Размещено на http://www.allbest.ru/

Введение

объектный ориентированный база данные

Объектные базы данных появились на свет, поскольку появилась насущная необходимость решать задачи, связанные с обработкой и хранением сложных многосвязных данных, а также слабоструктурированной и неструктурированной информации: текст, изображение, музыка, вообще, любые данные, требующие специфической обработки. Информатика [Текст] / Макарова Н.В. Учебник Издательство: Финансы и статистика Год: 2000 - 768с Объектная СУБД идеально подходит для интерпретации такого рода данных. В отличие от реляционных СУБД, где добавление нового типа данных достигается ценой потери производительности или за счет резкого увеличения сроков и стоимости разработки приложений.

В настоящее время еще не принят единый стандарт для разработки объектных СУБД.

Цель данной курсовой работы - рассмотреть теоретические аспекты проектирования объектных баз данных.

Для достижения цели курсовой работы поставлены следующие задачи:

· Подобрать и изучить литературу по данной теме;

· Исследовать состояние и разработанность данной темы;

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

В третьей главе приводится обзор по объектно-реляционным СУБД. Рассматриваются объектно-реляционные методы.

1. Общие понятия объектных СУБД

1.1 Причины возникновения объектных СУБД

В 1990-х годах в информатике произошли значительные изменения. В области баз данных следует отметить широкое применение реляционных СУБД в таких традиционных деловых приложениях, как обработка заказов, учет складских запасов, банковское дело и заказ авиабилетов. Однако существующие реляционные СУБД продемонстрировали свою непригодность для перечисленных ниже типов приложений, чьи требования значительно отличаются от требований традиционных деловых приложений: Введение в системы баз данных = Introduction to Database Systems [Текст] / Дейт К. Дж. -- 8-е изд. -- М.: Вильямс, 2005 - 1328 с.

· Автоматизированное проектирование.

· Автоматизированное производство.

· Автоматизированная разработка программного обеспечения.

· Офисные информационные системы и мультимедийные системы.

· Цифровое издательское дело.

· Геоинформационные системы.

· Интерактивные и динамические Web-узлы.

Такие проекты имеют следующие общие характеристики:

* Проектные данные характеризуются большим количеством разных типов, каждый из которых представлен в виде небольшого количества экземпляров. В реляционных базах данных это дело обстоит как раз наоборот. Например, база данных риэлторской компании состоит не более чем из десятка отношений, хотя такие отношения, как PropercyForRent (данные о недвижимости), Client (арендатор) и Viewing (предпочтения), могут содержать тысячи строк.

* Проекты могут быть очень большими, вполне вероятно, включающими миллионы элементов, часто со многими взаимозависимыми проектами подсистем.

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

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

* Часто для одного компонента проекта существует несколько альтернативных решений, поэтому для каждого такого компонента, кроме новой версии, необходимо хранить прежнюю тщательно проверенную версию. Для этого в проекте должны быть предусмотрены средства управления версиями и конфигурациями.

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

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

1.2 Недостатки реляционных СУБД

Реляционная модель данных и реляционная СУБД, в частности, имеют определенные недостатки. Ниже перечислены некоторые наиболее значительные из них, которые часто упоминаются сторонниками объектно-ориентированного подхода:

· Неадекватное представление сущностей реального мира.

· Семантическая перегрузка.

· Слабая поддержка ограничений целостности и корпоративных ограничений.

· Однородная структура данных.

· Ограниченный набор операций.

· Сложности при обработке рекурсивных запросов.

· Проблема рассогласования типов данных.

· Другие проблемы реляционных СУБД, связанные с параллельным выполнением, изменениями схемы и неразвитыми средствами доступа. Основы баз данных [Текст] /Кузнецов С.Д. -- 2-е изд. -- М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007 -- 484 с.

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

Семантическая перегрузка. Реляционная модель обладает только одной конструкцией для представления данных и связей между данными -- отношением. Например, для представления связи "многие ко многим" между двумя сущностями А и В необходимо создать три отношения: два для представления сущностей А и В, а третье -- для представления связи. При этом не существует никакого механизма установления различий между сущностями и связями или между разными типами связей, заданными между сущностями. Например, связь "один ко многим" может иметь разный смысл: Has (имеет). Owns (владеет), Manages (управляет) и т.д. Если бы была возможность отразить подобные различия в схеме, то операциям можно было придать определенный смысл. Из-за отсутствия подобных возможностей говорят, что реляционная модель семантически перегружена.

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

