ном, относились к первичным и внешним ключам). Однако при более внимательном чтении работы [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-диаграмме наличие зависимости соединения?

13.7. Резюме

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

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

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

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

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

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

в качестве примера полезных семантических концепций можно назвать концепции сущности, свойства, связи и подтипа.

Замечание. Следует особо подчеркнуть, что между неформальным уровнем семантического моделирования и базовым формальным системным уровнем весьма вероятно появление терминологических конфликтов и что наличие подобных конфликтов часто приводит к путанице.

Основная цель исследований в области семантического моделирования состоит в том, чтобы сделать СУБД более разумными . А более конкретная цель заключается в предоставлении некоторого систематического подхода к решению проблемы проектирования базы данных. В настоящей главе было описано применение одной из семантических моделей, предложенной Ченом для решения указанной проблемы, а именно - модель сущность/связь , иначе называемая ER-моделью.

В связи со сказанным выше стоит повторить мысль о том, что первая статья о ER-моделировании [13.5] на самом деле содержала два различных, более или менее независимых, предложения: саму ER-модель, а также технологию диаграммного ER-моделнрования. Как было отмечено в разделе 13.4, широкую популярность ER-модели, скорее всего, можно объяснить именно наличием этой технологии использования диаграмм, а не какой-либо другой причиной. Однако для использования технологии ЕЯ-диаграмм совсем не обязательно принимать все идеи этой модели. Данные диаграммы можно применять в качестве основы в любой методике проектирования, например в методике на основе RM/T-модели, описанной в [13.6]. Эта особенность часто упускается из виду при сравнении удобства использования ER-модели и других методик, разработанных для проектирования базы данных.

Сравним теперь идеи семантического моделирования (и ER-модель в частности) с методом нормализации, описанным в главах И и 12. Метод нормализации предусматривает приведение больших переменных-отношений к набору переменных-отношений меньшего размера. При этом предполагается, что на исходном этапе имеется небольшое количество больших переменных-отношений, которые после выполнения определенных операций к завершающему этапу будут преобразованы в множество малых переменных-отношений, т.е. произойдет отображение больших отношений в малые (это, конечно же, очень приблизительная формулировка). Однако метод нормализации не содержит никаких упоминаний о том, каким именно образом могут быть получены исходные большие переменные-отношения. Нисходящие методики, подобные описанной в настоящей главе, предназначены для решения именно этой проблемы, т.е. они позволяют отобразить некоторую предметную область реального мира на набор больших переменных-отношений. Иначе говоря, эти два подхода дополняют друг друга. Таким образом, общая процедура проектирования базы данных включает два следующих этапа.

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

2. Использование идей дальнейшей нормализации для разбиения созданных больших переменных-отношений на малые .

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