Техническое проектирование информационной системы

2 Проектная часть

2.1 Техническое проектирование информационной системы 

2.1.1 Разработка информационного обеспечения

Данная ИС проектируется для учета оборудования на складке открытого акционерного общества «Научно-производственная корпорация «Уралвагонзавод» (далее – ОАО «НПК «Уралвагонзавод»»). В результате изучения организации работы ОАО «НПК Уралвагонзавод»» выяснилось, что данная ИС будет применяться для хранения информации о поступившей на склад технике.

Храниться будет следующая информация:

• тип;
• фирма производитель;
• модель;
• срок гарантии;
• стоимость;
• поставщик;
• № отдела, где используется техника;
• ответственное лицо;
• дата покупки (поступления).

Так же необходимо хранить информацию о техобслуживании техники:

• замененные детали;
• описание проведенных работ;
• стоимость замененных деталей и проведенных работ.

В поступающих заявках следует отмечать следующую информацию:

• отдел, оформивший заявку;
• ответственное лицо;
• необходимая техника;
• дата подачи заявки.

2.1.2 Определение сущностей

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

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

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

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

• Сущность «Техника» включает в себя следующие поля:
• тип;
• производитель;
• модель;
• срок гарантии;
• дата поступления;
• стоимость;
• № отдела;
• ответственное лицо.
• Сущность «Техпаспорт» включает в себя следующие поля:
• замененные детали;
• описание проведенных работ;
• стоимость.
• Сущность «Поставщик» включает в себя следующие поля:
• название;
• телефон;
• адрес.

2.1.3 Определение связей (логическая модель)

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

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

Логическая модель – нормализация всех отношений и нахождение связей между ними.

Основная проблема разработчиков базы данных связана с тем, что разработка таблиц происходит в соответствии с их «видимой» формой. Вследствие чего таблицы могут содержать дублированные данные. Недостатками дублирования являются увеличение объема памяти для хранения таблиц, долгий поиск и сложность обработки данных.

Цель проектирования реляционной базы данных – найти оптимальное соотношение между количеством таблиц и их нормализацией.

Корректной называется схема базы данных, в которой отсутствуют нежелательные функциональные связи. Это достигается с использованием процедуры декомпозиции, при которой отношение заменяется множеством отношений, которые являются проекцией первого. Суть процесса нормализации – устранить нежелательные функциональные зависимости путем замены данной схемы другой, в которой отношения имеют более простую и регулярную структуру.

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

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

Выделяют следующую последовательность нормальных форм:

• первая нормальная форма;
• вторая нормальная форма;
• третья нормальная форма;
• четвертая нормальная форма;
• пятая нормальная форма.

21 источник литературы