Однородная структура данных. Реляционная модель предполагает как горизонтальную, так и вертикальную однородность данных. Горизонтальная однородность данных означает, что каждая строка отношения должна состоять из одинаковых атрибутов, А вертикальная однородность означает, что значения в некотором столбце отношения должны принадлежать к одному и тому же домену. Более того, на пересечении строки и столбца должно находиться элементарное значение. Эта фиксированная структура является слишком жесткой и недостаточной для представления многих объектов "реального мира" со слишком сложной структурой, что приводит к неестественным соединениям, которые, как уже упоминалось выше, весьма неэффективны.

Во многих реляционных базах данных теперь предусмотрена возможность хранения больших двоичных объектов типа BLOB (Binary Large Object -- BLOB). Объект BLOB -- это значение данных, которое содержит двоичные данные, представляющие изображение, оцифрованную видео- или аудиозапись, процедуру или любой другой крупный неструктурированный объект. СУБД не обладает сведениями о содержании объекта BLOB или его внутренней структуре. Это предотвращает выполнение запросов и операций по отношению к сложным и структурированным типам данных. Обычно база данных не содержит непосредственно саму информацию, а хранит лишь ссылку на файл с данными. Использование объектов BLOB не является оптимальным решением. Хранение такой информации во внешних файлах не позволяет использовать многие средства защиты, которые предусмотрены в СУБД, Более того, объекты BLOB не могут содержать другие объекты BLOB, поэтому не могут иметь вид составных объектов. Кроме того, объекты BLOB обычно игнорируют поведенческие аспекты объектов. Например, в некоторой реляционной СУБД изображение может храниться как объект BLOB. Однако с ним могут выполняться только такие операции, как запись в базу данных и вывод на экран. Не существует возможности модифицировать его внутреннюю структуру, отображать его отдельные части или манипулировать ими.

Ограниченный набор операций. Реляционная модель обладает только фиксированным набором операций, включающим операции с множествами и кортежами, определенные в спецификации SQL которая не допускает определения новых операций. Это накладывает большие ограничения на моделирование поведения многих объектов "реального мира". Например, в приложении GIS (геоинформационная система) обычно используются точки, линии, группы линий и многоугольники, для работы с которыми требуются операции определения расстояния, нахождения пересечений и оценки включения.

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

Проблема рассогласования типов данных. Спецификация SQL-92 не обладает вычислительной полнотой. Это утверждение остается справедливым по отношению к большинству языков манипулирования данными (DML-- Data Manipulation Language) для реляционных СУБД. Для преодоления этой трудности и предоставления дополнительных возможностей в стандарте SQL предусмотрено использование встроенных операторов SQL, что упрощает разработку более сложных приложений баз данных. Однако этот подход приводит к возникновению проблемы рассогласования типов данных (impedance mismatch), вызванной столкновением разных принципов программирования, которые описаны ниже.

* Язык SQL является декларативным языком программирования, который оперирует сразу несколькими строками данных, а такой высокоуровневый язык, как С, является процедурным языком программирования, который может управлять только одной строкой данных.

* В SQL и языках третьего поколения используются разные модели представления данных. Например, в SQL предусмотрены встроенные типы данных, которых нет в традиционных языках программировании. Таким образом, прикладной программе потребуется преобразовать данные между этими двумя представлениями, что неэффективно как в отношении затраченных на программирование усилий, так и в отношении использования вычислительных ресурсов. По некоторым оценкам, доля времени на программирование подобных преобразований и доля объема соответствующего кода в приложениях достигает 30% . Более того, из-за использования систем двух различных типов невозможно организовать в автоматическом режиме контроль типов во всем приложении в целом.

Другие проблемы реляционных СУБД

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

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

* Реляционные СУБД задумывались для обеспечения ассоциативного доступа с учетом информационного содержимого, поэтому они обладают слабыми средствами навигационного доступа, т.е. доступа по принципу перемещения между отдельными записями.

