Моделирование концептуальной схемы базы данных
Рассмотрим основные элементы метода концептуального моделирования «сущность-связь» на следующем примере. Некоторая банковская компания хранит информацию о своих счетах (№счета, баланс), клиентах (№клиента, имя, адрес, статус) и филиалах банка (название, адрес, директор). Счета могут быть двух типов – депозитные и текущие. Клиенты могут иметь произвольное число счетов. Несколько клиентов могут совместно использовать общий счет. Каждый счет обрабатывается одним филиалом.
Можно выделить три сущности – ФИЛИАЛЫ, КЛИЕНТЫ, СЧЕТА. На ER-диаграмме сущности обозначаются прямоугольником (рис 1.8.1).
Атрибуты описывают сущность и изображаются именованными овалами, прикрепленными к сущности. В нашем примере все атрибуты простые. Возможны и многозначные атрибуты, например, если у клиента два адреса. Ключевые атрибуты (т.е. та часть сущности, которая однозначно идентифицирует ее) выделяются подчеркиванием. Возможны составные ключи, состоящие из комбинации простых атрибутов.
Рис. 1.8.1. Сущности и атрибуты в ER-диаграмме
Связи представляют взаимодействие между сущностями и на диаграмме изображаются ромбом, который соединяет сущности. В нашем примере существуют бинарные связи между клиентами и счетами и между счетами и филиалами. Мы предположили, что каждый счет обрабатывается одним филиалом и каждый филиал обрабатывает произвольное количество счетов, поэтому тип связи между филиалом и счетами будет «один-ко-многим» Поскольку счет может совместно использоваться несколькими клиентами и клиент может иметь несколько счетов, то между ними связь имеет кардинальность «многие-ко-многим». ER-диаграмма нашего примера представлена на рис. 1.8.2.
Рис. 1.8.2. Модель данных «сущность-связь»
Связь типа «многие-ко-многим» может быть заменена двумя связями типа «один-ко-многим»: каждый счет может иметь множество регистраций для каждого клиента, использующего данный счет, и каждый клиент может иметь множество регистраций для каждого используемого счета. Такой вид связи называется слабой сущностью. Она не существует самостоятельно, а только при наличии связей, в которых участвует. Для создания ключа слабой сущности желательно использовать атрибуты связываемых сущностей. В нашем примере ключом может быть комбинация атрибутов ID_клиента и Номер_счета. Слабая сущность может иметь и собственные атрибуты, например, Дата_регистрации, Поручитель и т.п. На рис. 1.8.3 слабая сущность изображена двойной линией.
Т
Рис. 1.8.3. Представление
связи как слабой сущности
При изменении внешнего уровня архитектуры базы данных наша ER-модель может быть реконструирована. Например, если необходимо дополнить базу данных информацией о сотрудниках филиала, то это легко сделать, организовав связь кардинальности «один-ко-многим» между имеющейся сущностью Филиал и новой сущностью Сотрудники. Если необходимо учесть область деятельности сотрудников, то создаются подтипы, «Менеджер», «Экономисты», «Системный администратор», «Программист» и т.п.
Создание подтипов позволяет отразить в ER-диаграмме генерализацию (когда набор типов объектов объединяются в генерализованный тип) и специализацию (противоположный процесс) данных. Примером специализации является упомянутые подтипы «Депозиты» и «Текущие», а примером генерализации – объединение специальностей «Системный администратор» и «Программист» в тип «Технический персонал».
Р
ассмотрим
пример моделирования простой базы
данных. Необходимо хранить и обрабатывать
информацию о выполняемых фирмой проектах,
используемых деталях (или оборудовании)
и их поставщиках. Проекты, детали и
поставщики составляют основные объекты
(или сущности), о которых фирме
необходимо хранить информацию. На их
основе создаются базовые отношения
базы данных. Кроме сущностей имеются и
связывающие их отношения. Например,
существует отношение ДП между поставщиками
и деталями: каждый поставщик поставляет
определенные детали и, наоборот, каждая
деталь поставляется определенным
поставщиком; также существует отношение
между проектами и деталями (отношение
ПрД). Эти отношения двусторонние – их
можно рассматривать в обоих направлениях.
Следует помнить, что такие отношения,
подобно сущностям, являются частью базы
данных и называются слабыми сущностями.
Мы будем рассматривать их как специальный
тип объектов. ER-диаграмма,
показывающая сущности и связи в
рассматриваемом примере, представлена
на рис. 1.8.5.
В базе данных предлагается следующая семантика:
Таблица Проекты представляет уникальный номер проекта Пр№, его наименование Имя_Пр, руководителя проекта Имя_Рук.
Таблица Детали представляет уникальный номер детали Д№, название детали Имя_Д, цвет Цв, вес Вес (в граммах), город Гор, где производится деталь. Предполагается, что каждый вид детали одного цвета и производится в одном городе.
Таблица Поставщики представляет уникальный номер поставщика П№, имя Имя_П (не обязательно уникальное), значение рейтинга Статус, место расположения Гор.
Таблица ДП представляет поставки. Одно из ее назначений – соединение таблиц Детали и Поставщики. Она может состоять из полей П№, Д№ и поля количества поставок Кол.
Таблица ПрД представляет потребность проектов в деталях и соединяет таблицы Проекты и Детали. Она может состоять из полей Пр№, Д№ и, возможно, Кол.
Таким образом, можно считать, что один из возможных вариантов инфологической модели построен. Однако очевидно, что данные, содержащиеся в таблицах ДП и ПрД, можно представить более рационально, разместив их в одной таблице с именем, например, Поставки, включающей поля Д№, П№, Пр№ и Кол. Эта таблица будет является слабой сущностью и будет выполнять функцию отношений (связей) между сущностями Проекты, Детали и Поставщики конструируемой базы данных. На этом примере мы видим, что отношения, как и сущности, могут быть наглядно представлены таблицами.
С
учетом изложенного, схема базы данных
может иметь вид, изображенный на
рис. 1.8.6 (ключевые поля выделены
полужирным курсивом).
И
Поставки
Детали
П№
Д№
Пр№
Кол
Д№
Имя_Д
Цв
Вес
Гор
П1
Д1
Пр1
200
Д1
Тестер
Черный
250
Минск
П1
Д1
Пр4
700
Д2
Дозиметр
Серый
700
Борисов
П2
Д3
Пр1
400
Д3
Радиометр
Черный
1400
Гродно
П2
Д3
Пр2
200
Д4
Часы
Желтый
140
Минск
П2
Д3
ПР3
200
Д5
Рулетка
Красный
200
Брест
П2
Д3
ПР4
500
Д6
Лом
Черный
5000
Варшава
П2
Д3
ПР5
600
П2
Д3
ПР6
400
Поставщики
П2
Д3
ПР7
800
П№
Имя_П
Статус
Гор
П2
Д5
ПР2
100
П1
Волк
20
Брест
П3
Д3
ПР1
200
П2
Заяц
10
Минск
П3
Д4
ПР2
500
П3
Лев
30
Гродно
П4
Д6
ПР3
300
П4
Лиса
20
Минск
П4
Д6
ПР7
300
П5
Бык
30
Брест
П5
Д2
ПР2
200
П5
Д2
ПР4
100
Проекты
П5
Д5
ПР5
500
Пр№
Имя_П
Гор
П5
Д5
ПР7
100
Пр1
Спутник
Минск
П5
Д6
ПР2
200
Пр2
Корунд
Минск
П5
Д1
ПР4
100
Пр3
Лес
Брест
П5
Д3
ПР4
200
Пр4
Шина
Бобруйск
П5
Д4
ПР4
800
Пр5
Азот
Гродно
П5
Д5
ПР4
400
Пр6
Электро
Молодечно
П5
Д6
ПР4
500
Пр7
Кристалл
Пинск
Рис. 1.8.7. База
данных проектов, деталей и поставщиков
Определение базы данных на языке SQL может быть представлено так:
CREATE DOMAIN Пр№ CHAR(5) CREATE DOMAIN Имя CHAR(30) CREATE DOMAIN Д№ CHAR(5) CREATE DOMAIN Цв CHAR(10) CREATE DOMAIN Вес NUMERIC(5) CREATE DOMAIN Гор CHAR(15) CREATE DOMAIN Кол NUMERIC(5) CREATE DOMAIN П№ CHAR(5) CREATE DOMAIN Статус NUMERIC(3)
CREATE BASE RELATION Проекты ( Пр№ DOMAIN ( Пр№ ), Имя_Пр DOMAIN ( Имя ), Имя_Рук DOMAIN ( Имя ), PRIMARY KEY ( Пр№ );
CREATE BASE RELATION Детали ( Д№ DOMAIN ( Д№ ), Имя_Д DOMAIN ( Имя ), Цв DOMAIN ( Цв ), Вес DOMAIN ( Вес ), Гор DOMAIN ( Гор ), PRIMARY KEY ( Д№ );
CREATE BASE RELATION Поставщики ( П№ DOMAIN ( П№ ), Имя_П DOMAIN ( Имя ), Статус DOMAIN ( Статус ), Гор DOMAIN ( Гор ), PRIMARY KEY ( П№ );
CREATE BASE RELATION Поставки ( П№ DOMAIN ( П№ ), Д№ DOMAIN ( Д№ ), ( Пр№ DOMAIN ( Пр№ ), Кол DOMAIN ( Кол ), PRIMARY KEY ( П№, Д№, Пр№); FOREIGN KEY ( П№ ) REFERENCES Поставщики FOREIGN KEY ( Пр№ ) REFERENCES Проекты FOREIGN KEY ( Д№ ) REFERENCES Детали;
Представленная на рис. 1.8.6–1.8.7 модель базы данных будет использована нами в дальнейшем для иллюстраций различных реляционных операций.