Пример моделирования локальной ПрО

С помощью рассмотренных выше понятий могут быть получены ER- модели для большинства схем баз данных в традиционных административно-управленческих приложениях. Если ПрО обширная, то построение ее концептуальной модели будет протекать более успешно, если эту ПрО разбить на несколько локальных предметных областей. Объем локальной ПрО выбирается таким образом, чтобы в нее входило не более 6-7 сущностей. Как ранее упоминалось, отправными элементами для построения ER-модели локальной ПрО очень часто являются используемые в организации документы.

Предположим, что определена локальная ПрО: поставка товаров на склад. Пусть используемая форма поставки имеет вид, как на рис. 3.10.

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

Итак, анализируемая форма содержит следующую информацию: Поставщик, Индекс поставщика, Адрес поставщика, Товар. Индекс товара, Цена товара. Количество товара, Поставка, Индекс поставщика, Дата поставки и Номер склада.

Выделим две сущности: ПОСТАВЩИК и ТОВАР (рис. 3.11).

Оставшиеся атрибуты характеризуют сущность — ПОСТАВКА. Сформируем ее и установим определенные типы бинарных связей между тремя сущностями, исходя из следующих рассуждений: один и тот же поставщик может осуществить ряд поставок, но каждая поставка осуществляется только одним поставщиком.

Мощность связи между сущностями ПОСТАВКА и ТОВАР должна быть установлена M:N, так как каждая поставка может содержать несколько товаров, и один и тот же товар может содержаться в нескольких поставках. Исходя из вышесказанного, диаграмма модели предметной области ПОСТАВКА примет такой вид, как на рис. 3.12.

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

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

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

1. Спецификация сущностей:

ПОСТАВЩИК: Индекс_поставщика — идентификационный атрибут

Адрес_поставщика — описательный атрибут

Наименование_поставщика — описательный атрибут ПОСТАВКА: Индекс_поставки — идентификационный атрибут

Количество_товара— описательный атрибут

Дата_поставки — описательный атрибут

Номер_склада — описательный атрибут

ТОВАР: Индекс_товара — идентификационный атрибут

Наименование_товара — описательный атрибут

Цена_товара — описательный атрибут

2. Спецификация типов связей:

ПОСТАВЛЯЕТ: связь ПОСТАВЩИК <-----> ПОСТАВКА 1:N

ВКЛЮЧАЕТ: связь ПОСТАВКА <-----> ТОВАР M:N

3. Спецификация атрибутов:

Индекс_поставщика: символьный, 6 символов

Адрес_поставщика: символьный, 50 символов

Цена_товара: денежный

Сформированные спецификации заносятся в словарь данных.

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

Date: 2016-07-18; view: 447; Нарушение авторских прав