13.6. Краткий анализ er-модели

В этом разделе кратко рассматриваются некоторые определенные аспекты ER-модели. Большая часть излагаемого здесь материала взята из другой работы автора [13.8], в которой эта тема обсуждается подробнее. Дополнительные сведения и комментарии можно найти в аннотациях, помещенных в список рекомендуемой литературы к данной главе.

ER-модель как основа реляционной модели

Рассмотрим подход с использованием ER-модели с несколько иной точки зрения. Надо полагать, вполне очевидно, что идеи, послужившие основанием для разработки этого подхода, во многом очень близки тем идеям, которые послужили Кодду нефор­мальной основой при создании им исходной формальной реляционной модели. Как уже объяснялось в разделе 13.2, общий подход к разработке "расширенных" моделей включает четыре больших этапа; назначение каждого из них можно кратко сформули­ровать следующим образом.

1. Идентифицировать полезные семантические концепции.

2. Определить формальные объекты.

3. Определить формальные правила поддержки целостности данных ("метаограничения").

4. Определить формальные операторы.

Обратите внимание, что эти этапы вполне применимы и для разработки базовой реляционной модели (а также для любой другой формальной модели данных), а не только для "расширенных" моделей, подобных ER-модели. Иначе говоря, для того чтобы создать формальную базовую реляционную модель, Кодд прежде всего должен был выявить некоторые неформальные "полезные семантические концепции". Эти концепции в основе своей были близки идеям ER-моделированя или чему-то очень

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

"Множество сущностей заданного типа сущности можно рассматривать как отношение, и такое отношение мы будем называть отношением типа сущно­сти... Оставшиеся отношения... между типами сущностей... называются меж­сущностными отношениями... Важнейшим свойством каждого межсущност­ного отношения является то, что [оно содержит по крайней мере два внешних ключа, которые] обращаются к различным типам сущностей либо к общему типу сущности, выполняющему различные роли. "

Здесь Кодд явно предлагает использовать отношения для моделирования и "сущ­ностей", и "связей". Но самое главное заключается в том, что отношения являются формальными объектами, а реляционная модель — формальной системой. Ценность на­учного вклада Кодда состоит в том, что он нашел удачную формальную модель для оп­ределенных аспектов реального мира.

В противоположность этому ER-модель не является (или, по крайней мере, не в пер­вую очередь является) формальной моделью. Фактически она состоит из набора пре­имущественно неформальных концепций, соответствующих только первому из четырех приведенных выше этапов. (Более того, ее формальные аспекты на самом деле не очень значительно отличаются от соответствующих аспектов основной реляционной модели; обсуждение этого вопроса будет продолжено ниже.) Для проектирования базы данных, конечно, полезно иметь в своем распоряжении, помимо всего прочего, набор концепций, определенных на этапе 1. Однако несомненным остается тот факт, что проектирование базы данных не может быть завершено без применения формальных объектов и правил, представленных на этапах 2 и 3, а множество других задач и вовсе не может быть реше­но без использования формальных операторов, определяемых на этапе 4. • Следует отметить, что перечисленные выше замечания не предполагают доказатель­ства бесполезности ER-модели; скорее всего, наоборот. Однако одной этой модели не­достаточно. Более того, несколько странным кажется тот факт, что первые описания не­формальной ER-модели были опубликованы спустя несколько лет после опубликования описания формальной реляционной модели, изначально основанной (как мы видели) на некоторых идеях ER-модели.

Является ли ER-модель моделью данных

Из вышеизложенного не совсем ясно, является ли ER-модель на самом деле моде­лью данных, по крайней мере в предложенном в этой книге смысле (т.е. формальной системой, включающей структурные аспекты, аспекты поддержания целостности и манипулирования данными). Конечно, термин "ER-моделирование" обычно использу­ется для обозначения процесса выбора только структуры базы данных, хотя выше, в разделах 13.3-13.5¹¹, рассматривались и некоторые аспекты целостности (они, в основ­

ном, относились к первичным и внешним ключам). Однако при более внимательном чтении работы [13.5] можно предположить, что ER-модель действительно является моделью данных, но такой, которая представляет собой лишь тонкий слой на вершине базовой реляционной модели (и, конечно, не может заменить реляционную модель, как хотелось бы некоторым авторам). Это утверждение можно обосновать приведен­ными ниже доводами.