В ответ на все возрастающую сложность приложений баз данных появились две "новые" модели: объектно-ориентированная модель данных (Object-Oriented Data Model -- OODM) и объектно-реляционная модель данных (Object-Relational Data Model -- ORDM), которая прежде называлась расширенной реляционной моделью данных (Extended Relational Data Model -- ERDM). Объектные СУБД способны поддерживать стандартные деловые приложения с помощью таких же средств и таких же простых операций, как их реляционные аналоги. В частности, в следующей спецификации SQL3, предпринята попытка устранить многие из описанных выше недостатков. Например, предусмотрена возможность определения новых типов данных и операций как части языка определения данных, а также возможность добавления новых конструкций для того, чтобы сделать язык вычислительно полным.

1.3 Объектные типы и объектные таблицы

Объектные типы в Oracle8 являются аналогом типа записи в IUS. Как и в IUS, для доступа к отдельным полям значений объектного типа используется “точечная” нотация.

В Oracle 8 i при определении объектного типа можно, помимо спецификации структуры значений этого типа, определить и набор методов данного типа. Методы представляют собой функции или процедуры, написанные на PL/SQL, Java, C или другом языке и сохранённые в БД или вне её (при наличии регистрации в БД).

Любой метод объектного типа попадает в одну из трёх категорий:

· методы-члены

· статические методы

· методы сравнения.

Методы-члены вызываются в нотации

имя_объекта.имя_метода (список_параметров) имеют неявный параметр SELF и могут обращаться к значениям атрибутов объекта.

Статические методы вызываются в нотации

имя_объектного_типа.имя_метода (список_параметров) и не могут обращаться к значениям атрибутов конкретных объектов.

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

Метод типа ORDER сравнивает два объекта и возвращает -1, если первый объект меньше второго, 0, если объекты равны, и 1, если первый объект больше второго.

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

Каждый объектный тип имеет определяемый системой метод-конструктор, который создаёт новый объект этого типа и присваивает значения его атрибутам. Метод-конструктор - это функция, которая возвращает объект данного типа. Имя метода-конструктора совпадает с именем объектного типа, имена и типы параметров конструктора - с именами и типами атрибутов объектного типа.

Объектной таблицей в Oracle 8 называется таблица, строки которой имеют объектный тип. В Oracle 8 не поддерживалось наследование (ни типов, ни таблиц), но уже в Oracle 8 i появилась возможность наследования таблиц почти в той же форме, как это делалось в IUS , но без поддержки параллельной иерархии наследования объектных типов.

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

Использование ссылочных типов

В Oracle 8 строки объектных таблиц называются строчными объектами (row objects), а столбцы этих строк - столбцевыми объектами (column objects). Для всех строчных объектов обеспечивается возможность уникальной идентификации. Используется понятие объектного идентификатора, и столбец любой таблицы может быть определен на встроенном типе REF. Значения этого столбца являются своего рода указателями на строчные объекты той же самой или другой объектной таблицы. Считается, что REF - значение, указывающее на некоторый строчный объект, и сам этот строчный объект имеют разные, хотя и связные типы данных. Как утверждает Oracle, запросы с путевыми выражениями, основанными на наличии столбцов ссылочного типа, выполняются быстрее, чем эквивалентные запросы с соединениями.

Типы коллекций в Oracle 8

В Oracle 8 поддерживаются две разновидности типов коллекций: табличные типы(table types) и типы массивов. Значениями каждого типа коллекции являются коллекции (таблицы или массивы) элементов одного и того же типы (типа элемента). Тип элемента может быть встроенным или объектным типом, но не типом коллекции. Поскольку табличный тип является оригинальным изобретением компании Oracle, остановимся на нем немного подробнее. Табличный тип создается конструкцией следующего вида:

CREATE TYPE < имя типа > AS TABLE OF < тип элемента >;

Например, при наличии определения объектного типа EMP _ T можно было бы определить табличный тип DEPENDENTS _ T следующим образом:

CREATE TYPE DEPENDENTS_T AS TABLE OF EMP_T;

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

CREATE TABLE BOSSES

(boss EMP_T, dependentsEMP_T PRIMARY KEY ( boss.EMP_NO ) ) Nested TABLE DEPENDENTS STORE AS DEPENDENTS_TAB;

