Объектно-ориентированные субд. рассмотрим основные концепции объектно-ориентированного подхода.

Рассмотрим основные концепции объектно-ориентированного подхода.

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

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

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

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

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

Рис. 15. Схема строения объекта с атрибутами и методами

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

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

Рис. 16. Экземпляры класса, совместно использующие имена атрибутов и методы класса

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

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

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

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

• Использование классов и механизма наследования способствует разработке повторно используемых и расширяемых компонентов при создании новых или модернизации существующих систем.

Рассмотрим объектно-ориентированные системы управления базами данных (ООСУБД). ООСУБД появились сначала в инженерно-конструкторских приложениях и только недавно получили признание у разработчиков финансовых и телекоммуникационных приложений. Хотя доля рынка ООСУБД все еще остается очень маленькой , тем не менее ООСУБД продолжают находить все новые области применения, например в World Wide Web. Действительно, по оценкам некоторых аналитиков, рынок ООСУБД ежегодно будет возрастать на 50%, что выше темпов роста всего рынка баз данных в целом.

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

ООМД – логическая модель данных, которая учитывает семантику объектов, применяемую в объектно-ориентированном программировании;

ООДБ – перманентный, совместно используемый набор (коллекция) объектов, определенный средствами ООМД;

ООСУБД – система управления (менеджер) ООДБ.

Хошафян и Абноус предложили собственное определение объектно-ориентированной СУБД:

1. “Объектно-ориентированный подход” = “абстрактные типы данных” + “наследование” + “идентичность объектов”.

2. “Объектно-ориентированная СУБД” = “объектно-ориентированный подход” + “возможности базы данных”.

Ниже приводится еще одно определение ООСУБД, построенное посредством указания ее обязательных компонентов:

1. Высокоуровневый язык запросов со средствами оптимизации, реализованными в базовой системе.

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

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

4. “Объектно-ориентированная СУБД” = “объектно-ориентированная система” + “условия пунктов 1, 2 и 3”.

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

• Расширение существующего объектно-ориентированного языка программирования возможностями работы с базой данных. В этом подходе традиционные функции базы данных добавляются в существующие объектно-ориентированные языки программирования, подобные Smalltalk, C++ или Java. Подобный подход используется в продукте GemStone, в котором расширяются возможности именно этих трех языков.

• Предоставление расширяемых объектно-ориентированных библиотек СУБД. В этом подходе также используется добавление традиционных функций базы данных в существующий язык программирования. Однако вместо расширения функций самого языка здесь используются дополнительные библиотеки классов, поддерживающих объектные типы данных, транзакции, параллельность, безопасность и т.д. Именно этот подход используется в продуктах Ontos, Versant и ObjectStore.

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

• Разработка нового языка базы данных или модели данных. Это радикальный подход, который начиная с нуля приводит к созданию совершенно нового языка баз данных и СУБД, обладающих объектно-ориентированными возможностями. Такой подход используется в системе SIM (Semantic Information Manager), которая основана на собственной семантической модели данных и обладает новыми языками определения и управления данным.

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

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

В настоящее время реляционные СУБД являются доминирующим типом систем управления базами данных, приблизительный ежегодный объем продажи которых составляет 8–10 млрд. дол. США (или 25 млрд. дол. с учетом продажи инструментов для их разработки). Темпы роста объема продаж составляют до 25% в год. ООСУБД, которые рассматривались ранее, изначально нашли применение в области инженерно-конструкторских работ и только недавно стали приобретать популярность в финансовых и телекоммуникационных приложениях. Хотя рынок ООСУБД все еще относительно мал (объем продаж за 1996 год составил около 150 млн. дол. США) и составляет лишь 3% от всего рынка баз данных (в 1997 году), тем не менее ООСУБД продолжают находить все новые области применения, например в среде World Wide Web. Некоторые аналитики оценивают темпы ежегодного прироста рынка ООСУБД на уровне 50%, что выше темпов роста для всего рынка баз данных в целом. Однако маловероятно, что в обозримом будущем объемы продаж этих новых систем превзойдут объемы продаж реляционных СУБД, поскольку этот тип СУБД подходит для достаточно большого количества компаний, инвестировавших в их развитие такие огромные средства и ресурсы, что любая замена становится практически невозможной.

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

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

Для систем с расширенной реляционной моделью данных используются самые разные термины. Сначала дляих описания применяли термин “расширенная реляционная СУБД” (Extended Relational DBMS – ERDBMS). Однако в последние годы используется более информативный термин “объектно-реляционная СУБД”, или ООСУБД (Object-Relational DBMS – ORDBMS), в котором содержится указание на использование в системе понятия “объект”. Наконец, совсем недавно стали использоваться термины “универсальный сервер” (Universal Server), “универсальная СУБД”, или УСУБД (Universal DBMS). В этой главе будет использоваться термин “объектно-реляционная СУБД”, или ОРСУБД. Три ведущих фирмы в области разработки РСУБД, а именно “Oracle”, “Informix” и “IBM”, расширили свои системы до уровня ОРСУБД, хотя их функциональные возможности немного отличаются. Концепция ОРСУБД как комбинации ООСУБД и РСУБД, очень притягательна за счет применения всех тех богатейших знаний и опыта, которые были накоплены за время работы с РСУБД. Причем она настолько привлекательна, что некоторые аналитики предсказывают, что в недалеком будущем рыночная доля ОРСУБД будет на 50% выше доли РСУБД.

Как и следовало ожидать, разработка стандартов в этой сфере построена на расширении стандарта языка SQL. Национальные институты стандартизации работают над созданием расширений языка SQL с 1991 года. Эти расширения стали частью нового чернового варианта стандарта языка SQL, который обычно называют стандартом SQL3. Стандарт SQL3 представляет собой продолжающуюся и по сей день попытку стандартизовать расширения реляционной модели и языка запросов.

Хранилища данных

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