• Фундаментальный элемент данных в ER-модели, т.е. ее фундаментальный фор­мальный элемент, существующий в противоположность неформальным элементам ("сущностям", "связям" и т.д.), — это отношение степени п.

• Операторы ER-модели, в основном, являются операторами реляционной алгебры. (Действительно, работу [13.5] нельзя назвать очень ясной в этом отношении, но в ней предлагается менее мощное по сравнению с реляционной алгеброй множество операторов, среди которых, например, не существует объединения и явно задан­ного соединения.)

• Именно в вопросах целостности эти два подхода в некоторой степени отличаются один от другого: ER-модель содержит набор встроенных правил целостности, со­ответствующих некоторым (но не всем) описанным в этой книге правилам, необ­ходимым для внешнего ключа. Таким образом, там, где для "чистой" реляционной системы потребовалось бы явно сформулировать некоторые правила для внешних ключей, для ER-модели достаточно было указать, что данная переменная-отношение имеет некоторый тип, — и соответствующие правила для внешних ключей были бы задействованы.

Сравнительный анализ сущностей и связей

В этой книге уже несколько раз отмечалось, что "связи" лучше всего рассматривать просто как сущности определенного рода. И наоборот, обязательным условием исполь­зования ER-модели является то, что эти два понятия должны каким-то образом разли­чаться. По мнению автора, любой подход, при котором преследуется такое разделение, обладает серьезными недостатками, поскольку, как отмечалось выше, в разделе 13.2, один и тот же элемент может совершенно справедливо рассматриваться как сущность одними пользователями и как связь — другими. В частности, рассмотрим следующий пример с заключением брака.

• С одной стороны, очевидно, что браком называется некоторая связь между двумя людьми. В качестве примера можно привести запрос "С кем вступила в брак Эли­забет Тейлор в 1975 году?".

• С другой стороны, не менее очевидно, что брак является сущностью определенно­го типа. В качестве примера можно привести следующий запрос: "Сколько браков было заключено в этой церкви с апреля?".

этот счет из работы [13.27]: "Декларативные процессы очень сложны для того, чтобы их можно было выразить в виде части бизнес-модели, а потому они должны быть определены отдельно аналитиком/разработчиком". При этом все еще остается в силе аргумент, что проектирование базы данных должно быть процессом точного определения приемлемых огра­ничений (см. [8.18], [8.19], [13.17]-[13.19]).

Если в методике проектирования базы данных между сущностями и связями предполагается наличие определенных различий, то в лучшем случае эти две интер­претации будут рассматриваться асимметрично (т.е. запросы для "сущностей" и за­просы для "связей" будут выглядеть совершенно по-разному). В худшем случае одна интерпретация вовсе не будет поддерживаться (т.е. один из классов запросов сфор­мулировать будет невозможно).

В качестве еще одной иллюстрации рассмотрим следующее утверждение из учебного пособия по ER-моделированию [13.17].

"Обычно в начале, в процессе разработки концептуальной схемы, некоторые связи представляются в виде атрибутов [которые в данном случае означают внешние ключи]. Затем эти атрибуты преобразуются в связи по мере дальней­шей разработки проекта и углубления понимания его особенностей. "

Но что произойдет, если атрибут станет внешним ключом позже, т.е. если база дан­ных будет изменена уже после того, как она использовалась в течение некоторого време­ни? Если эту идею логически развивать, то можно прийти к выводу, что макет базы дан­ных должен содержать связи и совсем не содержать атрибутов. (На самом деле эта пози­ция обладает некоторыми достоинствами; см. аннотацию к [13.18] в конце этой главы.)

Заключительные замечания

Помимо описанной в этой главе схемы ER-моделирования, существует много других семантических схем моделирования. Однако большинство из них очень похожи одна на другую; в частности, многие из них можно характеризовать просто как тот или иной ва­риант графических обозначений для представления некоторых ограничений для внешних ключей, плюс несколько иных дополнительных компонентов. Безусловно, подобные графические компоненты могут быть полезны для представления "всей картины в це­лом", но они слишком просты, чтобы с их помощью можно было выполнить все необхо­димые проектировочные работы¹². В частности, как отмечалось выше, они обычно не подходят для определения общих ограничений целостности. Например, как можно было бы представить на ER-диаграмме наличие зависимости соединения?