6.3. Язык odl

Разработка базы данных в терминах реляционной модели часто сводится к сложному и неудобному для проектировщика процессу, поскольку эти модели не содержат достаточно средств для представления смысла данных. Такое положение вещей приводит к замедлению процесса разработки БД и является источником потенциальных ошибок. Семантика реальной предметной области должна независимым от модели способом представляться в сознании ее создателя. Поэтому в последнее время получило развитие семантическое моделирование. Основная цель такого подхода – организация интерфейса проектировщика, а также конеч-ного пользователя с информационной системой на уровне представлений в пределах предметной области, а не на уровне структур данных. Наиболее популярными инфологическими, или как их еще называют семантическими, моделями являются объектно-ориентированная модель и модель "сущность-связь". Сочетая в себе предметную наглядность и теоретическую обоснованность, они являются мощным инструментом проектирования баз данных. Данные подходы находят все большее воплощения в конкретных системах управления базами данных.

Для определения структуры БД в объектно-ориентированных терминах многими специалистами используется язык ODL (Object Definition Language - язык определения объектов). OQL – Object Query Language (язык объектных запросов) и OML – Object Manipulation Language (язык манипулирования объектами). Главное назначение ODL – обеспечить запись объектно-ориентированных проектов с последующим прямым переводом в выражения объектно-ориентированной СУБД (OODBMS). Как правило, основным языком таких систем является C++ или Object Pascal, поэтому ODL необходимо переводить в выражения этих языков. ODL соответствует им обоим (но больше C++), поэтому указанный перевод достаточно прост. Значительно сложнее осуществлять перевод из ODL или проектов, реализованных в терминах модели "сущность-связь", в выражения, систем управления реляционными базами данных (RDBMS). Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, Visual Basic .NET, Objective-C и Smalltalk и др.

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

Для построения адекватной модели предметной области, как правило, необходимо определить классы объектов, в рамках которых объекты обладают сходными свойствами. Понятия "объект" и "класс" в БД по сути дела совпадают с этими понятиями в языках объектно-ориентированного программирования (ООП).

Элементы и понятия реального мира, представляемые объектами класса, должны быть сходными. Все объекты одного класса должны иметь одинаковый набор свойств. Можно считать, что объекты имеют поля (слоты), в которых размещены значения. Такими значениями могут быть целые числа, строки или массивы, ссылки на другие объекты, а также методы, т.е. функции, применяемые к объектам.

Определяя проект классов ODL, описывают свойства следующих видов.

Атрибуты – свойства, типы которых строятся из исходных типов, например целых чисел или строк. Характерно то, что атрибут имеет тип, не включающий в себя ни одного класса. В ODL типы атрибутов ограничены.

Связи – свойства, типом которых являются ссылка на объект некоторого класса или набор (например, множество) таких ссылок.

Методы – функции, которые можно применить к объектам класса. В данном изложении применение методов не рассматривается.

Описания класса в ODL в их простейшей форме состоят из следующих элементов:

1. Ключевого слова interface.

2. Имени интерфейса (т.е. класса).

3. Списка свойств класса, заключенного в скобки.

Простая форма описания интерфейса.

interface <имя>{

<список свойств>}

Запись атрибутов выглядит следующим образом.

interface <имя> {

attribute string <имя>;

attribute integer <имя>;

attribute enum <имя>{х, у, z (перечень значений)}

<имя перечислителя>; };

Строка 1 описывает класс. Ключевое слово interface используется в ODL для выражения класса. За строкой 1 следуют описания трех атрибутов, которые имеют объекты класса. После ключевого слова аttribute указывается его тип (string - строка символов, integer - целое, enum – перечисляемое).

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

attribute Struct <имя>

{string <имя>, integer <имя>, string <имя>,

string <имя>, integer <имя>} <имя>;

Атрибуты объекта играют большую роль, однако иногда важнее знать то, как они связаны с объектами того же самого или другого класса.

relationship Set <имя объекта> <имя множества ссылок>

