Преобразование сущностей и атрибутов
1 - Каждая сущность преобразуется в определенное отношение.
2 – Каждый атрибут становится столбцом таблицы с тем же именем, но может быть выбран более точный формат атрибута.
3 - Уникальный идентификатор становится первичным ключом отношения. Получается набор предварительных отношений.
4 – Анализируются атрибуты отношений. Определяются функциональные зависимости между атрибутами. Если полученные отношения не находятся в 3НФ или если некоторым атрибутам не находится логически обоснованных мест в предварительных отношениях, то отношения пересматриваются и при необходимости декомпозируются (предыдущий пример).
5 – Отдельные атрибуты, характеризующие тот или иной признак сущности, могут быть выделены в отношение, домен которых ограничен конечным набором значений. Например, в предыдущем примере – должность преподавателя или статус студента. Категория товара или клиента.
6 – Еще один вид ограничений, накладываемый на данные, хранящиеся в БД, связан с правилами самой предметной области. Например, в группе- не более 35 человек. Оценки – от 2 до 5. В расписании не более 4 пар в день.
Вашему вниманию — несколько советов по включению полей в таблицы.
1 - Включайте атрибуты, относящиеся только к свойствам данного отношения. Атрибут, отображающий свойства другого отношения должен принадлежать другой таблице. Позже, при установлении связей между отношениями, вы увидите, как можно объединить данные нескольких атрибутов из разных таблиц.
А на этом этапе убедитесь, что каждое поле таблицы описывает только одно отношение. Если вы обнаружите, что в разных таблицах встречается однотипная информация, значит, какие-то таблицы содержат лишние поля.
2 - Не включайте производные или вычисляемые данные. В большинстве случаев вам нет необходимости хранить результаты вычислений в таблице. С помощью СУБДтвсегда сможете выполнить данные вычисления в нужный момент. Не имеет смысла хранить итоговые поля в таблице.
3 - Включите всю необходимую информацию. Довольно легко упустить важные данные. Вернитесь к собранным на первой стадии проектирования материалам. Внимательно рассмотрите бланки и отчеты и убедитесь в том, что вся интересующая вас информация может быть извлечена или вычислена из таблиц. Подумайте о вопросах, которые вы будете формулировать к базе данных. Сможете ли вы получить на них ответ, используя данные из ваших таблиц? Включили ли вы поля, в которых будут храниться уникальные данные типа кода клиента? Какие таблицы содержат информацию, обязательную для создания отчета или формы?
4 - Разделите информацию на наименьшие логические единицы. Вам может показаться, что удобно иметь одно поле для хранения полного имен клиента или одно поле для названия и описания продукта. Это ошибка. Если вы объединяете более одной категории информации в одном поле, потом вам будет очень не просто выделить из него отдельные факты. Постарайтесь разбить информацию на наименьшие логические части (1НФ).
Преобразование бинарных связей
Связь между сущностями преобразуется в связь между отношениями.
Связи между отношениями в реляционной модели данных реализуются посредством механизма внешних ключей. Чтобы этот механизм действовал, необходимо определиться с тем, которое из двух отношений является родительским, а которое — дочерним.
Родительским считается такое отношение, которое передает копию набора значений своего первичного ключа другому отношению, где этот набор значений будет представлять внешний ключ. Последнее отношение в этом случае будет являться дочерним отношением.
Связь типа 1:1
Предварительные отношения для бинарных связей 1: 1 могут быть получены вследствие просмотра нескольких логических альтернатив и выбора из них наиболее подходящей.
Рассмотрим предметную область – таксопарк. В нем работают водители. Каждый водитель ездит только на своем автомобиле. Пусть в проектируемой БД должна храниться следующая информация:
№В — номер водителя;
ФИО — фамилия, имя, отчество водителя;
Тел — телефон водителя;
№А – номер госрегистрации автомобиля
Марка – марка автомобиля
Мест – вместимость
Концептуальная схема выглядит следующим образом
Получаем отношение Автомобиль (№В; ФИО; Тел; №А, Марка, Мест). Первичным ключом этого отношения может быть ключ любой из двух сущностей. Можно спроектировать отношение водитель (№В; ФИО; Тел; №А, Марка, Мест).
Можно построить два отношения по одному под каждую сущность. При этом ключ каждой сущности должен служить первичным ключом для соответствующего отношения.
Водитель (№В; ФИО; Тел).
Автомобиль (№А, Марка, Мест)
Одна сущность преобразуется в родительское отношение, а другая - в дочернее. Для связи полученных отношений ключ родительского отношения добавляется в качестве атрибута (внешнего ключа) в дочернее отношение.
В результате получаем следующую реляционную схему:
Водитель (№В; ФИО; Тел, №А).
Автомобиль (№А, Марка, Мест)
Связь типа 1: М
Пусть существует бинарная связь типа 1: N. Студент учится в группе, в каждой группе учатся студенты определенной специальности.
Сущности: студент, группа, специальность
Каждая сущность преобразуется в отношение, ключ каждой сущности служит в качестве первичного ключа для соответствующего отношения.
Связи 1:М реализуется через внешний ключ. Для представления этой связи необходимо в дочернем отношении добавить внешний ключ, который соответствует первичному ключу родительского отношения
Обычно в качестве родительского назначается отношение, соответствующее "единичной" стороне связи, а в качестве дочернего назначается отношение, представляющее "множественную" сторону связи.
Студент Дочернее
Группа Родительское
Специальность Родительское
Группа Дочернее
Концептуальная модель
Логическая модель
Связь типа М:М
Реализуется через дополнительное отношение, которое содержит комбинацию первичных ключей исходных отношений. Такая связь может содержать атрибуты.
Пример 1
КУРС (НК, Назв_К);
ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_О, Тел_П);
ЧИТАЕТ (ТН, НК).
Вся информация о курсе будет содержаться в отношении КУРС, информация о преподавателе — в отношении ПРЕПОДАВАТЕЛЬ, а отношение ЧИТАЕТ будет содержать только экземпляры связи, имеющиеся в модели.
Пример 2
Поставщик поставляет нам товары
Пример 3
Преподаватель ставит на экзамене студенту оценку по предмету.
Проверка модели с помощью концепций последовательной нормализации
Созданный предварительный набор отношений логической модели данных должен обязательно быть подвергнут анализу на корректность. Проверка корректности состава каждого из отношений должна проводиться посредством применения к ним процедуры последовательной нормализации.
Целью применения этой процедуры является получение гарантий того, что каждое из отношений, полученных на основе концептуальной модели, находится, по крайней мере, в 3НФ. Если в процессе анализа отношений модели будут найдены отношения не отвечающие этим требованиям, то это будет означать, что где-то на предыдущих этапах были допущены ошибки. Возможно, ошибки появились при построении концептуальной модели, а возможно — в процессе ее преобразования в логическую модель.
Для обеспечения корректности логической модели в такой ситуации придется вернуться на ранние этапы проектирования и перестроить ошибочно созданные фрагменты модели.