Введение в системы БД (542480), страница 131
Текст из файла (страница 131)
Это утверждение можно обосновать приведенными ниже доводами. ° Фундаментальный элемент данных в ЕК-модели, т.е. ее фунламеитальный формальный элемент, существующий в противоположность неформальным элементам (" сущностям", "связям" и т.д.), — это отношение степени и. ° Операторы ЕК-модели, в основном, являются операторами реляционной алгебры. (Действительно, работу (13.51 нельзя назвать очень ясной в этом отношении, но в ней предлагается менее мощное по сравнению с реляционной алгеброй множество операторов, срели которых, например, не существует объединения и явно заданного соелинения.) ° Именно в вопросах целостности эти два подхода в некоторой степени отличаются один от другого: ЕК-модель содержит набор встроенны» правил целостности, соответствующих некоторым (но не всем) описанным в этой книге правилам, необходимым для внешнего ключа.
Таким образом, там, где для "чистой" реляционной системы потребовалось бы явно сформулировать некоторые правила для внешних ключей, для ЕК-модели достаточно было указать, что данная переменная- отношение имеет некоторый тип,— и соответствую1цие правила для внешних ключей были бы задействованы. Сравнительный анализ сущностей и связей В этой книге уже несколько раз отмечалось, что "связи" лучше всего рассматривать просто как сущности определенного рода. И наоборот, обязательным условием использования ЕК-модели является то, что эти два понятия должны каким-то образом различаться. По мнению автора, любой подход, при котором преследуется такое разделение, обладает серьезными недостатками, поскольку, как отмечалось выше, в разделе!3.2, один и тот же элемент может совершенно справедливо рассматриваться как сущность одними пользователями и как связь — другими.
В частности, рассмотрим следующий пример с заключением брака. ° С одной стороны, очевидно, что браком называется некоторая связь между двумя людьми. В качестве примера можно привести запрос "С кем вступила в брак Элизабет Тейлор в 1975 году?". ° С другой стороны, не менее очевидно, что брак является сущностью определенного типа. В качестве примера можно привести следующий запрос: "Сколько браков было заключено в этой церкви с апреля?". этот счет из работы 1'13.221: "Декларативные процессы очень сложны для того, чтобы и» можно было аыразнть в анде части бизнес-модели, а потому они должны быть определены отдельно аналитиком!разработчиком".
При этом все егце остается в силе аргумент, что проектирование базы данны» дотжно былин процессом точного определения приемлемы» ограничений 1см. 1К!81', 1В. 191', 113. 1П вЂ” 113. 19/1. 524 Часть 1П. Проектирование базы данных Если в методике проектирования базы данных между сущностями и связями предполагается наличие определенных различий, то в лучшем случае эти две интерпретации будут рассматриваться асимметрично (т.е. запросы для "сущностей" и запросы для "связей" будут выглллеть совершенно по-разному). В худшем случае одна интерпретация вовсе не будет поддерживаться (т.е.
один из классов запросов сформулировать будет невозможно). В качестве еще одной иллюстрации рассмотрим следующее утверждение из учебного пособия по ЕК-моделированию (13.! 7). "Обычно в начале, в проне«се разработки коннептуальной сх«ны, некоторые связи представляются в виде атрибутов 1которые в данном случае означают внешние ключи7. Затем зти атрибуты преобразуются в связи по мере дальнейшей разработки проекта и углубления понимания его особенностей." Но что произойдет, если атрибут станет внешним ключом позже, т.е.
если база данных будет изменена уже после того, как она использовалась в течение некоторого времени? Если эту идею логически развивать, то можно прийти к выводу, что макет базы данных должен содержать связи и совсем не содержать атрибутов. (На самом деле эта позиция обладает некоторыми достоинствами; см. аннотацию к [13.18) в конце этой главы.) Заключительные замечания Помимо описанной в этой главе схемы ЕК-моделирования, существует много других семантических схем моделирования. Однако большинство нз них очень похожи одна на другую; в частности, многие из них можно характеризовать просто как тот или иной вариант графических обозначений для представления некоторых ограничений для внешних ключей, плюс несколько иных дополнительных компонентов.
Безусловно, подобные графические компоненты могут быть полезны для представления "всей картины в целом", но они слишком просты, чтобы с их помощью можно было выполнить все необходимые проектировочные работыь. В частности, как отмечалось выше, они обычно не подходят лля определения общих ограничений целостности. Например, как можно было бы представить на ЕК-лиаграмме наличие зависимости соединения? 13.7. Резюме Эта глава начиналась с краткого введения в общие идеи семантического моделировании.
В целом, данный процесс состоит из четырех перечисленных ниже этапов, первый из которых является неформальным, а остальные — формальными. 1. Идентифицировать полезные семантические концепции. 2. Определить формальные объекты. 3. Определить формальные правила поддержки целостности данных ("метаограничения"). 4. Определить формальные операторы. В Печально, но простые решения остаются очень популярными далее тогда, когда они чрезмерно просты. В таких случаях молсно согласиться с Эйнштейном, который однажды заметил, что "все вещи следует делам~ настольно простыми, насколько зто возмозя.но, но не проще". 525 Глава з 3.
Семанпзическое моделирование В качестве примера полезных семантических концепций можно назвать концепции сущности, свойства, связи и подтипа. Замечание. Следует особо подчеркнуть, что между неформальным уровнем семантического моделирования и базовым формальным системным уровнем весьма вероятно появление терминологических конфликтов и что наличие подобных конфликтов часто приводит к путанице. Основная цель исследований в области семантического моделирования состоит в том, чтобы сделать СУБД более "разумными".
А более конкретная цель заключается в предоставлении некоторого систематического подхода к решению проблемы проектирования базы данных. В настоящей главе было описано применение одной из "семантических" моделей, предложенной Ченом для решения указанной проблемы, а именно — модель "сущность/связь", иначе называемая ЕК-моделью. В связи со сказанным выше стоит повторить мысль о том, что первая статья о ЕК- моделировании [13.5) на самом деле содержала два различных, более или менее независимых, предложения: сачу ЕК-модель, а также технологию диаграммного ЕК- моделирования. Как было отмечено в разделе 13.4, широкую популярность ЕК-модели, скорее всего, можно объяснить именно наличием этой технологии использования диаграмм, а не какой-либо другой причиной. Однако для использования технологии Ейдиаграим совсем не обязательно принимать все идеи этой модели.
Данные диаграммы можно применять в качестве основы в любой методике проектирования, например в методике на основе КМIТ-модели, описанной в (13.6). Эта особенность часто упускается из виду при сравнении удобства использования ЕК-модели и других методик, разработанных для проектирования базы ланных. Сравним теперь идеи семантического моделирования (и ЕК-модель в частности) с методом нормализации, описанным в главах 11 и 12. Метод нормализации предусматривает приведение больших переменных-отношений к набору переменных-отношений меньшего размера. При этом предполагается, что на исходном этапе имеется небольшое количество больших переменных-отношений, которые после выполнения определенных операций к завершающему этапу будут преобразованы в множество малых переменных- отношений, т.е. произойдет отображение больших отношений в малые (это, конечно же, очень приблизительная формулировка).
Однако метод нормализации не содержит никаких упоминаний о том, каким именно образом могут быть получены исходные большие переменные-отношения. Нисходящие методики, подобные описанной в настоящей главе, предназначены для решения именно этой проблемы, т.е. они позволяют отобразить некоторую предметную область реального мира на набор больших переменных-отношений. Иначе говоря, эти два подхода дополняют друг друга. Таким образом, общая процедура проектирования базы данных включает два следующих этапа. 1.
Использование метолов ЕК-моделирования (или лругой аналогичной методики) для создания "больших" переменных-отношений, представляющих сильные сущности, слабые сущности и т.д. 2. Использование идей дальнейшей нормализации для разбиения созданных "больших" переменных-отношений на "малые". Однако из особенностей проведенного в данной главе обсуждения можно сделать вывод, что в общем случае семантическое моделирование не является такой же строгой и ясной дисциплиной, как методика дальнейшей нормализации, описанная в главах!1 526 Часть |П.
Проектирование базы данных Упражнения 13.1. Что означает термин "семантическое моделирование"? 13.2. Перечислите четыре основных этапа разработки определения любой "расширенной" модели, подобной технологии ЕК-моделирования. !3.3. Дайте определение следующим терминам ЕК-модели. иерархия типов ключевое свойство связь сильная сушность слабая сушность супертипlподтип набор значений наследование свойство сушность 13.4. Приведите примеры связей следующих типов: а) связь типа "многие ко многим', в которой один из участников является слабой сущностью; б) связь типа "многие ко многим', в которой один из участников является другой связью; в) связь типа "многие ко многим", имеюшая собственный подтип; г) подтип, связанный со слабой сущностью, которая не зависит от его супертипа.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