Ключевое слово relationship определяет, что <множество ссылок> содержит ссылки на другие объекты, а ключевое слово Set, предшествующее <имя объекта>, показывает, что <множество ссылок> ссылается на множество объектов <имя объекта>, а не на единственный объект. В общем случае в ODL тип, являющийся множеством элементов другого типа Т, определяется ключевым словом Set и угловыми скобками, выделяющими тип Т.

При описании обратных связей, в описании каждой связи указывается ключевое слово inverse и имя другой связи. Если одна из связей находится в другом классе, как это обычно и бывает, ссылка на нее делается с помощью имени этого класса, за которым следуют двойное двоеточие (::) и имя связи.

Необходимо учитывать, что данный объект связан с единственным объектом или он может быть связан с множеством других объектов. В ODL эти возможности определяются тем, применяется или нет в описании связи оператор множества типа Set. При наличии обратимой пары связей существует четыре возможности: связь может иметь тип "один-к-одному", "один-ко-многим", или "многие-ко-многим".

Требования уникальности связи и ее обращения называются множественностью связей. Наиболее распространенные варианты.

1. Связь типа "многие-ко-многим" класса С с классом D – это связь, в которой с каждым объектом класса С ассоциируется множество объектов класса D, а в ее обращении с каждым объектом класса D ассоциируется множество объектов класса С. В любом направлении связи допускается пустое множество.

2. Связь типа "многие-к-одному" класса С с классом D – это связь, в которой для каждого объекта класса С существует уникальный объект класса D, но в ее обращении с каждым объектом класса D связаны многие С.

3. Связь типа "один-к-одному" класса С с классом D – это связь, в которой для каждого объекта класса С существует уникальный объект класса D.

В обратной связи каждый объект класса D связан с уникальным объектом класса С. При описании связей следует иметь в виду, что связь типа "многие-к-одному" – это частный случай связи типа "многие-ко-многим", а связь типа "один-к-одному" – частный случай связи типа "многие-к-одному". Любое полезное свойство связей типа "многие-ко-многим" применимо к связям типа "многие-к-одному", а полезные свойства последних верны и для связей типа "один-к-одному". Например, структура данных для представления связей типа "многие-к-одному" подходит для связей типа "один-к-одному", но может быть непригодна для связи типа "многие-ко-многим".

Используя термины типа "уникальный" или "один" при определении связей типа "многие-к-одному" или "один-к-одному" необходимо учитывать некоторую неопределенность. Важно считать, что "уникальный" или "один" элемент реально существует. Значение "null" часто допускается в БД там, где предполагается наличие истинного значения. Например, в терминологии традиционного программирования указатель "null" может стоять там, где предполагается указатель на единственный объект.

Средства ODL предоставляют проектировщику систему типов, подобную системам типов языка С или других популярных языков программирования. Система типов строится из базовых типов, которые определены сами по себе, с помощью конкретных рекурсивных правил (сложные типы строятся из более простых). Базовые типы ODL:

1. Атомарные типы: целое число с плавающей точкой, символ, строка символов, булево выражение и перечисление. Последний тип – это список имен, объявленных синонимами целых чисел.

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

Базовые типы комбинируются в структурные типы с помощью следующих конструкторов типов:

1. Множество. Если T - любой тип, то Set<T> обозначает тип, значениями которого являются все конечные множества элементов типа Т.

2. Мультимножество. Если Т – любой тип, то Bag<T > обозначает тип, значениями которого являются все мультимножества элементов типа Т. Мультимножество допускает многократное повторение одного и того же элемента. Например, {1, 2, 1} – это мультимножество, а не множество, так как 1 повторяется в нем дважды.

3. Список. Если Т – любой тип, то List<T> обозначает тип, значениями которого являются конечные списки, состоящие из нуля или более элементов типа Т. В специальном случае тип string является сокращением типа List<char>.

4. Массив. Если Т – любой тип, то Аггау<Т> обозначает тип, элементами которого является массив из i элементов типа Т. Например, Array<char,10> обозначает символьную строку длиной 10.

5. Структуры. Если Т₁,T₂, ..., Т_n являются типами, a F₁, F₂, ..., F_n именами полей, то

