Главная » SQL, Базы данных » КРАТКИЙ АНАЛИЗ ER-МОДЕЛИ

0

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

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

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

1.             Выявление полезных семантических концепций.

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

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

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

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

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

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

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

Следует отметить, что перечисленные выше замечания не следует рассматривать как стремление доказать бесполезность ER-модели; скорее всего, наоборот. Но одной этой модели недостаточно. Более того, несколько странным  кажется тот факт, что первые описания  неформальной ER-модели  были  опубликованы  спустя  несколько  лет  после опубликования описания формальной реляционной модели, изначально основанной (как мы видели) на некоторых идеях ER-модели.

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

Из изложенного выше не совсем ясно, является ли ER-модель на самом деле моделью данных, по крайней мере, в указанном в настоящей книге смысле (т.е. формальной системой, включающей структурные аспекты, а также аспекты поддержания целостности и манипулирования данными). Безусловно, термин ER-моделирование обычно используется для обозначения процесса выбора только структуры базы данных7, хотя выше, в разделах 14.3— 14.5, рассматривались и некоторые аспекты целостности (они в основном относились к

7  Фактически основная слабость здесь заключается в том, что ER-модель за исключением некоторых частных (но, по общему признанию, очень важных) случаев совершенно непригодна для работы с ограничениями целостности или бизнес-правилами. Процитируем типичное  высказывание на этот счет из работы [14.32]: "Декларативные процессы очень сложны для того, чтобы их можно было выразить в виде части бизнес-модели, а потому они должны быть  определены отдельно аналитиком-разработчиком". При этом все еще остается в силе такой довод, что проектирование базы данных должно быть процессом точного определения приемлемых ограничений (см. [9.21], [9.22] и [14.22]—[14.24]).

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

■     Фундаментальный элемент данных в ER-модели, т.е. ее фундаментальный фор мальный объект, существующий в противоположность неформальным объектам

{сущностям, связям и т.д.), — это отношение степени п.

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

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

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

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

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

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

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

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

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

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

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

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

14.1.     .  РЕ ЗЮМЕ

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

1.          Выявление полезных семантических концепций.

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

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

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

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

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

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

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

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

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

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

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

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

"больших" переменных отношения на "малые".

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

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

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

В заключение следует упомянуть еще один очень важный момент. Несмотря на заявление, что эта область исследований все еще остается очень субъективной, в ней есть одна особая часть, в которой идеи семантического моделирования в настоящее время могут быть весьма уместными и полезными. Речь идет о словаре данных, который в определенном смысле можно рассматривать как "базу данных для разработчика баз данных". В словаре данных разработчик может хранить сведения о решениях, принятых в процессе проектирования базы данных  [14.2]. Таким образом, изучение семантического моделирования может оказаться чрезвычайно полезным для проектирования системы управления словарем  данных, поскольку в нем могут быть указаны типы сущностей, которые словарь должен поддерживать и описывать, например, категории сущностей (такие как обычные и слабые сущности в ER-модели), правила целостности (такие как полное или частичное участие в связи ER-модели), супертипы и подтипы сущностей и т.д.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии