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

vPa6oTHHKl

+-живет в Городе! +-родился в Стране!

+-руководит работой Работника2, который +-живет в Городе! +-родился в Стране2 <> Стране!

Этот запрос означает: Извлечь данные о сотрудниках, руководящих работой других сотрудников, которые живут в том же городе, что и их руководитель, но родились в другой стране . Автор предлагает попробовать сформулировать этот запрос на языке SQL!

Наконец, в отношении языка ConQuer и бизнес-правил автор говорит: Хотя фафи-ческие обозначения ORM-модели могут выразить больше бизнес-правил, чем [ER-модель], их все еще приходится дополнять текстовым описанием [для выражения некоторых Офаничений]. В настоящее время продолжаются исследования, проводимые в направлении адаптации языка ConQuer для достижения указанной цели . 13.20.Hammer М.М., McLeod D. J. The Semantic Data Model: A Modelling Mechanism for Database Applications Proc. 1978 ACM SIGMOD Intern. Conf on Management of Data. - Austin, Texas. - May-June, 1978.

Семантическая модель данных (Semantic Data Model - SDM) представляет собой другой формальный подход к проектированию базы данных. Как и в случае ER-моделирования, в этой модели основное внимание уделяется структурным аспектам и аспектам целостности и совсем немного внимания (или вообще никакого) - аспектам манипулирования данными (операторам). Об этом также можно прочесть в [13.21], [13.24].

13.2LHammer М., McLeod D. Database Description with SDM: A Semantic Database Model ACM TODS. - September, 1981. - 6, № 3. Cm. комментарий к [13.20].

13.22.Hull R., King R. Semantic Database Modeling: Survey, Applications, and Research Issues ACM Сотр. Surv. - September, 1987. - 19, № 3.

Исчерпывающее учебное пособие по семантическому моделированию. Эта статья является прекрасной отправной точкой для изучения семантического моделирования и связанных с ним проблем и тем.

13.23.Jacobson I. et al. Object-Oriented Software Engineering (revised printing). - Reading. Mass.: Addison-Wesley, 1994.

В этой работе описывается метод проектирования Object-Oriented Software Engineering (OOSE). Так же, как и при использовании ОМТ-модели [13.3], компоненты OOSE (по крайней мере, имеющие отнощение к базам данных) могут рассматриваться как вариация ER-модели (как и в случае с ОМТ-моделью, OOSE-объекты соответствуют ЕК-сущностям). Приведем следующую цитату: Больщинство используемых сегодня методов разработки как информационных, так и технических систем основано на функциональной декомпозиции этой системы и/или декомпозиции на основе используемых данных. Такие подходы сильно отличаются от объектно-ориентированных методов, в которых данные и функции тесно связаны . Похоже, что здесь автор указывает на существенное отличие между объектным подходом и подходом на основе использования базы данных. Предполагается, что базы данных, по крайней мере совместно используемые базы данных общего назначения, которым уделяется больще всего внимания со стороны специалистов в области баз данных, отделены от функций , т.е. предполагается, что базы данных проектируются независимо от приложений, в которых они будут использоваться. Тем не менее мы считаем, что специалисты в области объектно-ориентированного подхода употребляют термин база данных в непосредственной связи с конкретным приложением, а не как совместно используемую базу данных общего назначения.

См. также аннотацию к [13.32] и обсуждение объектных баз данных в главе 24.

13.24. Jagannathan D. et al. SIM: A Database System Based on the Semantic Data Model Proc. 1988 ACM SIGMOD Intern. Conf. on Management of Data. - Chicago, 111., June, 1988. Описание коммерческой СУБД, которая построена на основе семантической модели данных, предложенной Хаммером и Мак-Лео дом в [13.20].

13.25. Keuffel W. Battle of the Modeling Techniques: A Look at the Three Most Popular Modeling Notations for Distilling the Essence of Data DBMS. - August, 1996. - 9, № 9. Тремя наиболее популярными системами обозначения являются ER-модель, NIAM-метод [13.29] и SOM-метод. Автор утверждает, что ER-модель является дедущкой двух других моделей, но одновременно подвергает ее критике в связи с отсутствием необходимого формального обоснования. Например, сущности, связи и атрибуты (т.е. свойства) описываются без упоминания о том, как они были открыты . NIAM-метод является гораздо более строгим. Если строго следовать правилам этой модели, можно получить концептуальный макет, который обладает гораздо большей целостностью , чем макеты, полученные на основе других моделей, хотя некоторые разработчики могут посчитать строгость NIAM-модели чрезмерно ограничивающей (!). SOM-модель напоминает ER-модель... из-за [аналогичной] нестрогой формулировки определений сущностей, атрибутов и связей . Но она отличается от ER-модели тем, что в ней поддерживаются групповые атрибуты (т.е. на самом деле повторяющиеся фуппы), позволяющие одному объекту (т.е. сущности) содержать другие. (В ER-модели сущность может содержать повторяющиеся группы атрибутов, но не других сущностей.)

13.26.Mannila П., Raiha K.-J. The Design of Relational Databases. - Wokingham, UK: Addison-Wesley, 1992.

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

Принципы проектирования

Офаничения целостности и зависимости

Свойства реляционных схем

Аксиоматизация зависимостей

Алгоритмы для задач проектирования

Отображения между ER-диафаммами и схемами реляционных баз данных

Преобразования схем

Примеры проектирования баз данных

Описанные в книге технологии были воплощены ее авторами в виде коммерчески распространяемого инструмента проектирования Design By Example (макет по образцу).

13.27.Moriarty Т. Enteфrise View (regular column) DBP&D. - August, 1997. - 10, № 8. В этой работе описан коммерческий инструмент проектирования и разработки приложений Usoft (www.usoft.com), который позволяет определять бизнес-правила с помощью SQL-подобного синтаксиса, а затем использовать их для генерации приложения (включая создание определения базы данных).

13.28.Nijssen СМ., Duke D.J., Twine S.M. The Entity-Relationship Data Model Considered Harmful Proc. 6th Symposium on Empirical Foundations of Information and Software Sciences. - Atlanta, Ga., 1988.

Может ли использование ER-модели привести к пагубным последствиям? Мы можем дать несколько подтверждений положительного ответа на этот вопрос, включая следующие.

Путаница между типами и переменными-отношениями (см. обсуждение в разделе 25.2 в главе 25)

Странная ситуация с подтаблицами и супертаблицами [13.12]

Широкое расхождение с принципом относительности базы данных (см. главу 9)

Путаница между сущностями и связями, обсуждавшаяся выше в этой главе

В данной работе этот перечень недостатков ER-модели был расширен.

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

Нет никаких критериев выбора одного из нескольких альтернативных представлений, что на практике может иметь весьма нежелательное следствие: необходимость внесения изменений в уже завершенный проект при изменении определенных обстоятельств.

Имеется слишком мало способов представления требований поддержки целостности данных, что делает неосуществимыми некоторые аспекты процесса проектирования ( [действительно] Офаничения могут быть формально выра-