Материал: Базы данных. учебное пособие. Бокарев Д.И

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 – максимум два класса.