Причины возникновения объектных СУБД. Основные принципы осуществления концепции объективно-ориентированного подхода, история и этапы ее развития. Наиболее значительные недостатки реляционной модели данных и реляционных баз данных. Перспективы их развития.
Аннотация к работе
Хранение такой информации во внешних файлах не позволяет использовать многие средства защиты, которые предусмотрены в СУБД, Более того, объекты BLOB не могут содержать другие объекты BLOB, поэтому не могут иметь вид составных объектов. В ответ на все возрастающую сложность приложений баз данных появились две "новые" модели: объектно-ориентированная модель данных (Object-Oriented Data Model - OODM) и объектно-реляционная модель данных (Object-Relational Data Model - ORDM), которая прежде называлась расширенной реляционной моделью данных (Extended Relational Data Model - ERDM). Методы-члены вызываются в нотации имя_объекта.имя_метода (список_параметров) имеют неявный параметр SELF и могут обращаться к значениям атрибутов объекта. Метод типа ORDER сравнивает два объекта и возвращает-1, если первый объект меньше второго, 0, если объекты равны, и 1, если первый объект больше второго. Если при определении объектного типа метод сравнения не задан, то объекты этого типа можно сравнивать только на равенство/неравенство, причем объекты не должны содержать элементов тип LOB.Уже существуют примеры практического их использования крупными биржами, банками, страховыми компаниями, а также в сфере производства и телекоммуникаций, где базам данных, содержащим гигабайты информации, приходится обслуживать сотни пользователей. Они оказались хорошей альтернативой в тех случаях, когда применение реляционных БД вынуждало строить сложную схему с чрезмерно большим числом межтабличных связей. Благодаря значительному прогрессу в развитии объектной технологии, за последние пять лет производителям удалось довести свои ООСУБД до такого уровня, что они стали вполне отвечать реальным требованиям рынка. Разработчики уже сегодня могли бы продуктивно использовать версии Visual Basic, Power Builder, Forte или Delphi, поддерживающие ООСУБД. Язык программирования, при создании которого используются языки программирования третьего уровня (3GL)-процедурные языки типа C и Pascal.
Введение
объектный ориентированный база данные
Объектные базы данных появились на свет, поскольку появилась насущная необходимость решать задачи, связанные с обработкой и хранением сложных многосвязных данных, а также слабоструктурированной и неструктурированной информации: текст, изображение, музыка, вообще, любые данные, требующие специфической обработки. Объектная СУБД идеально подходит для интерпретации такого рода данных. В отличие от реляционных СУБД, где добавление нового типа данных достигается ценой потери производительности или за счет резкого увеличения сроков и стоимости разработки приложений.
В настоящее время еще не принят единый стандарт для разработки объектных СУБД.
Цель данной курсовой работы - рассмотреть теоретические аспекты проектирования объектных баз данных.
Для достижения цели курсовой работы поставлены следующие задачи: · Подобрать и изучить литературу по данной теме;
· Исследовать состояние и разработанность данной темы;
В первой главе рассматриваются общие понятия объектных СУБД (ОСУБД), причины возникновения ОСУБД, недостатки реляционных СУБД, типы ОСУБД. Вторая глава посвящена объектно-ориентированным СУБД (ООСУБД). В этой главе рассматривается концепция объектно-ориентированного подхода, модель объектных данных.
В третьей главе приводится обзор по объектно-реляционным СУБД. Рассматриваются объектно-реляционные методы.
1. Общие понятия объектных СУБД
1.1 Причины возникновения объектных СУБД
В 1990-х годах в информатике произошли значительные изменения. В области баз данных следует отметить широкое применение реляционных СУБД в таких традиционных деловых приложениях, как обработка заказов, учет складских запасов, банковское дело и заказ авиабилетов. Однако существующие реляционные СУБД продемонстрировали свою непригодность для перечисленных ниже типов приложений, чьи требования значительно отличаются от требований традиционных деловых приложений: · Автоматизированное проектирование.
· Автоматизированное производство.
· Автоматизированная разработка программного обеспечения.
· Офисные информационные системы и мультимедийные системы.
· Цифровое издательское дело.
· Геоинформационные системы.
· Интерактивные и динамические Web-узлы.
Такие проекты имеют следующие общие характеристики: * Проектные данные характеризуются большим количеством разных типов, каждый из которых представлен в виде небольшого количества экземпляров. В реляционных базах данных это дело обстоит как раз наоборот. Например, база данных риэлторской компании состоит не более чем из десятка отношений, хотя такие отношения, как PROPERCYFORRENT (данные о недвижимости), Client (арендатор) и Viewing (предпочтения), могут содержать тысячи строк.
* Проекты могут быть очень большими, вполне вероятно, включающими миллионы элементов, часто со многими взаимозависимыми проектами подсистем.
* Проект не является постоянным и со временем изменяется. При изменении проекта любые последствия этих изменений должны быть отражены во всех представлениях проекта. Динамический характер проекта может означать то, что некоторые действия не могут быть предусмотрены в самом начале проекта.
* Обновления данных сопровождаются далеко идущими последствиями изза имеющихся топологических связей, функциональных зависимостей, допусков и т.д. Единственное изменение может повлиять на большое количество объектов данного проекта.
* Часто для одного компонента проекта существует несколько альтернативных решений, поэтому для каждого такого компонента, кроме новой версии, необходимо хранить прежнюю тщательно проверенную версию. Для этого в проекте должны быть предусмотрены средства управления версиями и конфигурациями.
* В работе над проектом могут участвовать сотни людей, причем они могут параллельно работать над несколькими вариантами одного большого проекта. Однако даже при таких условиях работы конечный продукт должен быть непротиворечивым и скоординированным. Этот тип деятельности называется коллективной разработкой, * Проекты способны работать с данными произвольного формата, фотографиями, диафильмами, аудио- и видеозаписями. Например, мультимедийный документ может содержать текст, фотографии, электронные таблицы и речевые комментарии. При этом процедуры поиска могут заключаться в нахождении отдельных признаков, например по форме, цвету или текстуре, для чего необходимо использование сложных методов распознавания образов.
1.2 Недостатки реляционных СУБД
Реляционная модель данных и реляционная СУБД, в частности, имеют определенные недостатки. Ниже перечислены некоторые наиболее значительные из них, которые часто упоминаются сторонниками объектно-ориентированного подхода: · Неадекватное представление сущностей реального мира.
· Семантическая перегрузка.
· Слабая поддержка ограничений целостности и корпоративных ограничений.
· Однородная структура данных.
· Ограниченный набор операций.
· Сложности при обработке рекурсивных запросов.
· Проблема рассогласования типов данных.
· Другие проблемы реляционных СУБД, связанные с параллельным выполнением, изменениями схемы и неразвитыми средствами доступа.
Неадекватное представление сущностей реального мира. Процесс нормализации обычно приводит к созданию отношений, которые не соответствуют сущностям "реального мира". Фрагментация сущности "реального мира" на несколько отношений с физическим представлением, которое отражает эту структуру, является неэффективной и приводит к необходимости выполнения многих соединений в процессе обработки запросов. Соединение - это одна из наиболее дорогостоящих операций реляционной алгебры.
Семантическая перегрузка. Реляционная модель обладает только одной конструкцией для представления данных и связей между данными - отношением. Например, для представления связи "многие ко многим" между двумя сущностями А и В необходимо создать три отношения: два для представления сущностей А и В, а третье - для представления связи. При этом не существует никакого механизма установления различий между сущностями и связями или между разными типами связей, заданными между сущностями. Например, связь "один ко многим" может иметь разный смысл: 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 Концепция объективно-ориентированного подхода
В этом разделе рассматриваются основные концепции объектно-ориентированного подхода. Ниже приведены основные понятия абстракции, инкапсуляции и сокрытия информации.
Абстракция, инкапсуляция и сокрытие информации. Абстракция - это процесс выявления наиболее важных аспектов сущности и игнорирования всех остальных ее малозначащих свойств. В контексте создания программного обеспечения это означает концентрацию внимания на том, что представляет собой объект и что он может делать, еще до выбора метода его реализации. Двумя основными аспектами абстракции являются инкапсуляция и сокрытие информации.
Понятие инкапсуляции означает, что объект содержит как структуру данных, так и набор операций, с помощью которых этой структурой можно манипулировать.
Концепция сокрытие информации означает, что все внешние аспекты объекта отделяются от подробностей его внутреннего устройства, скрытых от внешнего мира. Таким образом, внутренние детали строения объекта могут быть изменены без какого-либо влияния на приложения, в которых он используется, при условии, что внешние характеристики остаются теми же. Это позволяет исключить излишнюю зависимость приложений от структуры данных, когда небольшое изменение способа представления информации способно породить значительные изменения во многих частях приложения.
Названные концепции упрощают создание и сопровождение приложений за счет модульности. Объект рассматривается как "черный ящик", который может быть создан и изменен независимо от остальной системы при условии, что остается неизменным его внешний интерфейс.
Существуют два аспекта инкапсуляции: она может рассматриваться с точки зрения объектно-ориентированного языка программирования (ООЯП) и с точки зрения ее реализации в базе данных. В некоторых объектно-ориентированных языках программирования инкапсуляция обеспечивается за счет использования абстрактных типов данных (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
", BRANCHNO);
printf("Street: %s
", street);
printf{"City: %s
", city);
printf("Postcode: %s
", postcode);}
Перегрузка способствует существенному упрощению приложения, поскольку позволяет использовать одно и то же имя для одной и той же операции, независимо от того класса, в котором она представлена. Таким образом, конкретное значение этой операции определяется на основе контекста. Это позволяет избежать необходимости постоянно создавать уникальные имена для методов (например, PRINTBRANCHDETAILS и PRINTSTAFFDETAILS), которые выполняют практически те же функции.
Полиморфизм и динамическое связывание. Polymorphism, в переводе с греческого, означает "наличие многих форм". Существуют три типа полиморфизма: полиморфизм операций, включения и параметрический полиморфизм. Перегрузка, показанная в предыдущем примере, является разновидностью полиморфизма операций (operation polymorphism); его называют также произвольным полиморфизмом. Метод, определенный в суперклассе и унаследованный в его подклассе, является примером применения полиморфизма включения (inclusion polymorphism). Параметрический полиморфизм (parametric polymorphism), или универсальность (genericity), означает использование типов в качестве параметров в объявлениях универсального типа или класса.
Процесс выбора соответствующего метода, основанный на типе объекта, называется связыванием (binding). Если определение типа объекта может быть отложено (во время компиляции) до наступления времени исполнения, то такой выбор называется динамическим (dynamic), или поздним (late), связыванием.
Составные объекты. Часто возникают ситуации, когда объект состоит из подчиненных объектов, или компонентов. Составным называется объект, который выглядит как единый объект в "реальном мире", но содержит другие объекты в виде набора составных связей типа A-Part-Of, или АРО (часть). Такие встроенные объекты сами могут быть составными с образованием иерархии типа АРО. В объектно-ориентированной системе встроенные объекты можно применять одним из следующих двух способов. Во-первых,
Вывод
В 1996 г. наметился заметный сдвиг в области освоения объектных СУБД. Уже существуют примеры практического их использования крупными биржами, банками, страховыми компаниями, а также в сфере производства и телекоммуникаций, где базам данных, содержащим гигабайты информации, приходится обслуживать сотни пользователей. Они оказались хорошей альтернативой в тех случаях, когда применение реляционных БД вынуждало строить сложную схему с чрезмерно большим числом межтабличных связей.
Благодаря значительному прогрессу в развитии объектной технологии, за последние пять лет производителям удалось довести свои ООСУБД до такого уровня, что они стали вполне отвечать реальным требованиям рынка.
В настоящий момент ощущается настоятельная потребность в интеграции ООСУБД с существующими инструментальными средствами. Разработчики уже сегодня могли бы продуктивно использовать версии Visual Basic, Power Builder, Forte или Delphi, поддерживающие ООСУБД. Большинство продуктов для создания приложений в той или иной мере являются объектно-ориентированными, но работают по-прежнему с реляционными БД. Специалисты считают, что партнерство производителей ООСУБД и средств программирования способно привести к появлению столь необходимого инструментария.
Глоссарий
№ п/п Понятие Определение
1 Объектно-реляционные методы Object-relational Approaches). Подходы, позволяющие воспользоваться преимуществами объектных баз данных, не отказываясь полностью от реляционных БД.
2 Транзакция (Transaction) - обработка запроса. Выполнение элементарной целостной операции над данными, в течение которой база данных находится в неустойчивом состоянии.
3 4GL (4th Generation Language) - Язык программирования четвертого поколения. Язык программирования, при создании которого используются языки программирования третьего уровня (3GL)-процедурные языки типа C и Pascal. 4GL проще в использовании, чем 3GL, им обычно отдают предпочтение при составлении программ обслуживания баз данных и применяют в сочетании с соответствующими средствами разработки.
4 Blob (Binary Large Object) - Двоичный большой объект. Длинный линейный блок данных (например, цифровое изображение или видеоклип), который наиболее подходит для хранения в ООСУБД
5 DBMS (Database Management System) - Система управления базами данных
6 ODBMS (Object Database Management System) - Объектно-ориентированная СУБД - ООСУБД. СУБД, хранящая данные и взаимосвязи между ее элементами непосредственно в самой базе данных в виде объектов, содержащих, как правило, алгоритмы обработки этих данных.
7 ODMG (Object Database Management Group) -Консорциум производителей объектных баз данных для выработки стандартов (ODMG-93, ODMG-95).
8 OMG (Open Management Group) -Консорциум поставщиков в сфере объектной технологии для выработки стандартов межкомпонентного взаимодействия. Объединяет практически всех ведущих производителей (более чем 500).
9 OQL (Object Query Language) -Язык объектных запросов. Разработанный консорциумом ODMG язык описания запросов, за основу которого был принят SQL-92.
10 RDBMS (Relational Database Management System) - Реляционная СУБД - СУБД, хранящая взаимосвязи между элементами в виде двумерных таблиц и использующая для запросов ЯЗЫКSQL.
11 SQL (Structured Query Language) - Язык структурированных запросов. Интерпретируемый язык, описывающий операции (создание, обработка и извлечение) над реляционными базами данных.
12 Архитектура клиент-сервер Client-server architecture). Архитектура, обеспечивающая распределение нагрузки между клиентом и сервером. Обычно эти функции выполняют два разных компьютера, объединенных при помощи сети.
Список литературы
объектный ориентированный база
1.Введение в системы баз данных = Introduction to Database Systems [Текст] / Дейт К. Дж. - 8-е изд. - М.: Вильямс, 2005 - 1328 с. - ISBN 5-8459-0788-8
2.Информатика: Учебник / Под общ.ред. А.Н. Данчула. - М.: И74 Изд-во РАГС, 2004 - 528с. ISBN: 5-7729-0147-8
3.Энциклопедия технологий баз данных [Текст] / Когаловский М.Р. - М.: Финансы и статистика, 2002 - 800 с. - ISBN 5-279-022764.
4.Основы баз данных [Текст] /Кузнецов С. Д. - 2-е изд. - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007 - 484 с. - ISBN 978-5-94774-736-2.
5.Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. [Текст] / Коннолли Т., Бегг К. - 3-еизд. - М.:Вильямс, 2003 - 1436 с. - ISBN 0-201-70857-4.
6.Информатика [Текст]: Учебник/ Каймин В.А. - М.: ИНФРА-М, 2000 - 232 с. - ISBN 5-16-000170-0.
7.Системы баз данных [Текст ] /Г. Гарсиа-Молина, Ульман Дж., Уидом Дж.. Полный курс. - М.: Вильямс, 2003 - 1088 с. - ISBN 5-8459-0384-X.
8.Информатика [Текст]: Учебник / А.В. Могилев, Н.И. Пак, Е.К. Хеннер. - 3-е изд. - М.: издательский центр «Академия» 2004. - 848с.- ISBN: 5-7695-1709-3.
9.Информатика [Текст]: Учебник/ Соболь Б.В., Галин А.Б., Панов Ю.В. и др. Издательство: Феникс. Дата выпуска: 2007 - 446с. ISBN: 978-5-222-12081-1