Файл: Разработка регламента выполнения процесса «Управление запасами» (Обоснование необходимости внедрения информационной системы).pdf

2.3 Инфологическая модель базы данных разрабатываемой системы

Инфологическая (концептуальная) модель ‑ это формализованное описание предметной области, выполненное безотносительно к используемым в дальнейшем программным и техническим средствам.[16,17,18]

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

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

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

Рисунок 2.6 – Диаграмма «сущность-связь»

Таблица 2.1

Состав базы данных SAUSAGES

В таблице 2.1 приведены названия таблиц БД и их предназначение в системе. Описание таблицы дает возможность сделать вывод об информационном предназначении таблицы.

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

Физическая схема иллюстрирует ‑ как реализована физически БД с учетом проектирования инфологической модели. Также показаны информационные связи и потоки информации, позволяющие решить поставленные задачи оптимизации суточного производственного плана предприятия.

Рассмотрим структуру перечисленных таблиц базы данных, используемых программой. В табл. 2.2 приведены описания полей всех таблиц базы данных.

Таблица 2.2

Описание полей таблиц базы данных SAUSAGES

Следует заметить, что в таблице NUM_NAKL поле id и в таблице MOVE поле type_ могут приобретать следующие значения:

1 - приход сырья,

2 - производство сырья (полуфабриката),

3 - списание сырья,

4 - приход сырья,

5 - производство продукции,

6 - списание продукции,

7 - отгрузка продукции.

В таблице COMPOSITIONS логически связываются данные таблицы PRODUCT. Присутсвует реляционная связь “многие-ко-многим” по полям id_product (таблица Technology) и id_raw (таблица compositions) (рис 2.7).

COMPOSITIONS

Product

Product

Product

Продукт 1

Продукт 2

Продукт 3

Продукт 4

…

Product

Volume

Сырье 1

50

Сырье 2

1

Сырье 3

10

Сырье 4

100

…

…

5.5

25

75

10

1.50

10.5

52

Volume

…

Рисунок 2.7 ‑ Схема реляционной связи таблиц Product и COMPOSITIONS

3 ЭЛЕМЕНТЫ ПРОЕКТИРОВАНИЯ АИС

3.1 Модульная структура

Программа автоматизации может состоять из следующих программных модулей:

Таблица 3.1

Программные модули разрабатываемой системы

Структурное взаимодействие программных модулей представлено на Рисунок 4.1

UMain

UData

UProduct

UNakl

UCategors

URaw

UTech

Рисунок 3.1 ‑ Взаимодействие программных модулей системы

Модуль UMain является главным, он управляет порядком обработки информации и передачи данных по межмодульному интерфейсу.

Для ввода необходимых исходных данных в системе используются соответствующие формы, управление которыми осуществляют программные модули UCategors, UNakl, Uproduct, URaw, UTech.

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

3.2 Функционал системы

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

При описании сценария диалога рассмотрим подробно процедуру работы со справочниками (Рисунок 3.3).

На схеме (Рисунок 3.3) представлен классический набор операций с записями БД, в данном случае в отношении справочников (статистической информации в БД). В нашем случае обработка справочников имеет некоторые отличия. На схеме блок удаления выделен, потому что в нашей программной реализации удаление не предусмотрено. Это сделано умышленно с целью защиты БД и поддержания целостности данных. Дело в том, что данные в БД очень взаимосвязаны и удаление, например, какого-то сырья, может привести к критической ошибке, в том случае если это сырье было задействовано в других таблицах. Так как система однопользовательская и не предусматривает распределенного доступа, был выбран вариант, когда удаление непосредственно из информационной системы запрещено, вместо него есть редактирование. Это позволяет исправить ошибку, если она была допущена при вводе, операция редактирования намного более осознана, чем удаление. В случае необходимости удаления ‑ оператор через редактирование помечает какой-то объект как ошибочный или неправильный и при этом никакой коллизии в БД не происходит (просто другие сущности содержат теперь ошибочный объект), все другие записи и таблицы работают корректно, а корректный процесс удаления выполняет администратор системы. Он может сделать это непосредственно прямыми операциями с БД.

Рисунок 3.3 ‑ Сценарий диалога работы со справочниками

На Рисунок 3.4 представлено дерево программных модулей, отражающее структурно-функциональную схему пакета.

Рисунок 3.4 ‑ Дерево программных модулей

3.3 Анализ входной/выходной информации

3.3.1 Входные данные

Контроль достоверности информации в программе следует осуществлять на различных уровнях и на разных стадиях ее введения. Он призван обеспечить отсутствие ошибок при вводе тех или иных данных, поддержку достоверности информации в процессе функционирования СУБД.

К средствам контроля относятся:

1. задание входных данных, максимальных и минимальных значений, шаблонов для элементов ввода;
2. контроль над изменением информации при работе с ней и сообщения об изменении информации перед сохранением;
3. использование кэширования данных;
4. использование целостности связей;
5. использование таблиц-справочников;
6. отражение в справочной системе правил ввода информации.

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

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

Так на уровне программного кода для ввода даты поступления или реализации товара применен шаблон ввода. Данные о товарах в накладных вводятся путем выбора из соответствующих справочников, при этом в справочники интегрирована система поиска (например, выбор товара по категориям).

Также на уровне БД при формировании структуры таблиц определены поля, для которых при отсутствии ввода данных, определяется значение по умолчанию (например 0 для VOL), или проверяется уникальность содержания (ED_IZM).

Правильные связи между взаимосвязанными таблицами БД позволяют автоматически устанавливать и поддерживать организацию целостности.

Для запрета корректировки данных некоторых параметров использовано свойство ReadOnly для таблиц и их отдельных столбцов (ADOTABLE, DBGRID).

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

Данные в системах обработки информации основанных на базах данных принято делить на определенные категории (Рисунок 3.5).