В результате выполнения этой операции в базе данных будут созданы две таблицы - таблица верхнего уровня BOSSES и вложенная таблица DEPENDENTS _ TAB , содержащая все строчные объекты, которые соответствуют сотрудникам-подчиненным. Конечно, если в таблице верхнего уровня имелось бы несколько столбцов табличного типа, то для каждого из этих столбцов потребовался бы свой раздел Nested TABLE . П родемонстрируем возможность выборки из таблицы с вложенной подтаблицей на примере.

Пример 3.7. Выбрать из таблицы BOSSES все пары “начальник-подчиненный”.

SELECT B.boss.EMP_NO, D.EMP_NO

FROM BOSSES B, TABLE ( B.dependents) D

Должно быть понятно, что этот запрос в сокращенной форме выражает естественное соединение таблиц BOSSES и DEPENDENTS _ TAB . Поэтому в результате не появятся данные о служащих, данные о которых включены в таблицу BOSSES и которые не имеют подчиненных. Чтобы получить данные обо всех сотрудниках, данные о которых включены в таблицу BOSSES , в синтаксисе SQL Oracle 8 требуется задать следующий запрос:

SELECT B.boss.EMP_NO, D.EMP_NO

FROM BOSSES B, TABLE ( B.dependents ) (+) D

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

Вторая разновидность типов коллекций в Oracle 8 называется VARRAY , что вполне соответствует стандарту SQL :1999 и означает “массив переменного размера” (varying -length array ). При определении типа массива указываются имя типа, тип элементов и максимальное число элементов, которые может содержать значение определяемого типа. В отличие от значений табличного типа, для элементов значений типа массива поддерживается порядок.

Как и в случае с множествами (и мультимножествами) в IUS, на уровне прямого SQL в Oracle можно работать только с массивами целиком. Однако существует возможность привести в запросе (или другом операторе SQL) тип массива к табличному типу.

2. Объектно-ориентированные СУБД

2.1 Концепция объективно-ориентированного подхода

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

Абстракция, инкапсуляция и сокрытие информации. Абстракция -- это процесс выявления наиболее важных аспектов сущности и игнорирования всех остальных ее малозначащих свойств. В контексте создания программного обеспечения это означает концентрацию внимания на том, что представляет собой объект и что он может делать, еще до выбора метода его реализации. Двумя основными аспектами абстракции являются инкапсуляция и сокрытие информации. Информатика [Текст]: Учебник / А.В .Могилев, Н.И .Пак, Е.К. Хённер. - 3-е изд. - М.: издательский центр «Академия» 2004. - 848с

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

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

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

Существуют два аспекта инкапсуляции: она может рассматриваться с точки зрения объектно-ориентированного языка программирования (ООЯП) и с точки зрения ее реализации в базе данных. В некоторых объектно-ориентированных языках программирования инкапсуляция обеспечивается за счет использования абстрактных типов данных (Abstract Data Types -- ADT). При таком подходе объект состоит из интерфейса и реализации. Интерфейс предоставляет спецификацию операций, которые могут быть выполнены с объектом, а реализация состоит из структуры данных для ADT и функций, которые реализуют этот интерфейс. Для других объектов и пользователей доступен только интерфейс. С точки зрения реализации в базе данных инкапсуляция достигается благодаря тому, что программистам предоставляется право доступа только к интерфейсу. Таким образом, инкапсуляция обеспечивает логическую независимость от данных: внутреннюю реализацию ADT можно изменять, не затрагивая приложения, которые используют эти абстрактные типы данных ADT.

Объекты и атрибуты. В ООЯП объекты являются ключевым компонентом моделирования. Объект рассматривается как уникально определяемая сущность, которая содержит атрибуты, описывающие состояние объектов "реального мира" и связанные с ними действия. Объект инкапсулирует состояние и правила поведения. Текущее состояние объекта описывается одним или несколькими атрибутами, или переменными экземпляра. Например, отделение риэлторской компании, расположенное по адресу «ул. Маяковского 25», может иметь атрибуты, приведенные в приложении А.