Struct N {Т₁F₁,T₂F₂…,T_nF_n}

обозначает тип с именем N, элементами которого служат структуры, содержащие п полей; i-е поле имеет имя F_i и тип Т_i.

Для того чтобы различать множества, мультимножества и списки следует помнить, что элементы множества не упорядочены и каждый из них входит в данное множество только один раз. Мультимножество допускает более одного вхождения любого элемента, но элементы и их вхождения не упорядочены. В списке может быть несколько вхождений одного и того же элемента, но все вхождения в нем упорядочены. Значит, {1, 3, 1} и {3, 1, 1} – это одно и то же мультимножество, но {1, 3, 1} и {3, 1, 1} – это разные списки.

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

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

Тип связи – это или тип интерфейса, или тип набора, примененный к типу интерфейса.

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

Наследование является одним из основополагающих принципов ООП. Довольно часто класс содержит объекты с особыми свойствами, не связанными со всеми членами этого класса. В данном случае рекомендуется разделить класс на подклассы, каждый из которых будет иметь собственные специальные атрибуты и/или связи в дополнение к тем, что присущи классу как единому целому.

По определению класс С является подклассом другого класса D если в описании за именем С следуют двоеточие и имя класса D. Подкласс наследует все свойства своего суперкласса (называемого также классом, из которого выводится подкласс). Другими словами, любые атрибут и связь суперкласса автоматически являются атрибутом и связью его подкласса.

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

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

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

В ODL ключ класса – это такое множество атрибутов А, что при наличии в данном классе двух различных объектов 01 и 02 они не могут иметь идентичных значений для любого атрибута в ключе К.

В ODL один или несколько атрибутов описываются как ключи класса с помощью ключевого слова key или keys (любого из них), за которым указываются атрибуты, формирующие ключ. Если в ключе больше одного атрибута, список атрибутов заключается в круглые скобки. Описание ключа должно стоять непосредственно за описанием интерфейса, перед открывающей фигурной скобкой или любыми атрибутами либо связями. Само описание ключа заключается в круглые скобки.

Вместо key можно применять keys даже если описывается только один ключ.

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

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

Согласно ограничению ссылочной целостности объект, на который есть ссылка, должен существовать. Это ограничение можно ввести по-разному.

1. Можно запретить удаление объекта, на который есть ссылка.

2. Можно потребовать, чтобы при удалении объекта, на который есть ссылка, удалялся и объект, который на него ссылается.

От объектно-ориентированной модели в большинстве случаев достаточно легко перейти к реляционной.

Пусть принимаются следующие ограничения:

- все свойства класса представляют собой атрибуты (а не отношения или методы);

- типы атрибутов атомарны (не являются структурами или множествами).

В данном случае переход к реляционной модели прост: создаются отношения с именем соответствующего класса, при этом атрибуты объектной модели переходят в атрибуты соответствующего классу отношения.

В ряде случаев не возникает проблем, даже если некоторые атрибуты не атомарны (такие как дата, перечень). Можно, например, тип "перечень" для дней недели представить целыми числами от 0 до 6.

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

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

- однозначные связи – нужно найти ключ для представления каждого из связанных объектов;

- имеются атрибуты со значением типа множества – нужно представить множество связанных объектов путем создания одного кортежа для каждого значения. При этом появляется избыточность, которая устраняется при переходе к нормальным формам более высокого порядка.

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

Немаловажную роль в инфологическом проектировании играет наглядность представляемых моделей данных. В этой связи большой популярностью разработчиков пользуются средства, основанные на графических нотациях (рис. 4), самым распространенным средством данного типа являются диаграммы "сущность-связь" (entity-relationship, E/R), которые соответствуют объектно-ориентированному подходу. Эти диаграммы имеют те же три главных компонента, о которых говорилось при описании ODL (хотя модели E/R и ODL имеют особенности, о которых речь пойдет ниже).

1. Множества сущностей, аналогичные классам. Сущности – это члены множества сущностей, аналогичные объектам ODL.

Р ис. 4. Пример диаграммы "сущность-связь"

