2.3. Проблемы проектирования реляционных баз данных

Начинающие разработчики могут совершить следующие типичные ошибки при проектировании реляционных баз данных:

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

2. Ошибкой является повторение атрибута, относящегося к одной сущности, в нескольких отношениях. Например, указание в таблице «сделки» помимо номера продавца еще его имени, которое также находится в таблице «продавцы». Это может нарушить непротиворечивость информации. Впрочем, если речь идет об официальном документе, которому соответствует бумажный документ, на это можно пойти, ведь человек может сменить имя, но он подписывал документ под прошлым именем.

3. Иногда одинаковые по названию атрибуты могут повторяться в разных отношениях. Например, продавец из Екатеринбурга мог совершить сделку с покупателем из Петербурга в Москве. В этом случае эти атрибуты относятся к трем отношениям – продавцам, покупателям и сделкам.

4. Вычисляемые атрибуты лучше вычислять в запросах. Например, не стоит в таблицу «продавцы» помещать атрибут – «суммарная стоимость сделок». Это значение будет вычисляться в запросе по сделкам этого продавца.

5. Путаница моделей. Ошибочное представление предметной области приведено в Табл. 5. Эта таблица соответствует кросс-таблице или витрине OLAP. Правильное представление в реляционной модели приведено в Табл. 6.

Табл. 5. Кросс-таблица или витрина данных

Студент	Математика	Физика	Химия
Иванов	5	4	5
Петров	4	3	2
Сидоров	3	2	5

Табл. 6. Реляционное представление

№	Студент	Дисциплина	Оценка
1	Иванов	Математика	5
2	Иванов	Физика	4
3	Иванов	Химия	3
4	Петров	Математика	5
5	Петров	Физика	3
6	Петров	Химия	2
7	Сидоров	Математика	3
8	Сидоров	Физика	2
9	Сидоров	Химия	5

4. Каждой сущности соответствует свое отношение. Каждому документу – как минимум одно отношение. Нужно посмотреть, не является ли документ составным, не входят ли в него другие таблицы. В этом случае каждой таблице документа будут соответствовать свое отношение. При этом это отношение должно быть представлено в реляционной форме (см. пример из предыдущего пункта – даже если оценки студентов были приведены в бумажном виде как показано в Табл. 5, в базе данных они должны быть как в Табл. 6).

5. Наличие большого числа одинаковых по смыслу атрибутов в нескольких отношениях заставляет задуматься о выделении их в отдельное отношение. Например, у продавцов и покупателей повторяется фамилия, имя. Отчество. Паспортные данные и город. Можно выделить их в отдельную таблицу «человек». При этом появляется дополнительная возможность учета: один и тот же человек может быть и продавцом и покупателем (см. Рис. 9). С атрибутами надо поступать осторожно. Например, человек может работать продавцом в городе, а жить в другом городе – пригороде. Поэтому атрибут «город» лучше не переносить в таблицку «человек». Связи проводятся между ключевыми атрибутами отношений и представляют собой связи «1 к 1». Им соответствует связь наследования в объектно-ориентированных технологиях.

6. Иногда в одном документе могут быть вложенные таблицы. В этом случае им соответствуют отдельные отношения. Часто им соответствует связь агрегация («целое-часть») из объектных технологий. Например, в одной и той же сделке покупатель может покупать товары разного вида (см. Рис. 9).

Рис. 9. Уточненная реляционная модель БД «Продажи»

7. Связь «1 ко многим» соединяет первичный ключ и внешний ключ. Ошибкой является использование вместо первичного ключа других атрибутов. Например, соединение не номера, а имени продавца из таблицы «продавцы» с соответствующим атрибутом в таблице «сделки».

8. Связь «многие ко многим» практически всеми реляционными БД не поддерживается. Как правило, ей соответствует промежуточное отношение, соединенная двумя связями «1 ко многим» с исходными отношениями. В случае БД «Продажи» таким промежуточным отношением является таблица «сделки», соединяющая таблицы «продавцы» и покупатели. Часто промежуточное отношение не распознается, тогда получается схема как на Рис. 10. Такая схема возможна, если у покупателя только один продавец, а у продавца – один покупатель, что практически для большинства предметных областей нереально (такие связи возможно, если речь идет о какой-нибудь уникальной услуге, например, личном водителе, обслуживающем единственного пассажира). При этом, если включены механизмы обеспечения целостности, то нам придется создавать продавцов и покупателей парами (то есть мы не сможем вставить покупателя без продавца, а продавца без покупателя), что невозможно в большинстве реляционных БД.

Рис. 10. Неправильное представление связи «1 ко многим»

9. Две связи между двумя таблицами, отличающиеся направлением от связей на Рис. 10 вполне возможны и широко распространены. Например, команды, участвующие в игре (см. Рис. 11).

Рис. 11. Две связи между двумя таблицами

10. Проблемы возникают из-за рекурсивных связей, когда таблица связана сама с собой, как в примере на Рис. 3, продавцы и их начальники хранятся в одной таблице, которая связана сама с собой (N_Начальника выбирается из N в этой же таблице – см. Рис. 12). Большинство СУБД не поддерживают рекурсивные запросы, это означает, что построить иерархию подчинения – задача нетривиальная, еще сложнее вывести рзультат на экран. Рекурсивную связь можно заменить на промежуточную таблицу «Подчинение», связанную с исходной таблицей двумя связями «один ко многим» - Рис. 13. В последнем случае, правда, имеется проблема – для одного подчиненного можно создать несколько записей в таблице «Субординация» и окажется, что у него много начальников. Вариант с рекурсивной связью также не лишен недостатков. В иерархии подчинения возможен цикл, например, Иванов – начальник Петрова, Петров – Сидорова, а Сидоров – начальник Иванова. Поэтому в триггере на запись требуются дополнительные проверки.

Рис. 12. Рекурсивная связь

Рис. 13. Замена рекурсивной связи

Д/З . Для примера из Д/З опишите домены из предметной области предыдущего задания, увеличить схему БД, придумайте отношение «многие ко многим» и замените его на отношения «1 ко многим», придумайте рекурсивную связь, нормализуйте схему БД в 3NF, обозначьте первичные и внешние ключи, выберете варианты механизмов обеспечения целостности.

Вопросы для самопроверки:

1. Является ли список нормальных форм исчерпывающим?

2. Все ли нормальные формы, следующие по номеру, автоматически выполняют условия предыдущих нормальных форм?