Методология er проектирования
Шаг 1: Выбрать из описания требований к базе данных одну первичную сущность и указать атрибуты, которые будут принадлежать данной сущности. При возможности выделить ключ.
Шаг 2: Для описания базы данных использовать структурный английский язык для сущностей, атрибутов и ключей.
Шаг 3: Привести примеры некоторых данных.
Преобразование ЕR диаграммы в реляционную базу данных
Проиллюстрировав понятия о сущности и атрибуте, обратимся теперь к полу-физической реализации концепции. Мы говорим "полу-физической", поскольку мы действительно не касаемся физического файла, который хранится на жестком диске, а скорее, мы имеем дело с размещением данных в реляционных таблицах, чем с физическим представлением организации данных. В сущности, реляционная база данных является базой данных двумерных таблиц называющихся "отношения". Таблицы состоят из строк и столбцов. Строки часто называются кортежами, а столбцы – атрибутами. В реляционных базах данных, все атрибуты (табличные столбцы) должны быть атомарными и ключи должны быть не нулевыми. Кроме того, в реляционных базах данных, фактическое физическое расположение данных на диске обычно знать необязательно.
Процесс конвертации ER диаграммы в базу данных называется преобразованием (mapping). Мы касаемся только реляционной модели и, по мере повествования, будем рассматривать правила преобразования ER диаграмм в реляционные базы данных.
Начнем с правил преобразования для строгих сущностей:
M1 — для сильных сущностей: необходимо создать новую таблицу (отношение) для каждой сильной сущности и выбрать потенциальный ключ сильной сущности в качестве первичного ключа таблицы. Если в ER диаграмме указано более одного потенциального ключа, следует выбрать один из них первичным.
Затем, мы должны преобразовать атрибуты в сильной сущности. Правила преобразования разные для атомарных атрибутов, составных атрибутов и многозначных атрибутов. Сначала, мы определим правила преобразования для атомарных атрибутов:
M1a — преобразование атомарных атрибутов сущности — для сущностей с атомарными атрибутами: преобразовать сущности в таблицы, формируя столбцы из атомарных атрибутов сущности.
Реализация реляционной базы данных из ER диаграммы на Рисунке 2.3 с некоторыми данными должна выглядеть следующим образом:
Имя сущности, СТУДЕНТ, будет именем отношения (таблицы). Атрибуты диаграммы становятся заголовками столбцов. Данная таблица с данными является реализацией отношения и приводится здесь в качестве примера тех типов данных, которые могут содержаться в отношении. Упорядочивание столбцов в общем то необязательно для реляционных баз данных.
А как насчет смешанных и многозначных атрибутов? Как было упомянуто выше, аксиома реляционных баз данных состоит в том, что все столбцы должны быть атомарными. Если в диаграмме имеется неатомарный атрибут, то необходимо сделать его атомарным для преобразования в реляционную базу данных. Для составных атрибутов, можно достичь атомарности, записывая по отдельности компоненты атрибута.
Следующее правило преобразования касается составных атрибутов:
M1b – для сущностей с составными атрибутами: преобразовать сущности в таблицы, формируя столбцы из элементарных (атомарных) частей составных атрибутов.
Посмотрите на Рисунок 2.4. Реляционная база данных, которая соответствует ER-диаграмме, выглядит следующим образом:
Многозначные атрибуты были изображены на Рисунке 2.5. На этой диаграмме сущности, у сущности СТУДЕНТ был составной атрибут - имя и многозначный атрибут - школа. Это означает, что в строку для одного студента можно записать более чем одну школу. Данные, которые могли бы быть представлены этой диаграммой, могли бы выглядеть так (чтобы проиллюстрировать многозначными атрибуты, мы показываем только имя, адрес и посещенные школы):
Отметим, что это – не реляционная таблица, поскольку значения в столбце Школа - не атомарные.
Правило преобразования для многозначных атрибутов должно быть таким:
M1c - для многозначных атрибутов: сформировать отдельную таблицу для многозначных атрибутов. Завести столбец для каждого значения многозначного атрибута вместе с ключом оригинальной таблицы. Ключом новой таблицы будет совокупность многозначного атрибута и первичного ключа родительской сущности. После этого удалить многозначный атрибут из первоначальной таблицы.
Теперь предположим, что в вышеуказанном примере имя является ключом. Тогда это можно преобразовать в два отношения: отношение с многозначным атрибутом и результирующее отношение с исключенным многозначным атрибутом.
Отношение с многозначным атрибутом
Результирующее отношение с исключенным многозначным атрибутом
При отсутствии ключа, правило преобразования остается таким же за исключением того, что вместо "вместе с ключом,… " мы должны говорить "вместе с атомарными атрибутами… " В реляционных базах данных каждый столбец таблицы содержит только атомарные атрибуты. Также, каждый столбец уникален. Следовательно, в любой таблице потенциальный ключ – совокупность всех атрибутов. Обычно, из подмножества "всех атрибутов" можно выделить ключ; но поскольку не существует двух одинаковых строк, можно сказать, что одним из потенциальных ключей является совокупность всех атрибутов.
Если атрибуты имя или адрес не считались бы уникальными, то результирующее отношение могло быть таким:
STUDENT
Name Adress School
Отметим, что правило M1c - это преобразование ненормализованного отношения в первую нормальную форму (1NF), обсужденное в Главе 1.
Контрольные вопросы 2.3
Как преобразовать многозначные атрибуты?
Как преобразоватьсоставные атрибуты?
Что такое уникальный идентификатор? Является ли он потенциальным ключом? первичным ключом? Обосновать.
[4] Здесь правила преобразования даны в сокращении из Elmasri и Navathe (2000).