2. Атрибуты - это значения, описывающие свойства сущности. Атрибуты в E/R и ODL – это, по сути, одно и то же понятие.

3. Связи – это соединения между двумя или более множествами сущностей. Связи в E/R аналогичны связям в ODL за следующими исключениями:

- в модели E/R одно имя приписывается связи в обоих направлениях, а в ODL отдельно определяются связь и ее обращение;

- связи в E/R могут соединять более двух множеств сущностей, а связи ODL – максимум два класса.

Для выражения множественности связей в E/R-диаграммах можно применять стрелки. Если между множествами Е и F есть связь типа "многие-к-одному", используется стрелка, указывающая на F. Она означает, что каждая сущность из множества Е связана только с одной сущностью из множества F. Однако сущность из F может быть связана с многими сущностями в Е. Связь типа "один-к-одному" между множествами Е и F выражается стрелками, указывающими и на Е, и на F.

Зачастую E/R-связи удобно изображать таблицей, каждая строка которой представляет пару сущностей, вовлеченных в данную связь. Конкретного способа, которым должны реализовываться связи, не существует ни в E/R-моделях, ни в ODL. Такая таблица иногда называется множеством отношений для конкретной связи. Элементы этого множества – строки таблицы. Их можно представить в виде кортежей с компонентами для каждого множества сущностей.

В E/R-моделях, в отличие от ODL, удобно определять связи между несколькими множествами. Однако на практике тернарные (трехсторонние) связи или связи еще более высокого порядка встречаются довольно редко. Многосторонние связи в E/R-моделях изображаются линиями, соединяющими ромб (связь) с каждым из участвующих в данной связи множеств.

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

Некоторое множество сущностей может многократно фигурировать в одной и той же связи, от символа связи к множеству проводится столько линий, сколько раз это множество участвует в данной связи. Каждая из таких линий определяет роль, которую множество играет в связи.

В ODL допустимы только бинарные связи, в отличие от E/R-модели. Однако любую сложную связь, включающую в себя более двух компонентов, нетрудно конвертировать в множество бинарных связей типа "многие-к-одному" без потери какой-либо информации. В E/R-модели можно ввести новое множество сущностей, элементами которого являются кортежи множества отношений для многосторонней связи. Такое множество называется множеством связующих сущностей. Затем вводится связь типа "многие-к-одному" этого множества связующих сущностей с каждым множеством сущностей, предоставляющим элемент кортежей исходной многосторонней связи. Если какое-то множество сущностей играет несколько ролей, оно является целевым пунктом одной связи для каждой из ролей.

Существует значительное отличие между наследованием в ODL или других объектно-ориентированных моделях и наследованием в E/R-модели. В ODL объект должен быть членом только одного класса. В E/R-модели считается, что сущность имеет компоненты, принадлежащие нескольким множествам сущностей, которые являются частью ISA -иерархии. Эти компоненты объединены в единую сущность связями ISA, и такая сущность имеет все атрибуты своих компонентов, а также участвует во всех связях, в которых они участвуют. Отношение между объектом и множеством, обозначающим, что объект принадлежит этому множеству, называется отношением классификации (ISA). Говорят, что множество (класс) классифицирует свои экземпляры (пример: «Шарик является собакой» = Шарик является объектом типа собака).

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

При необходимости, вместо использования множественного наследования, в E/R-модели можно ввести новое множество сущностей.

Аналогично классам ODL, множество сущностей может также иметь ключи. Если множество атрибутов формирует ключ для множества сущностей, в нем не может быть двух сущностей, чьи значения совпадают для каждого атрибута ключа. В нотации E/R-диаграммы подчеркиваются атрибуты, принадлежащие ключу для любого множества сущностей.

В модели может быть несколько ключей, при в E/R-модели отсутствуют средства для указания всех ключей. Принято выделять один ключ в качестве первичного и рассматривать множество его атрибутов как единственный ключ для множества сущностей. В E/R-модели первичный ключ выделяется подчеркиванием, а другие ключи, называемые вторичными, либо не отмечаются, либо перечисляются в комментарии на краю диаграммы.

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