Атрибуты могут быть простыми и составными. Простой атрибут может иметь примитивный тип (например, целое число, строка, действительное число и т.д.) и принимать строковое значение. Например, атрибут branchNo в табл.1. является простым атрибутом со строковым значением 'ВООЗ'. Составной атрибут может содержать коллекции и/или ссылки. Например, атрибут SalesStaff является коллекцией объектов типа Staff (сотрудник). Ссылочный атрибут представляет связь между объектами. Он содержит значение (или коллекцию значений), которое само является объектом. Например, атрибут SalesStaff, если говорить точнее, является коллекцией ссылок на объекты типа Staff. Ссылочный атрибут концептуально аналогичен внешнему ключу в реляционной модели данных или указателю в языках программирования. Объект, который содержит один или несколько составных атрибутов, называется составным объектом.

Ссылки на атрибуты обычно формируются с использованием "точечного" обозначения, например, как показано ниже для атрибута street объекта, представляющего отделение: branchObject.street

Идентификация объектов. Ключевой частью определения объекта является уникальность его идентификации. В объектно-ориентированной системе каждому объекту в момент его создания присваивается идентификатор объекта (Object IDentifier -- OID), который обладает следующими свойствами:

· генерируется системой;

· уникально обозначает этот объект;

· является неизменным в том смысле, что его нельзя изменить, пока объект продолжает существовать;

· после создания объекта его идентификатор OID не может быть использован повторно ни для какого другого объекта, даже после удаления данного объекта;

· не зависит от значений его атрибутов (т.е. от его текущего состояния; два объекта могут иметь одинаковое состояние, но всегда обладают разными идентификаторами OID);

· скрыт от пользователя (в идеальном случае).

Таким образом, идентичность гарантируется тем, что объект всегда можно единственным образом обозначить, что автоматически гарантирует целостность сущностей.

Ниже перечислены основные преимущества использования идентификаторов OID для обозначения объектов.

* Эффективность. Для хранения идентификаторов OID внутри составного объекта требуется очень мало места. Обычно они меньше текстовых имен, внешних ключей или семантических ссылок.

* Быстродействие. Идентификатор OID указывает на фактический адрес или место внутри таблицы, в котором находится адрес данного объекта. Это означает, что объекты могут быть быстро обнаружены, независимо от места их текущего хранения: в оперативной памяти или на жестком диске.

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

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

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

Сообщения являются средством взаимодействия объектов. Сообщение представляет собой запрос, направленный одним объектом (отправителем) другому объекту (получателю) и требующий, чтобы объект-получатель выполнил один из своих методов. Один и тог же объект может быть одновременно и отправителем, и получателем. Доступ к методу обычно обозначается точкой. Например, для выполнения метода updateSalary (обновить зарплату) объекта Staff с передачей ему параметра 1000 следует использовать такой синтаксис: staffObject.updateSalary(1000)

В обычном языке программирования сообщение записывается как вызов функции: updateSalary(staffObject, 1000)

Классы. В объектно-ориентированных системах классы играют роль шаблона для определения набора подобных объектов. Таким образом, объекты, которые имеют один и тот же набор атрибутов и отвечают на одни и те же сообщения, могут быть сгруппированы в виде класса. Атрибуты и связанные с ними методы определяются один раз для всего класса, а не отдельно для каждого объекта. Например, все объекты отделений компании описываются единственным классом Branch. Объекты некоторого класса называются его экземплярами (instance). Каждый экземпляр обладает своими собственными значениями каждого из атрибутов, но совместно с другими экземплярами данного класса использует для этих атрибутов одни и те же имена и методы. В литературе термины "класс" и "тип" часто используются как синонимы, хотя некоторые авторы указывают на различие между ними. Термин "тип" более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указанием ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать допустимость программных конструкций. С другой стороны, класс является шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам.

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

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

Подклассы, суперклассы и наследование. Некоторые объекты могут иметь подобные, но не идентичные атрибуты и методы. Если степень такого подобия достаточно высока, то имеет смысл совместно использовать некоторые свойства (атрибуты и методы). Наследование (inheritance) позволяет определять один класс на основе общего класса. Такие менее общие классы называются подклассами, а более общие -- суперклассами. Процесс образования суперкласса называется обобщением (generalization), а процесс образования подкласса -- специализацией. По умолчанию подкласс наследует все свойства своего суперкласса и в дополнение к ним определяет свои собственные уникальные свойства. Однако в подклассе могут быть также переопределены унаследованные свойства. Все экземпляры подкласса являются также экземплярами суперкласса. Более того, согласно принципу подстановки, для любого метода и конструкции вместо экземпляра суперкласса всегда можно использовать экземпляр его подкласса.

