Файл: Разработка регламента выполнения процесса «Складской учет»(Анализ предметной области).pdf

• Словарь групп ролей;
• Словарь ролей;
• Словарь ресурсов.

Организационная диаграмма представляет собой традиционную древовидную структуру, во главе которой находится единственный блок, который разделяется вниз на блоки подсистем. Каждый блок является графическим представлением конкретной роли. На организационной диаграмме можно так же увидеть иерархию подчинения на нашем складе (Заведующий складом, Кладовщик, Грузчик).

Рисунок 1.8 Организационная диаграмма

§1.4 Разработка модели базы данных системы складского учета

ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако, ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

В ERwin существуют два уровня представления и моделирования - логический и физический. Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц.

Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ERwin. ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне.

Объекты модели на данном уровне называются сущностями и атрибутами. Диаграмма сущность – связь (рисунок 1.9) содержит сущности и взаимосвязи, которые отражают основные закономерности предметной области.

Данные о сущностях разработанной модели данных представлены в таблице А.1 (Приложение А). Данные о выявленных связях между сущностями представлены в таблице А.2 (Приложение А). Связи «многие ко многим» в таблице А.3 (Приложение А).

Рисунок 1.9 ER – диаграмма модели базы данных

Модель данных, основанная на ключах (KB – модель), кроме сущностей и связей, включает в себя ключевые атрибуты сущностей: первичные (PK) и внешние (FK). Для определения первичных и внешних ключей были выявлены следующие закономерности:

1. Каждый сотрудник обладает своим уникальным кодом.
2. Каждый сотрудник может быть закреплен на выдачу товара по нескольким накладным.
3. Каждая накладная обладает своим уникальным кодом.
4. Каждая накладная может содержать несколько строк, указывающих на товары по накладной.
5. Каждая накладная содержит информацию о клиенте, на которого производится выдача товара.
6. Каждый клиент вносится в базу под своим уникальным кодом.
7. Каждый клиент может оформлять несколько накладных.
8. Каждый склад обладает уникальным кодом.
9. Один склад может быть прописан в нескольких накладных.
10. Каждая строка входит в состав определенной накладной.
11. Каждая строка содержит информацию о товаре по коду товара.
12. Каждый товар обладает своим уникальным кодом.
13. Каждый поставщик обладает своим уникальным кодом.
14. Каждый поставщик может поставлять множество товаров.

В результате формируем KB-модель (рисунок 1.10).

Рисунок 1.10 KB – диаграмма модели базы данных

Полная атрибутивная модель предполагает наиболее детальное представление структуры проектируемой базы данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.

Каждая из наших сущностей будет обладать своими атрибутами. Соответствие атрибутов и сущностей проведено в таблице А.4 (Приложение А). В таблице А.5 (Приложение А) отображены функциональные зависимости.

В результате формируется FA – модель, представлена на рисунке 1.2.8.

Рисунок 1.11 FA – модель базы данных информационной системы склада

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Для построения трансформационной модели необходимо определить домены атрибутов сущностей, области их допустимых значений, а также типы данных (таблица А.6 (Приложение А)).

В результате сформирована трансформационная модель (рисунок 1.12), ориентированная на формат выбранной СУБД и включает все сущности, атрибуты, их типы данных, а так же ограничения.

Рисунок 1.12 T – модель базы данных информационной системы склада

Далее была разработана DBMS-модель в виде SQL-кода, представленного в приложении Б. Его интерпретация позволила получить схему базы данных в формате СУБД MS SQL Server на физическом уровне.

Заключение

В результате выполнения курсового проекта были выполнены задачи:

• исследована предметная область;
• проанализированы внутренние бизнес-процессы организации складского учета;
• разработана модель бизнес-процессов организации;
• разработана модель данных ИС складского учета;

ИС спроектирована с использованием CASE – средств, согласно общепринятым стандартам. Все бизнес – процессы, диаграммы, а так же логическая структура базы данных смоделированы для последующего использования.

Разработанный регламент выполнения процесса «Складской учет» позволит вести полноценный складской учет: вести базу клиентов и поставщиков, производить все необходимые операции с товарами. Использование ИС позволит свести к минимуму появление ошибок при учете товаров, проводить инвентаризации в автоматизированном режиме и контролировать деятельность склада.

Таким образом, цель курсового проектирования можно считать достигнутой.

Список литературных источников

1. Ческидов С.В. Проектирование информационных систем на основе структурного подхода: Практикум. – М.: МГПУ, 2010. – 93 с.
2. Ческидов С.В. «Методическая разработка для проведения лабораторных работ»: М.:МГПУ, 2014.
3. Интернет – портал по разработке конфигураций на платформе 1С: Предприятие www.1c-pro.ru.
4. Материалы и видео уроки по созданию конфигурации на платформе 1С: Предприятие www.1c-uroki.ru.
5. GLPI (Gestionnaire libre de parc informatique) – система инвентаризации компьютерной и оргтехники. [Электронный ресурс] – Режим доступа: http://wiki.dieg.info/glpi (дата обращения 10.02.2017).
6. Коданев, В.Л., Чискидов, С.В. Проектирование информационных систем: Практикум, ч.1. – М.: МГПУ, 2010. – 93 с.
7. Исаев, Г.Н. Проектирование информационных систем: Учебное пособие. – М.: Омега–Л, 2013. – 424 с.
8. Белов, В. В. Проектирование информационных систем: учебник для студ. учреждений высш. проф. образования / В. В. Белов, В. И. Чистякова; под ред. В. В. Белова. – М.: Издательский центр «Академия», 2013. – 352 с.
9. Коваленко, В. В. Проектирование информационных систем: учебное пособие для студентов вузов. – М.: Форум, 2012. – 319 с.

Приложение А

Т а б л и ц а А.1 – Сущности и их определения

Т а б л и ц а А.2 – Связи между сущностями

Т а б л и ц а А.3 – Связи «многие-ко-многим»

Т а б л и ц а А.4 – Соответствие сущностей и атрибутов

Т а б л и ц а А.5 – Функциональные зависимости

Т а б л и ц а А.6 – Домены атрибутов сущностей

1. Приложение Б

CREATE TABLE Clienti

( Kod_klienta integer NOT NULL ,

Familiya varchar(20) NULL ,

Imya char(18) NULL ,

Otchestvo char(18) NULL ,

№_pasporta integer NULL )

go

ALTER TABLE Clienti

ADD CONSTRAINT XPKКлиенты PRIMARY KEY CLUSTERED (Kod_klienta ASC)

go

CREATE TABLE Nakladnaya

( ID_Naklad integer NOT NULL ,

Data_Naklad datetime NULL ,

Tip_Naklad varchar(20) NULL ,

ID_Sotr integer NOT NULL ,

Kod_klienta integer NOT NULL ,

Kod_sklada integer NOT NULL)

go

ALTER TABLE Nakladnaya

ADD CONSTRAINT XPKНакладная PRIMARY KEY CLUSTERED (ID_Naklad ASC)

go

CREATE TABLE Postavshik

( ID_Postavshika integer NOT NULL ,

Name varchar(20) NULL ,

Gorod varchar(20) NULL ,

Rekvezit varchar(20) NULL)

go

ALTER TABLE Postavshik

ADD CONSTRAINT XPKПоставщик PRIMARY KEY CLUSTERED (ID_Postavshika ASC)

go

CREATE TABLE Skladi

( Kod_sklada integer NOT NULL ,

Naimenovanie varchar(20) NULL )

go

ALTER TABLE Skladi