Проектирование базы данных учёта отгруженной продукции. Концептуальное проектирование модели данных учёта отгруженной продукции

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

Рисунок 6 – Диаграмма ЕR-экземпляра для связи адресуется

На основе диаграмм ЕR-экземпляров и ER-типа для каждой связи построим диаграмму Чена модели данных.

Рисунок 7– Диаграмма ER-типа

Уточним концептуальную модель данных согласно правилам. Теория по правилам.

Так как имеется связь многие ко многим, применим правило 6.На основании этого выделим сущность «ТТН-Продукция» которая отображена на диаграмме Чена рисунок 8.

Рисунок 8 – Концептуальная модель данных

Таким образом построили концептуальную модель.

2 ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ модели данных учета отгруженной продукции

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

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

Для реляционных СУБД логическое проектирование заключается в проектировании таблиц, индексов, представлений, транзакций, авторизации доступа и т.д.

Можно указать основные этапы логического проектирования:

1.  Выбор требуемой СУБД, которая ориентирована на определённую модель данных. Как правило, чаще всего выбирается СУБД реляционного типа. Так же на выбор СУБД влияю такие факторы как:

·  стоимость

·  инструментальные средства и возможности СУБД

·  тип модели

·  переносимость

·  требование СУБД к оборудованию.

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

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

4.  Нормализация отношений. После процедуры преобразования объектов к отношениям реляционной модели рекомендуется проверить корректность  полученной структуры путём нормализации. Это позволит получить адекватный проект и в дальнейшем наращивать логическую моделью.

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

6.  Определение представлений.

7.  Определение пользователей и прав доступа к объектам базы данных.

8.  Создание окончательного варианта логической модели данных.

2.1 Определение отношений, атрибутов и их доменов, обеспечение целостности

Основные правила преобразования концептуальной модели в реляционную:

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