2.2. Проектирование блок-схемы, баз данных, запросов и тд.

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

Схема 2.1. Инфологическая модель базы данных.

Схема 2.2. Даталогическая модель базы данных.

Как можно видеть из схемы 4, всего было использовано пять таблиц, при этом связующей была таблица «Список процессов», фактически, в ней были приведены название и список стадий. Для удобства был так же создан запрос «Общая информация», где помимо названия процессов и стадий выводится код, название и описание сырья, а так же, название и описание оборудования для каждой стадии. Таблица «Описание процесса» содержит основные параметры процессов и их описание. В ней так же приведены используемые для каждого процесса оборудование и сырье. Таблица «Описание оборудование» содержит название и описание всех используемых аппаратов в процессе получения глинозема. Помимо описания, данная таблица, содержит информацию о производителях, стране производства, стоимости, материале, размере, напряжении и так далее. Каждая из этих таблиц содержит поле «Стадия» которое, как уже было сказано, является связующим, но не всегда ключевым полем. К примеру, в таблице «Описание оборудования» ключевым полем является поле «Наименование», однако, связь всё равно идет по полю «Стадия». Это связанно с тем, что в случае определения поля «Стадия» ключевым во всех таблицах, не удается согласовать их одинаковое значения. В результате чего невозможно создать адекватные и удобные запросы.

Структура таблиц «Список сырья» и «Описание сырья» фактически схожи с предыдущими таблицами, за исключением того что в качестве параметров использовались параметры сырья, а не оборудования. Разумеется, описание у них тоже различаются. В данном случае интерес с точки зрения проектирования был лишь в том, что сырье используется только в 1 и 4 стадии, соответственно при создании запросов невозможно было не учитывать данный фактор. Мной было принято решение создавать запрос о сырье не с помощью поля «стадия», а с помощью отдельного поля «Код сырья», который был создан именно с этой целью. Так как всего в процессе участвует пять типов сырья, то и кодов в общей сложности всего пять. Эта информация, для удобства пользования запросом, была выведена в название запроса «Поставки сырья». Так же был создан запрос «Поставки оборудования», он, в отличии от запроса «Поставки сырья» использовал поле «Стадия», что в принципе логично, так как для каждой стадии используется своё оборудование. Так же сложной задачей было определиться о втором параметре отбора при запросах «Поставки сырья» и «Поставки оборудования» и после некоторых размышлений, я решил, что самым логичным будет выбрать в качестве второго параметра отбора поле «стоимость» (если быть точнее, то максимальная стоимость).