Файл: Анализ существующих информационных систем компании для выявления решения, компенсирующего недочеты.pdf

Вследствие существования связи «многие-ко-многим» была образована вспомогательная сущность [12] «Партии-Поставки», однако в процессе тестирования было выяснено, что нет нужны хранить информацию о поставках отдельно, и более продуктивное решение — частично перенести данные во вспомогательную сущность, частично избавиться от некоторых атрибутов. Следовательно, в сущность «Партии-Поставки» были добавлен Идентификатор, Код задания (который создается при добавлении новой записи в БД), Количество партий в поставке.

Также было решено, что целесообразнее привязать сущность «Комментарий», как и сущность «Документы», к той же вспомогательной сущности «Партии-Поставки».

В сущность «Комментарий» был добавлен атрибут «pr_no», являющийся дубликатом идентификатора пользователя в основной базе данных. Так как прямая связь между базами данных была сложно осуществимой, было решено сделать копию.

Полученная схема базы данных приведена на Рис. 3.

Рис. 3. Схема базы данных

В таблицах 1-8 представлено составление реляционных отношений.

В Таблице 1 показаны атрибуты сущности «Поставки»: ID (который является первичным ключом), Модель, Имя модели, Артикул2 (код товара внутри компании), Производитель, Страна, Дата производства, Дата поставки, Гарантия, Проверка ОТК, Дата пригодности, Страна.

Стоит заметить, что Дата производства относится ко времени изготовления партии, а Дата поставки — ко времени приема партии на склад.

Таблица 1

«Партия»

В Таблице 2 показаны атрибуты вспомогательной сущности «Партии-Поставки»: ID (который является первичным ключом), ID Партии (ВнК к таблице «Партия»), ID Поставки, Количество партий в поставке, Код задания.

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

Таблица 2

«Партии-Поставки»

В Таблице 3 показаны атрибуты сущности «Изображения»: ID (ПК), Название, Партия (ВнК к таблице «Партия»), Статус актуальности, Автор. Так как информация о том, кто добавляет изображение, не выводится пользователю, нет смысла реализовывать связь с таблицей пользователей основной БД.

Таблица 3

«Изображения»

В Таблице 4 показаны атрибуты сущности «Ссылки на изображения»: ID (ПК и ВнК к таблице «Изображения»), Ссылка на изображение, Изображение.

Таблица 4

«Ссылки на изображения»

В Таблице 5 показаны атрибуты схожей сущности «Документы»: ID (ПК), Название, Поставка (ВнК к таблице «Партии-Поставки»), Статус актуальности, Автор.

Таблица 5

«Документы»

Таблица 6, характеризующая атрибуты сущности «Ссылки на документы», аналогична Таблице 4: ID (ПК и ВнК к таблице «Документ»), Ссылка на документ, Документ.

Таблица 6

«Ссылки на документы»

В Таблице 7 показаны атрибуты сущности «Комментарий»: ID (ПК), ответственный за заказ, Текстовое поле, Статус актуальности, Партия-Поставка (ВнК к к таблице «Партии-Поставки»).

Таблица 7

«Комментарий»

• 1. Нормализация

По схеме БД видно, что существует две связи 1:1, что является денормализацией [13]. Следует объединить таблицы:

1. «Изображения» и «Ссылки на изображения».
2. «Документы» и «Ссылки на документы».

Также было найдено дублирование данных в сущностях:

1. «Партия» (атрибут «Страна»);
2. Изображения (атрибут «Тип»);
3. Документы (атрибут «Тип»).

Для нормализации до четвертой нормальной формы были выделены следующие сущности.

В Таблице 8 показаны атрибуты сущности «Страна»: ID (ПК), Название.

Таблица 8

«Страна»

Следовательно, после нормализации сущность «Партия» (Таблица 9) лишится текстового атрибута, который заменится более простым текстовым полем, который станет внешним ключом для таблицы «Страна».

Таблица 9

«Партия»

Тем же самым способом была произведена нормализация сущностей «Изображения» и «Документы». В Таблице 10 показаны атрибуты сущности «Тип изображения».

Таблица 10

«Тип изображения»

Следовательно, в отношении «Изображения» текстовое поле заменяется более коротким числовым, который будет являться внешним ключом к таблице «Тип изображения». Также после объединения с таблицей «Ссылки на изображения» появится атрибут «Ссылка».

Таблица 11

«Изображения»

Аналогичные действия проводятся для нормализации отношения «Документы». Изменения представлены в Таблицах 12-13.

Таблица 12

«Тип документа»

Таблица 13

«Документы»

Результирующая схема базы данных выглядит так, как показано на Рис. 4.

Рис. 4. Схема БД после нормализации

Так как база данных находится на стадии тестирования в рамках корпоративной сети, доступ к ней есть у любого сотрудника компании. В дальнейшем планируется разделение пользователей на группы и ограничение прав доступа, но на данном этапе эта информация не подлежит обязательному внесению в проектирование базы данных.

В результате работы над этим подразделом была сформирована первоначальная схема базы данных на основании ER-диаграммы, составлены реляционные отношения, проведены их нормализация и сопутствующее изменение схемы.

2.3 Физическое проектирование

Название БД в системе компании: Erp_PurchaseLot.

Данные таблиц базы данных приведены в Приложении 1.

1. Триггер «articul2» является проверкой на ввод и на обновление артикула [14]. Ограничения таковы: вводимые символы должны быть цифрами, а их длина должна быть не больше тринадцати. При неправильном вводе пользователь видит сообщение об ошибке.
2. Триггер «task_num» является аналогичной проверкой на ввод кода задания. Требования: вводимые символы должны быть цифрами, а их длина должна быть не больше шести. Результатом неправильного ввода является сообщение об ошибке.

Код созданных триггеров приведен в Приложении 2.

На Рис. 5 показан скрин диаграммы БД из MS Server 2012.

Рис. 5. Диаграмма базы данных

1. Представления [15].

В интерфейсе была реализована связь основной БД с дополнительным модулем. Это было сделано через представления. На Рис. 6 показано представление dbo.v_PoReceiptTasks. Оно состоит из двух атрибутов:

— task_id (код задачи, который создается при занесении нового заказа в БД);

— pr_no (идентификатор для связи с другими таблицами).

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

Рис. 6. Представление dbo.v_PoReceiptTasks

На Рис. 7 показано представление dbo.v_PoReceiptItems. Оно состоит из четырех атрибутов:

— pr_no (тот же идентификатор из представления dbo.v_PoReceiptTasks);

— pi_no (идентификатор для связи с другими таблицами);

— ri_no (не использующийся на данный момент идентификатор);

— qty_ord_rec_plan (количество комплектующих в поставке, которое должно быть доставлено по плану и может разбиваться по партиям).