База данных / examen / conceptual_model_пример
.pdf1
Лекция 5. Разработка концептуальной модели Предметной Области на учебном примере.
5.1 |
Постановка задачи............................................................................................................................ |
1 |
5.2 |
Определение сущностей, свойств и связей. ................................................................................... |
1 |
5.2.1 Определение сущностей............................................................................................................ |
1 |
|
5.2.2 Определение связей................................................................................................................... |
3 |
|
5.2.3 Определение ограничений на объекты во внешнем представлении..................................... |
6 |
|
5.2.4 Определение основных операций над данными..................................................................... |
6 |
|
5.3 |
Еще один пример.............................................................................................................................. |
7 |
5.4 |
Построение концептуальной схемы по имеющимся внешним схемам. ...................................... |
7 |
5.1 Постановка задачи
Пусть в некотором внешнем представлении выполняется описание поставок товаров на склад.
Предполагается, что в одной поставке может участвовать только один поставщик, поставляя только один вид товара (за одну поставку один поставщик может дать один товар). Поставщик может участвовать в нескольких поставках. Поставщик может поставлять несколько товаров.
Входные данные: Каждая поставка описывается с помощью приходной накладной. В накладной указывается номер накладной, название и адрес поставщика, название товара, количество поставляемого товара, цена единицы товара, единицы измерения товара, дата поставки, тип склада (холодильник, обычный, …), а также фамилия человека, принимающего поставку.
Выходные данные: информация о товаре, информация о поставщике, информация о размещении и количестве разных товаров на складе, возможно, некоторая другая информация.
Имея такое неформальное описание внешнего представления, выполним концептуальное проектирование данного внешнего представления.
Согласно п.3.2 лекции 3, данная задача выполняется за 5 шагов, с нужным числом итераций.
5.2 Определение сущностей, свойств и связей.
Воспользуемся нисходящей методологией проектирования концептуальной схемы, т.е. схемой "от общего к частному". Мы будем идти от некоторой абстрактной сущности, обладающей всеми возможными свойствами, согласно описанию внешнего представления, и постепенно уточняя требования пользователей, будем формировать новые сущности, устанавливать новые связи и определять принадлежность свойств той или иной сущности или связи.
5.2.1 Определение сущностей
Входные данные предполагают, что центральным в данном внешнем представлении будет тип сущностей ПОСТАВКА.
В первом приближении тип сущностей ПОСТАВКА характеризуется такими свойствами (см.
Рис. 5.1)
2
ПОСТАВКА |
Цена ед. товара |
|
|
|
Ед. измерения |
Код_поставки |
Дата_поставки |
Название_поставщика |
Тип_склада |
|
и |
Адрес_поставщика |
|
Название товара |
|
Количество поставленного товара
Рисунок 5.1-Исходный тип сущностей ПОСТАВКА
Недостаток: при такой концептуальной схеме вся информация связана, т.е. информацию об отдельном поставщике, который в данной поставке не участвует, получить нельзя, более того, при внесении новой поставки от того же поставщика все данные о поставщике будут повторно внесены, это может быть источником ошибок при работе оператора, вносящего данные, а также возникнет избыточность при хранении данных. Поэтому, выделим тип сущностей ПОСТАВЩИК, и его свойствами будут название поставщика и его адрес. Поскольку ПОСТАВЩИК может участвовать в нескольких ПОСТАВКАХ, то между двумя типами сущностей возникает связь 1:M. (см. Рис. 5.2). Однако и такая внешняя схема
|
|
1,N |
|
1,1 |
|
|||
ПОСТАВЩИК |
участвует |
ПОСТАВКА |
||||||
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
Код_поставщика 
Название_поставщика 
Адрес_поставщика
Код_поставки Название товара
Количество поставленного товара Цена ед. товара Ед. измерения Дата_поставки
Тип_склада
и
Рисунок 5.2 - Уточнение внешней схемы. Тип сущностей ПОСТАВЩИК. обладает недостатками: нельзя выдать информацию о товаре, если он отсутствует в поставке.
3
Код_поставки
Количество поставленного товара
|
|
|
|
Дата_поставки |
|
|
|
|
Тип_склада |
|
|
|
|
и |
ПОСТАВЩИК |
1,N |
участвует |
1,1 |
ПОСТАВКА |
|
|
|||
|
|
|
|
1,1 |
Код_поставщика |
|
|
|
|
Название_поставщика |
|
|
был поставлен |
|
Адрес_поставщика
1,M
ТОВАР
Код_товара
Название товара
Цена ед. товара
Ед. измерения
Рисунок 5.3 - Добавление типа сущностей ТОВАР
Поэтому, выделим тип сущностей ТОВАР, его свойствами будут: название товара, ед. измерения, цена ед. товара. Поскольку один экземпляр типа сущностей ТОВАР может участвовать в нескольких экземплярах ПОСТАВОК, но в каждом экземпляре ПОСТАВКИ присутствует только один ТОВАР, то между двумя типами сущностей возникает связь 1:M. (см. Рис. 5.3)
Замечание:
При определении типов сущностей ПОСТАВЩИК и ТОВАР мы неявно добавили по одному свойству к каждому типу: "код_поставки" и "код_товара", и сделали их первичными ключами. Как известно, в концептуальном моделировании с помощью диаграмм Чена, каждый тип сущностей (в том числе и слабая сущность) должен обладать первичным ключом. Поэтому часто, чтобы не делать первичным ключом длинную текстовую строку, вводят дополнительный атрибут, основная задача которого - быть уникальным идентификатором экземпляра типа сущностей.
5.2.2 Определение связей
Типов связей “Участвует” и “Был поставлен” недостаточно для того, чтобы выдавать информацию такого вида:
“Какие товары может поставлять отдельный поставщик” “Какие поставщики могут поставлять данный товар”
Ключевое слово “может” подсказывать, что связи будут необязательными, т.е. типа 0:M. Изменим внешнюю схему с учетом последних требований (см. Рис.5.4)
Код_поставщика 
Название_поставщика 
Адрес_поставщика
4
Код_поставки Количество поставленного товара Дата_поставки
Тип_склада
и
ПОСТАВЩИК |
1,N |
участвует |
1,1 |
ПОСТАВКА |
|
|
|||
0,N |
0,N |
|
|
1,1 |
|
|
|
||
|
|
|
|
был поставлен |
|
|
Может |
0,M |
1,M |
|
|
|
||
|
|
поставлять |
|
ТОВАР |
|
|
|
0,M |
Код_товара |
Может быть |
|
Название товара |
||
|
|
|||
поставлен |
|
|
Цена ед. товара |
|
Ед. измерения
Рисунок 5.4 - Добавление типа сущностей ТОВАР
Почти всегда существует более одного варианта построения внешних и концептуальной схем даже для одной и той же задачи.
Например, так может выглядеть второй вариант построения внешней схемы (см. Рис.5.5):
0,N
Возможные
поставки
0,M
Код_поставщика 
Название_поставщика 
Адрес_поставщика
ПОСТАВЩИК 1,M
Реальные
поставки
ТОВАР 1,M
Код_товара 1,M
Название товара
Цена ед. товара
Ед. измерения
5
Код_поставки
Количество поставл. товара
Дата_поставки
Тип_склада
и
Рисунок 5.5 - Другой вариант внешней схемы
Сразу определяются два типа сущностей ПОСТАВЩИК и ТОВАР, их первичные ключи, и описательные атрибуты.
Типы связей могут быть такими:
ПОСТАВЩИК “поставляет несколько" ТОВАРОВ (вообще , а не в конкретный момент); ТОВАР "поставляется несколькими" ПОСТАВЩИКАМИ (возможно, разными). В такой интерпретации появляется связь M:N “Реальные Поставки” для фиксации уже произведенных поставок (класс принадлежности: обязателен с двух сторон ). ПОСТАВЩИК "может поставить несколько" ТОВАРОВ и ТОВАР "может быть поставлен несколькими" ПОСТАВЩИКАМИ. Для фиксации таких возможных зависимостей появляется связь M:N “Возможные поставки”, класс принадлежности которой - необязателен с двух сторон).
Комментарий: ”Реальные поставки” (как, впрочем, и ”Возможные поставки”) могут рассматриваться как агрегированные объекты. В данном примере "Реальные поставки" может рассматриваться как агрегированный объект - процесс, в котором участвуют ПОСТАВЩИКИ и ТОВАРЫ. Этот объект имеет набор свойств, характерный для типа сущности ПОСТАВКА в первом варианте внешней схемы.
6
Таким образом, можно сформулировать общий вывод:
Внешние и концептуальные схемы одной и той же предметной области могут иметь разные ER-диаграммы.
Сущности могут стать связями или свойствами, и наоборот. Критерий выбора – понятность, удобство модификации, корректность полученной схемы.
5.2.3 Определение ограничений на объекты во внешнем представлении
Определим ограничения на значения атрибутов выделенных типов сущностей.
Тип сущностей "ПОСТАВКА":
Все атрибуты являются обязательными, единичными, статическими.
Код_поставки - натуральное число от 1 до 9999, обозначающие порядковый номер приходной накладной.
Количество_поставленного_товара - натуральное число от 1 до 999999. Дата_поставки - дата в виде дд_мм_гггг.
Код_склада - натуральное число от 1 до 9.
Тип сущностей "ПОСТАВЩИК":
Все атрибуты являются обязательными, единичными, статическими.
Код_поставщика - натуральное число от 1 до 999, обозначающее порядковый номер поставщика в списке.
Название_поставщика - текст, 50 символов. Адрес_поставщика - текст, 50 символов.
Тип сущностей "ТОВАР":
Все атрибуты являются обязательными, единичными, статическими.
Код_товара - натуральное число от 1 до 999, обозначает порядковый номер товара в списке.
Название товара - текст, 25 символов.
Цена_единицы_товара - вещественное число, формат 999999,999. Ед_измерения - текст, 10 символов.
5.2.4Определение основных операций над данными
Вданной предметной области типичные операции могут быть такие: Операция 1. Оформление новой поставки.
Операция 2. Внесение данных о новом поставщике.
Операция 3. Внесение данных о новом товаре.
Операция 4. Внесение данных обо всех возможных товарах, поставляемых данным поставщиком.
Для каждой операции создается такая таблица (см. например, Табл. 1.):
Таблица 1. – Характеристики для Операции 1.
7
Название |
Тип |
Частота |
Сущности |
Сколько |
Тип доступа |
операции |
(I–интерак- |
выпол- |
|
экземпляров |
(R – чтение, |
|
тивный |
нения |
|
|
W - запись) |
|
B– |
|
|
|
|
|
пакетный) |
|
|
|
|
Операция |
I |
50 / день |
Поставка |
1 |
W |
1 |
|
|
Товар |
1 |
R |
|
|
|
Поставщи |
1 |
R |
|
|
|
к |
|
|
5.3 Еще один пример
Пусть существует внешнее представление, в котором описан сбыт товаров со склада. Предполагается, что каждый товар можно продать один раз, но за одну операцию продажи можно продать несколько товаров. Сформируем внешнюю схему представления СБЫТА (см.
Рис.5.6):
ТОВАР |
1,1 |
Был |
1,M |
ПРОДАЖА |
|
|
|||
|
|
продан |
|
|
Код_товара |
|
|
|
Код_продажи |
Название товара |
|
|
Название_покупателя |
|
Цена ед. товара |
|
|
Название товара |
|
Ед. измерения |
|
|
Способ_доставки |
|
|
|
|
|
Отпускная_цена |
|
|
|
|
Дата_продажи |
Рисунок 5.6 - Внешняя схема для задачи о сбыте
5.4 Построение концептуальной схемы по имеющимся внешним схемам.
Для этого рассмотрим типы сущностей:
1.В двух внешних представлениях участвует тип ТОВАР, причем в разных представлениях есть лишь часть всей информации о ТОВАРЕ, следовательно, в концептуальной схеме создается тип сущностей ТОВАР, обобщающий всю информацию из внешних схем.
2.В типе сущностей ПОСТАВКА используется свойство “код_склада”. Очевидно, что для учета поставок на все склады предприятию необходимо создать тип сущностей СКЛАД.
3.Различают товары промышленные и продовольственные, в свою очередь, эти категории разделяются на подкатегории (например, продовольственные – хлебобулочные, молочные или промышленные – оргтехника, и т.д.). Для ускорения поиска товара с нужными свойствами, точной идентификации товара, и возможности создания отчетов по каждой категории товаров, вводится вспомогательная сущность КАТЕГОРИИ ТОВАРОВ. См. Рис.5.7 или более развернутый пример на Рис 5.8.
После создания концептуальной схемы и спецификации всех новых типов сущностей и связей, создается общая таблица операций по типу Табл.1, но включающая операции, выполняемые уже над всей концептуальной схемой (если такие операции нужны).
СКЛАД |
|
Код_склада |
|
|
Название_складаа |
|
1,1 |
Адрес_склада |
|
|
Код_поставщика 
Название_поставщика 
Адрес_поставщика
ПОСТАВЩИК 1,N
на склад
участвует
0,N 0,N
Может
поставлять
8
|
Код_поставки |
|
Количество поставленного товара |
|
Дата_поставки |
1,1 |
Продать_до |
и |
|
1,1 |
ПОСТАВКА |
|
1,1
был поставлен
1,N |
Норма_запаса |
|
0,M |
||
|
||
ТОВАР |
На_складе |
0,1
|
0,M |
Может быть |
1,1 |
поставлен |
|
был продан
Относится к
1,M
Код_товара Название товара Цена ед. товара Ед. измерения
0,M
КАТЕГОРИИ
Код_категории
Название
ПРОДАЖА
Код_продажи Количество Дата_продажи
Отпускная цена
и
Способ_доставки 
Название_покупателя 
Адрес_покупателя
9
кодМенеджера |
|
|
|
МЕНЕДЖЕР |
1,M |
|
|
|
|
ФИО |
|
|
|
1,M |
|
|
|
|
|
|
|
|
|
едИзм |
|
|
|
|
|
|
оформляет |
|
|
ЕД.ИЗМЕР. |
1,M |
имеет |
|
оформляет |
|
|
|
|
|
|
|
||||
номерПН |
покупку |
|
|
1,1 |
|
продажу |
|
||
|
|
|
|
номерРН |
|||||
|
|
|
|
|
|
||||
дата |
|
|
|
номенклНомер |
|
|
|||
|
|
|
|
НоменклНомер+ |
дата |
||||
|
|
|
|
|
|
|
|||
1,1 |
|
название |
ТОВАР |
|
едИзм |
|
1,1 |
||
|
|
|
|
||||||
|
|
|
|
|
|
||||
ПРИХОДНАЯ |
|
количество |
1,M |
1,M |
|
количество |
РАСХОДНАЯ |
||
НАКЛАДНАЯ |
|
|
|
|
отпЦена |
НАКЛАДНАЯ |
|||
|
1,M |
вхЦена |
|
|
|
|
1,M |
1,1 |
|
1,1 |
|
|
|
|
|
||||
|
|
Поступил |
Отпускается |
|
|||||
|
|
|
|
|
|
|
|||
|
формирует |
|
по |
|
по |
формирует |
|
||
|
приход |
|
|
|
|
расход |
|
||
|
|
1,1 |
1,1 |
|
|
1,1 |
1,1 |
|
|
участвует |
|
ПРИХОДНЫЙ |
|
РАСХОДНЫЙ |
|
оформляет |
|||
в поставке |
|
СКЛАДСКОЙ |
|
СКЛАДСКОЙ |
|
покупку |
|||
|
|
ОРДЕР |
|
|
|
ОРДЕР |
|
|
|
|
|
1,1 |
|
|
|
|
1,1 |
|
|
|
номерПСО |
|
|
на |
|
со |
|
номерРСО |
|
|
дата |
|
|
|
|
дата |
|
||
1,M |
|
|
1,M |
1,M |
|
|
1,M |
||
|
|
|
|
|
|
||||
ПОСТАВЩИК |
|
|
СКЛАД |
|
|
ПОКУПАТЕЛЬ |
|||
кодПоставщика |
|
|
кодСклада |
|
|
|
кодПокупателя |
||
НазваниеПоставщика |
|
|
НазваниеСклада |
|
|
|
НазваниеПокупателя |
||
АдресПоставщика |
|
|
типСклада |
|
|
|
АдресПокупателя |
||
телефон |
|
Рисунок 5.8 – Развернутая ER-диаграмма для БД «Учет товаров на складе» |
телефон |
||||||
|
|
|
|||||||