Понятия подкласса, суперкласса и наследования аналогичны таким же понятиям в модели "сущность-связь" за исключением того, что в объектно-ориентированной модели наследование относится как к состоянию, так и к правилам поведения. Связь между подклассом и суперклассом обычно называется связью типа АКО (A Kind Of), например суперкласс Manager связан с подклассом Staff связью АКО. Связь между экземпляром и его классом иногда называют связью типа IS-А, например, экземпляр Сьюзен Бранд связан с классом Manager связью IS-A.

Существует несколько видов наследования: единичное (single), множественное (multiple), повторное (repeated) и избирательное (selective). Например, подклассы Manager и SalesStaff наследуют свойства суперкласса Staff. Термин единичное наследование означает, что подклассы наследуют свойства не более, чем одного суперкласса. Суперкласс staff сам по себе может быть подклассом суперкласса Person (человек), образуя, таким образом, иерархию классов.

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

method void giveCommiselon(float branchProfit)

{salary = salary + 0.02 * branchProfit;}

Однако для класса Manager может потребоваться выполнять те же расчеты исходя из другого процента комиссионных. Это можно сделать за счет переопределения или перекрытия метода giveCommission в самом подклассе Manager:

method void giveCommission(float branchProfit)

{salary = salary + 0.05 * branchProfit;}

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

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

method void print( ) {

printf("Branch number: %s\n", branchNo);

printf("Street: %s\n", street);

printf{"City: %s\n", city);

printf("Postcode: %s\n", postcode);}

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

Полиморфизм и динамическое связывание. Рolymorphism, в переводе с греческого, означает "наличие многих форм". Существуют три типа полиморфизма: полиморфизм операций, включения и параметрический полиморфизм. Перегрузка, показанная в предыдущем примере, является разновидностью полиморфизма операций (operation polymorphism); его называют также произвольным полиморфизмом. Метод, определенный в суперклассе и унаследованный в его подклассе, является примером применения полиморфизма включения (inclusion polymorphism). Параметрический полиморфизм (parametric polymorphism), или универсальность (genericity), означает использование типов в качестве параметров в объявлениях универсального типа или класса.

Процесс выбора соответствующего метода, основанный на типе объекта, называется связыванием (binding). Если определение типа объекта может быть отложено (во время компиляции) до наступления времени исполнения, то такой выбор называется динамическим (dynamic), или поздним (late), связыванием.

Составные объекты. Часто возникают ситуации, когда объект состоит из подчиненных объектов, или компонентов. Составным называется объект, который выглядит как единый объект в "реальном мире", но содержит другие объекты в виде набора составных связей типа A-Part-Of, или АРО (часть). Такие встроенные объекты сами могут быть составными с образованием иерархии типа АРО. В объектно-ориентированной системе встроенные объекты можно применять одним из следующих двух способов. Во-первых, за счет инкапсуляции внутри составного объекта с образованием части составного объекта. В этом случае структура встроенного объекта образует часть структуры составного объекта и доступ к ней можно получить только с помощью методов составного объекта. Во-вторых, встроенный объект может рассматриваться как независимый от составного объекта. И в этом случае в родительском объекте хранится не сам объект, а лишь его идентификатор OID. Такой способ называется совместным использованием ссылок (referential sharing). Встроенный объект обладает своей собственной структурой и методами, а также может принадлежать нескольким родительским объектам. Эти типы составных объектов иногда называют структурированными составными объектами, так как их состав известен системе. Термин неструктурированный составной объект используется для обозначения составного объекта, структура которого может интерпретироваться только прикладной программой. В контексте баз данных неструктурированные составные объекты иногда называются большими двоичными объектами, или объектами BLOB.

2.2 Объектно-ориентированная модель данных

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

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

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

Во-первых, следуя практике многих ООБД, предлагается выделить два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий). На структурном уровне поддерживаются сложные объекты, их идентификация и разновидности связи IS-A. База данных - это набор элементов данных, связанных отношениями «входит в класс» или «является атрибутом». Таким образом, БД может рассматриваться как ориентированный граф. Важным моментом является поддержание наряду с понятием объекта понятия значения.

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

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

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

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

