65

кардинальность 0, N. Следовательно, склад при магазине может отсутствовать, или их имеется несколько. Атрибуты, которые принимают более одного значения, называются многозначными.

Вобъекте Магазин имеется группированный атрибут Адрес. Атрибуты, входящие в его состав, объединены скобкой (см. рис. 16).

Вобъекте Магазин существует также атрибут объектного типа Продавец с кардинальностью 1, N (см. рис. 16). Это указывает на то, что данный объект связан с одним или несколькими объектами Продавец (в магазине могут работать один или несколько продавцов). Для обеспечения связи между рассматриваемыми объектами в объект Продавец обязательно должен входить атрибут Магазин, характеризующий этот объект (см. рис. 16).

Диаграммы семантических объектов допускают создание агрегированных объектов, подклассов объектов [ 12 ].

7.3. Логическое проектирование базы данных

При проектировании логической структуры реляционной базы данных определяется оптимальный состав таблиц для хранения исходной информации. Для каждой таблицы указывается ее название, перечень полей и первичный ключ. Идентифицируются связи между таблицами. В рамках логического проектирования БД могут формулироваться ограничения целостности, приниматься решения о создании индексов и т. д.

Наиболее часто для решения перечисленных задач используется переход к логической модели базы данных от концептуальной модели, представленной в виде ER-диаграммы [ 3, 4 ]. Существуют методы однозначного преобразования ER-модели в логическую модель реляционной базы данных. Эти методы положены в основу работы многих CASE-систем – инструментальных средств автоматизированного проектирования баз данных (см. п. 7.5).

Рассмотрим основные правила преобразования ER-модели в логическую модель базы данных на примере диаграммы, построенной на рис. 15 (для иллюстрации некоторых правил будут привлекаться дополнительные сущности и связи между ними). Для наглядности полученных результатов заполним таблицы данными.

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

66

каждого поля определяется допустимый тип данных и другие ограничения целостности. Названия сущности и таблицы, атрибутов и полей могут совпадать, если используемая СУБД не накладывает на них никаких ограничений (табл.

7.1):

Таблица 7.1

Магазины

Если между двумя сущностями имеется связь «один к одному», а класс принадлежности связи для обеих сущностей является обязательным, обе сущности можно объединить в одну таблицу. Первичным ключом таблицы может быть первичный ключ любой сущности. Например, имеются связанные сущности Директор и Магазин. В каждом магазине есть директор, и каждый директор руководит только одним магазином. Таблица, включающая атрибуты сущностей Директор и Магазин, может выглядеть следующим образом (табл. 7.2):

Когда между сущностями имеется связь «один к одному», а класс принадлежности связи для одной сущности является обязательным, а для другой необязательным, для каждой сущности формируется отдельная таблица. К таблице, сущность которой имеет обязательный класс принадлежности, добавляется в качестве поля ключ таблицы с необязательным классом принадлежности.

67

Рассмотрим связь между сущностями Магазин и Автомобиль. Предположим, лишь некоторым магазинам («Светлый», «Восток») принадлежит автомобиль (только один). У других магазинов («Факел») автомобиля нет (класс принадлежности связи для сущности Магазин является необязательным). Каждый автомобиль является собственностью некоторого магазина (класс принадлежности связи для сущности Автомобиль является обязательным). Таблица с информацией о магазинах будет идентична табл. 7.1, а таблица с информацией об автомобилях будет иметь следующий вид (табл. 7.3):

Таблица 7.3

Автомобили

При связи между сущностями «один ко многим» в процессе формирования таблиц решающую роль играет класс принадлежности сущности, находящейся со стороны «много». Если он не является обязательным, следует создать три таблицы. Две из них будут соответствовать каждой сущности, ключи сущностей станут первичными ключами этих таблиц. Третья таблица будет связующей, в нее должны входить первичные ключи связываемых таблиц.

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

Рассмотрим связь «один ко многим» между сущностями Магазин и Работник (см. рис. 15). Класс принадлежности связи для сущности Работник является обязательным. Таблица с информацией о магазинах будет иметь вид, идентичный табл. 7.1, таблица с информацией о работниках будет включать ключ табли-

цы Магазин (табл. 7.4):

68

Если между двумя сущностями имеется связь «многие ко многим», независимо от класса принадлежности связей этих сущностей, необходимо сформировать три таблицы. Две таблицы соответствуют связываемым сущностям, ключи этих сущностей становятся первичными ключами таблиц. Третья таблица является связующей, в нее должны входить первичные ключи обеих сущностей.

Рассмотрим связь «многие ко многим» между сущностями Продавец и Товар. Таблица Продавцы может иметь структуру, совпадающую со структурой таблицы Работники (см. табл. 7.4), таблица Товары будет иметь вид (табл. 7.5):

Таблица 7.5

Товары

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

Таблица 7.6

Продажи

ИНН Артикул

272123 100

67

272123 300

67

272333 100

69

19

272333 400

19

Рассмотренные правила преобразования ER-модели в логическую модель базы данных достаточно просты, наглядны и позволяют получить хорошие результаты. Более подробные сведения о данном процессе приводятся в книге [ 3 ].