7.3. Логическое проектирование базы данных
При проектировании логической структуры реляционной базы данных определяется оптимальный состав таблиц для хранения исходной информации. Для каждой таблицы указывается ее название, перечень полей и первичный ключ. Идентифицируются связи между таблицами. В рамках логического проектирования БД могут формулироваться ограничения целостности, приниматься решения о создании индексов и т. д.
Наиболее часто для решения перечисленных задач используется переход к логической модели базы данных от концептуальной модели, представленной в виде ER-диаграммы [ 3, 4 ]. Существуют методы однозначного преобразования ER-модели в логическую модель реляционной базы данных. Эти методы положены в основу работы многих CASE-систем – инструментальных средств автоматизированного проектирования баз данных (см. п. 7.5).
Рассмотрим основные правила преобразования ER-модели в логическую модель базы данных на примере диаграммы, построенной на рис. 15 (для иллюстрации некоторых правил будут привлекаться дополнительные сущности и связи между ними). Для наглядности полученных результатов заполним таблицы данными.
Для сущности, имеющей только простые атрибуты (например, Магазин), может быть созданы одна таблица. Каждый атрибут сущности становится полем таблицы, ключевые атрибуты сущности – первичным ключом таблицы. Для каждого поля определяется допустимый тип данных и другие ограничения целостности. Названия сущности и таблицы, атрибутов и полей могут совпадать, если используемая СУБД не накладывает на них никаких ограничений (табл. 7.1):
Таблица 7.1
Магазины
Название | Адрес | Специализация |
Светлый | Мира, 14 | Хозяйственные товары |
Восток | Запарина, 2 | Продовольственные товары |
Факел | Фрунзе, 13 | Хозяйственные товары |
Если между двумя сущностями имеется связь «один к одному», а класс принадлежности связи для обеих сущностей является обязательным, обе сущности можно объединить в одну таблицу. Первичным ключом таблицы может быть первичный ключ любой сущности. Например, имеются связанные сущности Директор и Магазин. В каждом магазине есть директор, и каждый директор руководит только одним магазином. Таблица, включающая атрибуты сущностей Директор и Магазин, может выглядеть следующим образом (табл. 7.2):
Таблица 7.2
Магазины
Название | Адрес | Специализация | Директор | ИНН |
Светлый | Мира, 14 | Хозяйственные товары | Деев О.И. | 27213456 |
Восток | Запарина, 2 | Промышленные товары | Стогов П.И. | 27243212 |
Факел | Фрунзе, 13 | Хозяйственные товары | Репина О.Г. | 27231217 |
Когда между сущностями имеется связь «один к одному», а класс принадлежности связи для одной сущности является обязательным, а для другой необязательным, для каждой сущности формируется отдельная таблица. К таблице, сущность которой имеет обязательный класс принадлежности, добавляется в качестве поля ключ таблицы с необязательным классом принадлежности.
Рассмотрим связь между сущностями Магазин и Автомобиль. Предположим, лишь некоторым магазинам («Светлый», «Восток») принадлежит автомобиль (только один). У других магазинов («Факел») автомобиля нет (класс принадлежности связи для сущности Магазин является необязательным). Каждый автомобиль является собственностью некоторого магазина (класс принадлежности связи для сущности Автомобиль является обязательным). Таблица с информацией о магазинах будет идентична табл. 7.1, а таблица с информацией об автомобилях будет иметь следующий вид (табл. 7.3):
Таблица 7.3
Автомобили
Номер | Марка | Водитель | Адрес магазина |
Х 123 МН | ЗИЛ-130 | Андреев Р.С. | Мира, 14 |
Х 234 РТ | ГАЗ-66 | Реутов С.П. | Запарина, 2 |
При связи между сущностями «один ко многим» в процессе формирования таблиц решающую роль играет класс принадлежности сущности, находящейся со стороны «много». Если он не является обязательным, следует создать три таблицы. Две из них будут соответствовать каждой сущности, ключи сущностей станут первичными ключами этих таблиц. Третья таблица будет связующей, в нее должны входить первичные ключи связываемых таблиц.
В ситуации, когда класс принадлежности сущности, находящейся со стороны «много», обязателен, достаточно создать две таблицы. Ключ таблицы, находящейся со стороны «один», должен быть добавлен в таблицу, находящуюся со стороны «много».
Рассмотрим связь «один ко многим» между сущностями Магазин и Работник (см. рис. 15). Класс принадлежности связи для сущности Работник является обязательным. Таблица с информацией о магазинах будет иметь вид, идентичный табл. 7.1, таблица с информацией о работниках будет включать ключ таблицы Магазин (табл. 7.4):
Таблица 7.4
Работники
ИНН | ФИО | Должность | Адрес | Адрес магазина |
27212367 | Фомин Л.М. | продавец | Боровая, 16 | Мира, 14 |
27233319 | Цыпин Л.Е. | продавец | Мира, 33 | Запарина, 2 |
27254322 | Гейт Ф.П. | грузчик | Осиновая, 5 | Фрунзе, 13 |
27265413 | Ревва С.Р. | кассир | Мира, 67 | Мира, 14 |
Если между двумя сущностями имеется связь «многие ко многим», независимо от класса принадлежности связей этих сущностей, необходимо сформировать три таблицы. Две таблицы соответствуют связываемым сущностям, ключи этих сущностей становятся первичными ключами таблиц. Третья таблица является связующей, в нее должны входить первичные ключи обеих сущностей.
Рассмотрим связь «многие ко многим» между сущностями Продавец и Товар. Таблица Продавцы может иметь структуру, совпадающую со структурой таблицы Работники (см. табл. 7.4), таблица Товары будет иметь вид (табл. 7.5):
Таблица 7.5
Товары
Артикул | Название | Цена, руб. |
100 | Туфли | 5 000 |
200 | Сапоги | 7 000 |
300 | Костюм | 10 000 |
400 | Костюм | 8 000 |
Таблица Продажи позволяет связать таблицы Продавец и Товары (табл. 7.6). В результате по данным, хранящимся в трех связанных таблицах, можно получить информацию о том, какие товары продает конкретный продавец.
Таблица 7.6
Продажи
ИНН | Артикул |
27212367 | 100 |
27212367 | 300 |
27233319 | 100 |
27233319 | 400 |
Рассмотренные правила преобразования ER-модели в логическую модель базы данных достаточно просты, наглядны и позволяют получить хорошие результаты. Более подробные сведения о данном процессе приводятся в книге [ 3 ].
- Содержание
- Предисловие
- Введение
- 1. Основные понятия баз данных
- 1.1. Банк данных и его компоненты
- Пользователи
- Прикладные
- 1.2. Модели данных
- 2. Целостность баз данных
- Условие на значение “Парус” or “Волна” or “Лотос”
- 3. Внутренняя организация субд
- 3.1. Общие положения
- 3.2. Линейный список
- 3.3. Инвертированный список
- 3.4. Индексы
- 3.5. Хеширование
- Область переполнения
- 3.6. Кластеризация
- 4. Распределенная обработка данных
- 4.1. Режимы работы с базой данных
- Параллельный
- 4.2. Архитектура «клиент-сервер»
- Приложения
- 4.3. Модели «клиент-сервер»
- 4.4. Управление распределенными данными
- 5. Восстановление баз данных
- 5.1. Транзакции
- 5.2. Журнал транзакций
- 5.3. Выполнение транзакций в многопользовательских системах
- 6. Защита баз данных
- 7. Основы проектирования реляционных баз данных
- 7.1. Этапы проектирования
- 7.2. Построение концептуальной модели предметной области
- 7.3. Логическое проектирование базы данных
- 7.4. Нормализация отношений
- 7.5. Автоматизированные технологии проектирования баз данных
- Заключение
- Библиографический список