2.3 Современные объектно-ориентированные СУБД

Список современных коммерческих объектно-ориентированных систем включает в себя следующие продукты: Энциклопедия технологий баз данных [Текст] / Когаловский М.Р. -- М.: Финансы и статистика, 2002 - 800 с.

Objectivity/DB компании Objectivity, Inc. (последняя версия - 2.1) идеально, по заявлениям фирмы, подходит для приложений, которые работают в распределенных средах, требуют гибкой модификации данных, организации сложных связей, а также нуждаются в высокой производительности и работы с большими объемами данных. Objectivity обеспечила интеграцию инструментария СУБД и разработки приложений с такими средствами программирования, как SoftBench и C++ SoftBench. Благодаря интегрированному графическому интерфейсу разработки схемы БД и инструментам отладки и анализа упрощается задание модели базы данных и, соответственно, разработки приложений для Objectivity/DB.

СУБД GemStone корпорации GemStone Systems, Inc. известна в последней редакции под номером 5.0. GemStone традиционно сосредоточена на рынке Smalltalk (хотя не так давно и была выпущена версия для С++) и имеет заказчиков, способных продемонстрировать на производстве крупномасштабные, целевые применения ее продуктов.

ONTOS Corp., разработчик СУБД ONTOS, по традиции занимается развитием сервера объектно-ориентированной СУБД, но в последнее время придает особое значение своим Службам Интеграции Объектов (Object Integration Services).

Построенная на основе реляционной СУБД AllBase, система OpenODB фирмы Hewlett-Packard также, как и Objectivity/DB, интегрирована с системой SoftBench и существует в версии для С++. Благодаря глубокой интеграции, SoftBench распознает файлы приложений OpenODB для установки оптимальной конфигурации, может создавать базы данных формата OpenODB из своей интегрированной среды, обеспечивает оперативную помощь из среды разработки и т. д.

Object Design Inc. со своей СУБД ObjectStore занимает лидирующее положение в отрасли, осуществляя около 33% поставок на рынке объектно-ориентированных СУБД и последняя модернизация системы (клиент языка SQL и шлюз к реляционной СУБД) должны только укрепить положение фирмы. Object Design поддерживает версии своей СУБД как для С++, так и для Smalltalk.

Versant Object Technology, Inc. (СУБД Versant) проводит двойную стратегию, предлагая средство обеспечения объектно-ориентированной СУБД высокого класса для телекоммуникаций и инструментальные средства Smalltalk для более общих случаев разработки приложений. Используя разработанный фирмой интерфейс VERSANT Smalltalk Language Interface, СУБД совместима как с версией языка Smalltalk компании ParcPlace-Digitalk, так и с Visual Age for Smalltalk корпорации IBM.

СУБД UniSQL компании UniSQL Inc. - хорошо устоявшаяся система, позволяющая пользователям осуществлять запросы и модификацию базы при помощи разработанного компанией языка SQL/X (подобные языки, носящие условное название Object SQL, разработаны и некоторыми другими поставщиками). Вся БД UniSQL может состоять одновременно из связей в локальных РСУБД и классов в локальных объектных базах UniSQL. Благодаря механизму каталогов, СУБД передает запросы и модификации данных в локальные базы данных и, обработав (перевод в другой формат, группирование, сортировка и т. д.) полученный от них результат, возвращает его пользователю.

Кроме того ООСУБД предлагают: Object Database, Inc. (Object Database), Itasca Systems Inc. (Itasca) O2 Technology (O2) и некоторые другие компании.

3. Объектно-реляционные СУБД

3.1 История появления объектно-реляционных СУБД

Два весьма известных специалиста в области технологии баз данных - Майкл Стоунбрейкер и Вон Ким - оспаривают пальму первенства в направлении объектно-реляционных СУБД (ОРСУБД). Стоунбрейкер начал работать в области баз данных в начале 70-х гг. прошлого века в университете Беркли. Его первым всемирно известным проектом была СУБД Ingres, которая существует и используется до сих пор в двух ипостасях - как свободно распространяемая система (университетская Ingres; код поддерживается в Беркли) и как коммерческая СУБД, принадлежащая компании Computer Associates. В исходном варианте СУБД Ingres отсутствовала поддержка языка SQL (поддерживался собственный язык запросов QUEL ), но система уже обладала некоторыми уникальными чертами, которые, с некоторой натяжкой, можно было бы назвать объектными (например, в СУБД Ingres допускалось определение пользовательских процедур, выполняемых на стороне сервера). Кроме того, в проекте Ingres очень большое внимание уделялось управлению правилами. Информатика: Учебник / Под общ.ред. А.Н. Данчула. - М.: И74 Изд-во РАГС, 2004 - 528с.

