76
Рисунок 2.9 – Сущность связь (филиалы и города)
В связи Филиалы - Техника (М: М) независимо от класса принадлежности
сущностей формируются три отношения, два отношения соответствуют связы-
ваемым сущностям и их ключи являются первичными ключами этих отношений.
Третье отношение является связным между первыми двумя, а его ключ объеди-
няет ключевые атрибуты связываемых отношений. Связь изображена на рисунке
2.10
Рисунок 2.10 – Сущность связь (филиалы и техника)
В связи Заказы - Техника (М: М) независимо от класса принадлежности
сущностей формируются три отношения, два отношения соответствуют связы-
ваемым сущностям и их ключи являются первичными ключами этих отношений.
Третье отношение является связным между первыми двумя, а его ключ объеди-
няет ключевые атрибуты связываемых отношений. Связь изображена на рисунке
2.11
77
Рисунок 2.11 – Сущность связь (заказы и техника)
В связи Города - Филиалы (1: М) класс принадлежности сущности Филиа-
лы будет обязательным. Согласно правилу 3, первичный ключ сущности на сто-
роне 1 добавляется как атрибут в таблицу для сущности на стороне М, и служит
внешним ключом. И строится 2 таблицы.
Рисунок 2.12 – Сущность связь (города и филиалы)
В связи Сотрудники - Ремонт (1: М) класс принадлежности сущности Ре-
монт будет обязательным. Согласно правилу 3, первичный ключ сущности на
стороне 1 добавляется как атрибут в таблицу для сущности на стороне М, и слу-
жит внешним ключом. И строится 2 таблицы.
78
Рисунок 2.13 – Сущность связь (сотрудники и ремонт)
В связи Сотрудники - Ремонт (1: М) класс принадлежности сущности Ре-
монт будет обязательным. Согласно правилу 3, первичный ключ сущности на
стороне 1 добавляется как атрибут в таблицу для сущности на стороне М, и слу-
жит внешним ключом. И строится 2 таблицы.
Рисунок 2.14 – Сущность связь (клиенты и ремонт)
В связи Сотрудники - Заказы (1: М) класс принадлежности сущности зака-
зы будет обязательным. Согласно правилу 3, первичный ключ сущности на сто-
роне 1 добавляется как атрибут в таблицу для сущности на стороне М, и служит
внешним ключом. И строится 2 таблицы.
79
Рисунок 2.15 – Сущность связь (сотрудники и заказы)
Рисунок 2.16 – ERD-модель
Логическая модель. Разработка логической модели базы данных.
После того, как концептуальная модель одобрена, можно перейти к этапу
логического проектирования БД. При этом исходными данными для проектиро-
вания являются диаграмма ER-типов концептуальной модели предметной обла-
сти и логическая модель данных, используемая для реализации будущей БД и
поддерживаемая какой-либо коммерческой СУБД. [15]
80
В качестве логической модели данных выбираем реляционную модель ко-
гда, как наиболее распространенную в большинстве современных СУБД. [16]
Теперь следует преобразовать концептуальную модель в соответствии с требо-
ваниями реляционной модели данных.
Таким образом, формально этап логического проектирования БД может в
проекте отсутствовать, но при этом следует иметь в виду, что при выполнении
преобразования диаграммы ER-типов в схему БД с помощью выше изложенных
правил 1-8, мы, фактически и выполняем логическое проектирование БД с ис-
пользованием реляционной логической модели данных. И в любом случае полу-
чаем логическую модель, в которой все объекты представлены как сущности
(сильные или слабые) и связи один ко многим и один к одному (сильные или
слабые).
Еще одним ограничением реляционной модели данных является требова-
ние нормализации всех сущностей-отношений. Это требование часто называют
первой нормальной формой (1НФ). Оно заключается в том, чтобы все атрибуты
в БД были атомарными с точки зрения СУБД. Атомарность означает недели-
мость каждого значения данных на многие значения, например не допускается
иметь в БД атрибутов, представляющих собой списки значений (множественные
значения), как-то: номера телефонов, оценки, дни работы и т.д. Не допускается
иметь в БД и атрибуты составные, например адрес, включающий город, улицу,
дом, квартиру при условии, что в процессе использования БД потребуется обра-
щение к какой-либо части этого адреса.
Во всех этих случаях требуется на этапе логического проектирования обя-
зательно провести нормализацию каждого отношения, т.е. привести его к 1НФ.
На следующем шаге проектирования необходимо оценить полученные от-
ношения с точки зрения нормальных форм более высокого порядка. Причем, из
пяти нормальных форм, известных в настоящее время 2НФ, 3НФ. НФБК, 4НФ и
5НФ, на практике, как правило, бывает вполне достаточно обеспечить третью
нормальную форму или НФБК (усиленную 3НФ). В крайнем случае, можно во-
обще не заниматься вопросами приведения БД к той или иной НФ, но при этом
надо помнить о том, что надежность проекта будет тем ниже, чем сложнее БД и
чем большие требования предъявляются к целостности данных.
81
Чтобы провести проверку на уровень нормализации БД, необходимо:
разместить все атрибуты во всех полученных сущностях-отношениях
(слабых и сильных);
выявить в каждом отношении потенциальные ключи;
выявить все функциональные зависимости (ФЗ) между атрибутами в
каждом отношении;
сопоставить потенциальные ключи с детерминантами ФЗ (их левыми
частями);
если какой-либо детерминант отношения не совпадает ни с одним по-
тенциальным ключом этого же отношения, то данное отношение не находится в
той или иной НФ и его требуется нормализовать в соответствии с теорией нор-
мальных форм.
В результате приведения БД в ту или иную НФ, как правило, появляются
дополнительные отношения, которые следует добавить в логическую модель.
[17]
Таким образом, получается окончательный вариант логической модели
БД, ER диаграмма которой представлена на рисунке 2.17
82
Рисунок 2.17 – Логическая модель
83
Разработка физической модели базы данных. На третьем этапе проекта, опираясь
на логическую модель БД, полученную на предыдущем этапе.
На основе схемы базы данных, а именно, используя значения потенциаль-
ных и внешних ключей отношений, напишем скрипты создание таблиц.
Ниже приведен скрипт создания таблицы филиалы:
CREATETABLEBranches
(
BranchIdintIDENTITY (1,1) ,
Name nvarchar(50) NULL ,
Director nvarchar(50) NULL ,
PhoneDirectornvarchar(50) NULL ,
CityIdint NULL
)
ALTER TABLE Branches
ADDCONSTRAINTXPKФилиалPRIMARYKEY
Ниже приведен скрипт создания таблицы филиалы_продукты:
CREATE TABLE BranchesProducts
(
Quantity int NULL ,
BranchIdint NOT NULL ,
ProductIdint NOT NULL
)
go
ALTER TABLE BranchesProducts
ADDCONSTRAINTXPKФилиал_товарPRIMARY
Ниже приведен скрипт создания таблицы города:
CREATE TABLE Cities
(
CityIdint IDENTITY (1,1) ,
Name nvarchar(50) NULL
84
)
go
ALTER TABLE Cities
ADDCONSTRAINTXPKГородPRIMARYKEY
Ниже приведен скрипт создания таблицы клиент:
CREATE TABLE Customers
(
CustomerIdint IDENTITY (1,1) ,
Surname nchar(50) NULL ,
Name nchar(50) NULL ,
Patronymic nchar(50) NULL ,
Address nchar(50) NULL ,
Phone nchar(50) NULL
)
go
ALTER TABLE Customers
ADDCONSTRAINTXPKКлиентPRIMARYKEY
Ниже приведен скрипт создания таблицы поставка:
CREATE TABLE Deliveries
(
DateOfDeliveryIddate NOT NULL ,
Quantity int NULL ,
ProductIdint NOT NULL ,
ProviderIdint NOT NULL ,
BranchIdint NOT NULL
)
go
ALTER TABLE Deliveries
ADDCONSTRAINTXPKПоставкаPRIMARYKEY
85
Ниже приведен скрипт создания таблицы заказы:
CREATE TABLE Orders
(
OrderIdint IDENTITY (1,1) ,
DateOrdersdate NULL ,
OrderPricemoney NULL ,
SellerIdint NOT NULL
)
go
ALTER TABLE Orders
ADDCONSTRAINTXPKЗаказыPRIMARYKEY
Ниже приведен скрипт создания таблицы продукты:
CREATE TABLE Products
(
ProductNamenvarchar(50) NULL ,
Price money NULL ,
ProductIdint IDENTITY (1,1)
)
go
ALTER TABLE Products
ADDCONSTRAINTXPKТоварPRIMARYKEY
Ниже приведен скрипт создания таблицы продукты_заказы:
CREATE TABLE ProductsOrders
(
Quantity int NULL ,
OrderIdint NOT NULL ,
BranchIdint NOT NULL ,
ProductIdint NOT NULL
)
go