12. Этапы построения er модели. Получение реляционной схемы из er-схемы.

Выделяют три этапа проектирования БД:

-  инфологическое моделирование

-  даталогическое моделирование

-  физическая реализация

1) На первом этапе создается инфологическая модель предметной области.

Предметная область – это часть реального мира, представляющего интерес для данного проектирования.

Инфологической моделью предметной области называют описание предметной области, выполненное с использованием специальных языковых средств, и независящее от используемых в дальнейшем программных и технических средств.

2) На основе инфологической модели строится даталогическая модель.

Даталогическая модель является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Описание логической структуры БД на языке СУБД называется схемой .

3) Третий этап проектирования состоит в привязке ДЛМ к среде хранения с помощью модели данных физического уровня ( физической модели ). Описание физической структуры БД называется схемой хранения .

Компоненты ИЛМ:

•  описание объектов и связей между ними (ER – модель);

•  описание информационных потребностей пользователей;

•  алгоритмические связи показателей;

•  лингвистические отношения;

•  ограничения целостности.

В предметной области в результате ее анализа выделяют классы объектов. Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств. Каждый объект в информационной системе представляется своим идентификатором, а каждый класс объектов представляется именем класса. Каждый объект обладает определенным набором свойств, связь между объектами и характеризующими их свойствами изображается в виде линии.

Получение реляционной схемы из ER схемы:

Каждая простая сущность превращается в таблицу, простая сущность это сущность не являющаяся подтипом. Имя сущности становится именем таблицы.

Каждый атрибут становится возможным столбцом с тем же именем. Столбцы соответствующие необязательным атрибутам могут содержать неопределенные значения. Столбцы соответствующие обязательным атрибутам не могут.

Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.

Связи многие к одному становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.

Индексы создаются для первичного ключа внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.

6) Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

- все подтипы в одной таблице

- для каждого подтипа отдельная таблица

Применение способа один, таблица создается для наиболее внешнего супер типа, а для подтипа могут создаваться представления, в таблицу добавляются по крайней мере один столбец содержащий код типа, он становится частью первичного ключа. При использования метода 2, для каждого подтипа первого уровня супертип воссоздается с помощью предоставления UNION, после всех подтипов выбираются общие столбцы супертипа.

Все в одной таблице	Таблица - на подтип
Преимущества
Все хранится вместе Легкий доступ к супертипу и подтипам Требуется меньше таблиц	Более ясны правила подтипов Программы работают только с нужными таблицами
Недостатки
Слишком общее решение Требуется дополнительная логика работы с разными наборами столбцов и разными ограничениями Потенциальное узкое место (в связи с блокировками) Столбцы подтипов должны быть необязательными В некоторых СУБД для хранения неопределенных значений требуется дополнительная память	Слишком много таблиц Смущающие столбцы в представлении UNION Потенциальная потеря производительности при работе через UNION Над супертипом невозможны модификации