При проектировании логической структуры реляционной базы данных определяется оптимальный состав таблиц для хранения исходной информации. Для каждой таблицы указывается ее название, перечень полей и первичный ключ. Идентифицируются связи между таблицами. В рамках логического проектирования БД могут формулироваться ограничения целостности, приниматься решения о создании индексов и т. д.
Наиболее часто для решения перечисленных задач используется переход к логической модели базы данных от концептуальной модели, представленной в виде ER-диаграммы [ 3, 4 ]. Существуют методы однозначного преобразования ER-модели в логическую модель реляционной базы данных. Эти методы положены в основу работы многих CASE-систем – инструментальных средств автоматизированного проектирования баз данных (см. п. 7.5).
Рассмотрим основные правила преобразования ER-модели в логическую модель базы данных на примере диаграммы, построенной на рис. 15 (для иллюстрации некоторых правил будут привлекаться дополнительные сущности и связи между ними). Для наглядности полученных результатов заполним таблицы данными.
Для сущности, имеющей только простые атрибуты (например, Магазин), может быть созданы одна таблица. Каждый атрибут сущности становится полем таблицы, ключевые атрибуты сущности – первичным ключом таблицы. Для каждого поля определяется допустимый тип данных и другие ограничения целостности. Названия сущности и таблицы, атрибутов и полей могут совпадать, если используемая СУБД не накладывает на них никаких ограничений (табл. 7.1):
Таблица 7.1
Магазины
|
Название |
Адрес |
Специализация |
|
Светлый |
Мира, 14 |
Хозяйственные товары |
|
Восток |
Запарина, 2 |
Продовольственные товары |
|
Факел |
Фрунзе, 13 |
Хозяйственные товары |
Если между двумя сущностями имеется связь «один к одному», а класс принадлежности связи для обеих сущностей является обязательным, обе сущности можно объединить в одну таблицу. Первичным ключом таблицы может быть первичный ключ любой сущности. Например, имеются связанные сущности Директор и Магазин. В каждом магазине есть директор, и каждый директор руководит только одним магазином. Таблица, включающая атрибуты сущностей Директор и Магазин, может выглядеть следующим образом (табл. 7.2):
предыдущаяследующая