Появление слабых множеств сущностей связано с двумя основными причинами. Во-первых, часто множества сущностей выстраиваются в иерархию. Когда сущности множества Е являются составными частями сущностей множества F, возможно, что имена сущностей Е не уникальны до тех пор, пока не будет учитываться имя той сущности из F, которой подчинена сущность из Е.

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

В E/R-диаграммах можно расширить функции стрелок таким образом, чтобы они показывали, ожидается ли ссылочная целостность данной связи в одном или нескольких направлениях. Пусть R – это связь множества сущностей Е с множеством сущностей F. Стрелка с закругленным "острием", указывающая на F, означает не только то, что Е и F находятся в связи типа "многие-к-одному" или "один-к-одному", но и то, что должно существовать множество Е. То же самое относится к случаю, когда R – связь между более чем двумя атрибутами.

Ключевые атрибуты для слабого множества сущностей нельзя получить произвольным образом. Если Е – слабое множество сущностей, то каждое из множеств F, поставляющих один ключевой атрибут для Е или более, должно быть соединено с Е связью R. Кроме того, необходимо выполнить следующие условия:

1. R должно быть бинарной связью типа "многие-к-одному" между E и F.

2. Атрибуты F, используемые в ключе для Е, должны быть ключевыми атрибутами множества F.

3. Если F само является слабым, атрибуты F, используемые в ключе для Е, могут быть атрибутами множества сущностей, с которым F соединено связью типа "многие-к-одному.

4. Если есть несколько связей типа "многие-к-одному" между Е и F, эти связи можно использовать для получения копий ключевых атрибутов F, позволяющих сформировать ключ для Е. Заметим, что сущность е из Е может быть связана с многими сущностями в F посредством различных связей из Е. Поэтому ключи многих различных сущностей из F могут появляться в ключевых значениях, идентифицирующих отдельную сущность е из Е.

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

1. Слабое множество обозначается двойным прямоугольником.

2. Связи типа "многие-к-одному" слабого множества с другими множествами сущностей, поставляющими для него ключевые атрибуты, обозначаются двойными ромбами.

3. Если множество сущностей поставляет атрибуты для собственного ключа, эти атрибуты подчеркиваются.

Эти соглашения суммируются в виде правила:

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

В объектно-ориентированных системах вопрос о поиске ключа никогда не возникает, всегда можно построить ключ путем описания атрибута или атрибутов, хотя это и необязательно. Объект обладает свойством "целостности объекта" и в результате имеет адрес, по которому его можно найти, a ID (идентификатор) объекта уникальным образом отличает один объект от другого даже тогда, когда их невозможно различить по значениям их атрибутов или связям. А E/R-модель "ориентирована на значение", и сущности различимы только по связанным значениям их атрибутов. Поэтому нужно всегда учитывать, что в E/R-моделях сущности любого множества можно различать только по значениям, не обращаясь ни к какой "идентичности объектов".

Переход от диаграммы "сущность-связь" к реляционной схеме БД принципиально аналогичен переходу к ней от проекта ODL. Данный переход достаточно хорошо формализуем.

1. Все простые сущности преобразуется в таблицу. Простая сущность – сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

2. Атрибуты становится возможными столбцами с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, – не могут.

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

4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи – столбцам, не допускающим неопределенные значения.

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

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

• все слабые сущности в одной таблице (а);

• для каждой слабой сущности – отдельная таблица (б).

При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления.

При использовании метода (б) для каждого подтипа первого уровня (для более нижних используются представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы – столбцы супертипа).

7. При наличии исключающих связей (сущность может быть расщеплена на два или более взаимно исключающих подтипа, каждый из которых включает общие атрибуты и/или связи) имеется два способа работы:

- общий домен (а);

- явные внешние ключи (б).

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

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

Преимущества перехода к схеме БД от E/R-моделей по сравнению с ODL-проектом заключаются в следующем:

- отношения часто можно "нормализовать", избегая избыточности, присутствующей в проекте, полученном непосредственно из описания ODL;

- двухсторонние связи ODL заменяются единственным отношением, представляющим связи в обоих направлениях.

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

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