ER-модель используется на ранних стадиях разработки проекта. Если понимать язык условных обозначений, то ее легко можно читать, следовательно, она доступна для анализа программиста-разработчика. Она имеет однозначную интерпретацию в отличие от некоторых предложений естественного языка.
Для разработки компьютерных реализаций любых задач предпочтительно выражение мыслей на некотором формальном языке, который обеспечивает однозначную их трактовку. Таким языком для программистов часто служит алгоритм, который может быть реализован на разных языках программирования. Таким формальным языком для описания БД и стал язык ER-модели.
Но кроме строгих правил для представления ER-модели необходимы правила преобразования ее в реляционную, как наиболее распространенную для компьютерной реализации.
Рассмотрим эти правила.
1. Каждой сущности ставится в соответствие таблица реляционной модели данных. Имена их могут не совпадать, т.к. на имена сущностей не наложены ограничения, а на имена таблиц - наложены в конкретной СУБД.
2. Каждый атрибут сущности становится полем соответствующей таблицы. С именами – та же ситуация. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность (то есть допустимость или недопустимость пустых значений).
3. Ключевой атрибут сущности становится первичным ключом соответствующей таблицы.
4. В каждую таблицу, соответствующую подчиненной сущности (т.е. связанной с другой как 1:М), добавляется ключевой атрибут (или множество атрибутов) основной сущности. В таблице эти атрибуты будут внешним ключом.
5. Для моделирования частичного участия сущности в связи (необязательное участие) для внешнего ключа указывается допустимость пустых значений. При полном участии – недопустимость.
6. При преобразовании супертипов и подтипов в таблицы возможны два варианта:
1 вариант: создается одна таблица для всех подтипов одного супертипа. В него включают все атрибуты всех подтипов. Но тогда для ряда экземпляров некоторые атрибуты не будут иметь смысла. Достоинство такого представления в том, что создается одна таблица.
2 вариант: для каждого подтипа и для супертипа создаются отдельные таблицы. Недостаток в том, что получается много таблиц. Но зато работать можно только со значимыми атрибутами подтипа. В этом случае между таблицами супертипа и подтипов устанавливается связь (часто связь эта типа 1:1, т.е. связываются первичные ключи супертипа и подтипов).
НАПРИМЕР:
Преподаватели Сотрудники ТехПерсонал
Табельный№ Табельный№ Табельный№
Специальность Фамилия Должность
Ученая степень Имя
Разряд Отчество
ДатаПринятия
Оклад
7. Реализация связи М:М требует отдельного подхода, т.к. в реляционных моделях такая связь напрямую не может быть представлена. Здесь эта связь реализуется путем введения дополнительной связующей таблицы, которая связана с каждой исходной таблицей связью 1:М. Эта дополнительная таблица состоит из ключевых атрибутов исходных таблиц, причем эти атрибуты образуют составной первичный ключ.
НАПРИМЕР, связь Студенты-Кружки/Секции.
На практике построенные ER-модели в любом случае носят субъективный характер и нельзя сказать, что они полностью точны. Но такие модели служат переходным звеном от реального мира к формализованной реляционной БД, т.е. помогают разработчику учесть требования заказчика и максимально откорректировать модель еще до ее компьютерной реализации.