В 80-е годы Майкл Стоунбрейкер возглавлял проект Postgres (вариант этой системы под названием PostgreSQL до сих пор является весьма популярным свободно доступным продуктов). В Postgres были реализованы многие интересные средства: поддерживалась темпоральная модель хранения и доступа к данным, и в связи с этим был абсолютно пересмотрен механизм журнализации изменений, откатов транзакций и восстановления БД после сбоев; обеспечивался мощный механизм ограничений целостности; поддерживались ненормализованные отношения (работа в этом направлении началась еще в среде Ingres), хотя и довольно странным способом: в поле отношения может храниться динамически выполняемый запрос к БД.

Одно свойство системы Postgres сближало ее со свойствами объектно-ориентированных СУБД. В Postgres допускалось хранение в полях отношений данных абстрактных, определяемых пользователями типов. Это обеспечивало возможность внедрения поведенческого аспекта в БД, т.е. решало ту же задачу, что и ООСУБД, хотя, конечно, семантические возможности модели данных Postgres были существенно слабее, чем у объектно-ориентированных моделей данных. Основная разница состояла в том, что в Postgres не предполагалось наличие языка программирования, одинаково понимаемого как внешней системой программирования, так и системой управления базами данных. Как и в Ingres , в исходном варианте Postgres не поддерживался язык SQL (имелся собственный язык запросов Postquel ). Во времена Postgres Майкл Стоунбрейкер не использовал термин объектно-реляционная система, предпочитая называть свою СУБД системой следующего поколения.

В 90-е гг. Стоунбрейкер создал компанию Illustra , основной целью которой был выпуск коммерческого варианта СУБД Postgress , получившего название Illustra. В этой системе поддерживались основные идеи Postgres, но уже присутствовала и поддержка языка SQL . В конце 1995 г. компания Illustra была поглощена компанией Informix , и это привело к выпуску в 1996 г. СУБД Informix Universal Server .

Имя Вона Кима стало широко известно во второй половине 70-х гг., когда он примкнул к участию в экспериментальном проекте компании IBM System R . Наиболее известная ранняя работа доктора Кима была посвящена преобразованию SQL -запросов с целью превращения запросов с вложенными подзапросами в запросы с соединениями.

В 80-е гг. Вон Ким работал в компании MCC , где успешно выполнил реализацию серии прототипов ООСУБД Orion . В этих прототипах были опробованы многие идеи объектно-ориентированных СУБД. Одной из интересных особенностей проекта было то, что в качестве основного языка программирования использовался объектный вариант известного функционального языка Lisp . Базы данных. Проектирование, реализацияисопровождение. Теорияипрактика = Database Systems: A Practical Approach to Design, Implementation, and Management. [Текст] / Коннолли Т., Бегг К. -- 3-еизд. -- М.:Вильямс, 2003 - 1436 с

В конце 80-х д-р Ким основал компанию UniSQL , выпустившую в 1991 г. первую версию продукта UniSQL , которую Вон Ким стал называть объектно-реляционной системой. Трудно оценивать коммерческий успех этой СУБД. В настоящее время она принадлежит Корейской национальной телекоммуникационной компании и, по всей видимости, продолжает использоваться. Поскольку UniSQL была первой СУБД, официально называемой объектно-реляционной системой, приведем ее краткое описание.

UniSQL обеспечивает возможность построения так называемых федеративных систем баз данных. При этом предоставляется единое представление данных, которые могут храниться либо в базе данных, непосредственно управляемой UniSQL , либо в какой-либо из реляционных баз данных, управляемой СУБД Oracle , Informix , Sybase и т.д., либо в какой-либо дореляционной базе данных. Сервер UniSQL обеспечивает интегрированный доступ к данным, управляемым разными СУБД.