Файл: БегичеваС.В. БеляеваО.Б. Метод.указания к курсовой работе Базы данных.pdf

11 

Сущности  (объекты)  отображаются  прямоугольниками,  свойства  объектов  – 

овалами.  Связи  изображаются  линиями,  соединяющими  сущности,  вид  линии  в  месте 

соединения  с  сущностью  определяет  кардинальность  связи.  В  таблице  3  приведены 

обозначения отношений между объектами в концептуальной модели. 

Таблица 3 – Условные обозначения кардинальности бинарных связей  

Обозначение 

Кардинальность 

Описание 

(1,1) 

Сущность 

имеет 

обязательный 

класс 

принадлежности. 

Указан 

интервал 

числа 

возможных 

вхождений экземпляров сущности в 
связь. 

(0,1) 

Сущность  имеет  необязательный 
класс принадлежности (один или ни 
одного экземпляра сущности) 

(0,N) 

Сущность  имеет  необязательный 
класс  принадлежности  (ни  одного, 
один 

или 

много 

экземпляров 

сущности) 

(1,N) 

Сущность 

имеет 

обязательный 

класс  принадлежности  (один  или 
много экземпляров сущности) 

Опишем подробно построение концептуальной модели проектируемой 

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

информационной системы.  

Рассмотрим  сущности  «Заказ»  и  «Заказчик».  На  схеме  обе  сущности 

отобразим в виде прямоугольников. Заказчик оформляет заказ. Отобразим в 

модели  связь  между  этими  сущностями,  а  процесс  оформления  обозначим 

ромбом.  Один  и  тот  же  заказчик  может  сделать  несколько  заказов.  В  то  же 

время  каждый  заказ  может  быть  оформлен  только  на  одного  заказчика. 

Таким образом, тип связи между этими двумя сущностями «один-ко-многим» 

(рисунок 1).  

Заказчик 

оформ

Заказ 

12 

Рисунок 1 – Связь между сущностями Заказчик и Заказ

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

присутствовать  в  нашей  базе  данных,  как  потенциальный  покупатель, 

который  до  сих  пор  не  сделал  ни  одного  заказа,  появление  же  заказа  без 

заказчика  невозможно.  Таким  образом,  сущность  «Заказчик»  имеет 

обязательный класс принадлежности (интервал вхождений сущности в связь 

(1,1)), а сущность «Заказ» необязательный (интервал вхождений сущности в 

связь (0, N)). 

На рисунке 2 отображена модель с учетом кардинальности связи. 

Рисунок 2 – Концептуальная модель «Заказчик-Заказ»

Обозначим на схеме в овалах свойства объекта «Заказчик» (рисунок 3). 

Рисунок 3 – Концептуальная модель «Заказчик-Заказ» 

Продолжим добавлять в схему другие сущности. 

В каждом заказе может содержаться заявка на поставку нескольких видов трубных 

изделий.  При  этом  заявки  на  один  и  тот  же  товар  могут  быть  сделаны  в  нескольких 

Заказчик 

оформляе

Заказ 

Заказчик 

оформля

Заказ 

Наименование 

ФИО 

руководителя 

Адрес 

Телефон 

13 

различных  заказах.    Выделим  «Товар»  отдельной  сущностью  на  схеме.  Связь  между 

сущностями «Заказ» и «Товар» имеет тип «многие-ко-многим». 

Очевидно,  что  в  отдельном  заказе  конкретный  вид  товара  может    быть  заказан 

крупной  партией,  а  может  быть  не  заказан  совсем.  Таким  образом,  сущность  «Товар» 

является необязательной и имеет интервал вхождения в связь (0, N). По аналогии, товар 

может входить во многие заказы, но так же может быть абсолютно невостребованным. То 

есть сущность «Заказ» в этой связи так же имеет класс принадлежности  (0, N). 

Каждый  товар  может  поставляться  только  одним  поставщиком  (бизнес-правило 

№6)  и  при  этом  каждый  поставщик  выпускает  множество  различных  видов  трубных 

изделий. Введем в модель сущность «Поставщик» и ассоциируем ее с сущностью «Товар» 

связью «один-ко-многим».  

Отметим, что каждый товар должен поставляться хотя бы одним поставщиком, но 

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

поставляет  товар  фирме-дилеру.  Поэтому  сущность  «Поставщик»  имеет  обязательный 

(кардинальность  связи:    (1,  1))  ,  а  сущность  «Товар»  необязательный  класс 

принадлежности (кардинальность связи:   (0, N)). 

Атрибут  «Количество»  товара  каждого  вида,  которое  необходимо  указать  при 

оформлении  заказа  не  принадлежит  ни  одной  из  рассмотренных  сущностей.  Он  не 

относится ни к сущности «Товар», т.к. характерен для конкретного заказа, ни к сущности 

«Заказ»,  т.к.  учитывает  количество  конкретного  товара  в  данном  заказе.  Этот  атрибут 

принадлежит связи, объединяющей сущности «Заказ» и «Товар». 

На рисунке 4 представим концептуальную модель базы данных. 

14 

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

1.3  ВЫБОР ЛОГИЧЕСКОЙ МОДЕЛИ ДАННЫХ 

На  следующем  этапе  необходимо  выбрать  модель  данных.  В  нашей  работе  для 

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

необходимо  привести  примеры  других  видов  моделей  данных  и  обосновать  выбор 

реляционной модели данных. 

Наименование 

ФИО 

руководителя 

Адрес 

Телефон 

Заказчик 

оформля
ет 

Заказ 

Заказчик 

оформля
ет 

Заказ 

включает 

Товар 

ФИО менеджера 

Статус заказа 

Цена входящая 

Дата исполнения 

Диаметр трубы 

ГОСТ 

Цена исходящая 

Стенка трубы 

Дата размещения 

Поставщик 

поставля
ет 

Наименование 

ФИО 

руководителя 

Адрес 

Телефон 

Количество 

15 

1.4  ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННО-ЛОГИЧЕСКОЙ МОДЕЛИ  

БАЗЫ ДАННЫХ 

На  данном  этапе  моделирования  происходит  уточнение  концептуальной  модели, 

преобразование  её  в  реляционную  модель.  В  логической  модели  из  концептуальной 

модели  сущности  преобразуются  в  таблицы,  связи  –  в  механизм  связывания  таблиц  с 

помощью  первичных  и  внешних  ключей,  а  тип  отношений  между  сущностями  в  тип 

отношений между двумя таблицами. 

В  этом  разделе  необходимо  привести  обоснование  выбора  первичных  и  внешних 

ключей.  

Необходимо  отдельно  остановиться  на  связи  «включает»  между  сущностями 

«Заказ»  и  «Товар».  В  концептуальной  модели  они  связаны  между  собой  отношением 

«многие-ко-многим».  В  реляционной  модели  связь  «многие-ко-многим»  между  двумя 

сущностями реализуются с помощью промежуточной сущности, которая связана с двумя 

другими  отношением  «один-ко-многим».  Таким  образом,  для  реализации  связи 

«включает»  при  переходе  к  реляционной  модели  базы  данных,  необходимо  создать 

дополнительную сущность «Заказано» с атрибутом сущности – «Количество». 

Выберите CASE-средство для рисования логической модели.  

В Visio реляционная модель базы данных может быть реализована таким образом, 

как  представлено  на  рисунке  5  (пример  для  задачи  из  лекции).  Построенная  логическая 

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

Рисунок 5 – Логическая модель