77. Пример проектирования простой er–модели.

При разработке ER–модели необходимо получить след информацию о предметной области:

1. базовый список сущностей

2.список основных характеристик (атрибутов) каждой сущности.3.наличие и описание взаимосвязей м/у сущностями метод ER диаграмм удобен т.к процесс выделения сущностей атрибутов и связей может быть реализован итерациями, т.е разработав 1–ый или n–ый вариант диаграмм проектировщик проводит их экспертизу(заказчик, эксперт в предметной обл–ти), при этом официальной документацией явл сами ER диаграммы. 1 этап. Менеджер считает что система должна выполнять след действия: 1)хранить инфу о покупателях, 2) печатать накладные, 3)счет–фактуры, 4)следить за наличием товаров на складе. 2 этап. Выделяем существенное: 1) потенциальные кондидаты на сущности и атрибуты. Покупатель–кондидат на сущность. Накладная–кнс(при усл что владеем Эл–ми бух учета). Счет–фактура – не сущность, а внешняя форма накладной. Товар–сущность. Склад– не достаточно инфы, однако пусть–сущность. Наличие товара–атрибут, но атрибут какой сущности–инфы не достаточно. 3 этап.

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

5. анализ атрибутов сущностей

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

1) юридическое лицо – термин обобщенный, связанный с термином покупатель и т.к. эта БД не работает с физическими лицами термин юридическое лицо и покупатель совпадут. Это сущность.

2) наименование покупателя, адрес, банковские реквизиты – явные характеристики покупателя, т е атрибуты. Если наименование покупателя – простой атрибут, то адрес и банковские реквизиты необходимо конкретизировать. Например адрес в профессиональной БД – это стандартный набор атрибутов вида: индекс, код региона, город, район, улица, дом, корпус, квартира, офис.

3) наименование товара – явная характеристика.

4) единица измерения – явная характеристика.

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

6) номер накладной и дата очевидные атрибуты.

7) список товара в накладной очевидно не может быть атрибутом, поэтому его необходимо выделить в отдельную сущность

8) количество товаров в накладной – характеристика, но это характеристика не товара а накладной.

9) аналогично цена товара в накладной опять не столько характеристика товара, а скорее всего характеристика товара в накладной. Поэтому возникает вопрос: цена товара и цена товара в накладной это одно и то же или нет?

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

11) наименование склада – атрибут но для простоты и эффективности заполнения вместо одного атрибута наименования склада рекомендуется использовать номер или короткое имя и наименование или полное имя.

6. в ходе следующей беседы с менеджером продаж удалось выяснить, что каждый товар имеет текущую цену, т е цену по которой товар продается в данный момент. Поэтому цена может меняться со временем. А это означает что цена одного и того же товара в разных накладных может быть разной. Т о необходимо различать 2 разных атрибута: цена товара и текущая цена товара в накладной. Замечание: для простоты мы не будем вводить отдельную сущность цена товара, иначе легко заметить, что эта сущность могла бы иметь атрибуты: код товара, цена товара, дата. Т к сущности накладная и товар связаны по типу многие – ко – многим, то такая связь в реляционной БД должна быть расщеплена на две связи типа один – ко – многим, как известно для этого требуется дополнительная сущность. Этой сущностью будет список товаров накладной или «низ». Т е ее связь с сущностями накладная и товар можно описать как: «каждая накладная обязана иметь одну или несколько записей из списка товаров и каждая запись из списка товаров накладной должна включаться только в одну накладную и товар может включаться в одну или несколько записей из списка товаров накладной и каждая запись из списка товаров накладной должна быть связана только с одним товаром». Т о список товаров накладной имеет атрибуты: количество товаров, цена товара. Аналогично проанализируем связь сущностей склад и товары. Т к между ними может появиться связь многие – ко – многим, то введем дополнительную сущность – товар на складе. Очевидным атрибута будет количество товара на данном складе, т е товар может храниться на любом складе и количество его на каждом складе может быть любым. Т о проанализировав все требования менеджера нам удалось построить концептуальную модель БД склад. Рассмотрим реализацию этой модели с помощью ER – диаграммы.

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

Рисунок 2

Очевидно, что на физической ER – модели каждая сущность представляет собой таблицу БД а каждый атрибут – поле таблицы. Обратим внимание, что в некоторых таблицах для реализации физических связей между таблицами появились новые поля, которые отсутствовали в концептуальной модели. Однако эти поля на самом деле являются реализацией механизма внешних ключей, т е чтобы реализовать связь родительского отношения с дочерним, т е связь один – ко – многим. Пришлось добавить ключевые атрибуты родительского отношения в дочерние. Поэтому и появились такие поля как Sklad_ID, PR_ID в таблице Product_In_Sclad и тд.

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

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