11.2. Объектно-ориентированные базы данных
В объектно-ориентированной парадигме модель предметной области – это класс взаимодействующих объектов, каждый из которых представляется набором свойств (статическими характеристиками) и набором методов работы с этим объектом (что и позволяет отразить «поведение» объекта) и обладающих следующими свойствами.
1. Инкапсуляция - объекты наделяются некоторой структурой и обладают определенным набором операций (методов). Внутренняя структура объекта скрыта от пользователя; манипуляция объектом, изменение его состояния возможны лишь посредством его методов. Таким образом объекты можно рассматривать как самостоятельные сущности
2. Наследование - возможность создавать из объектов новые объекты, которые унаследуют структуру и поведение своих предшественников, добавляя к ним черты, отражающие их собственную индивидуальность.
3. Полиморфизм - различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, как реализованы у них методы, реагирующие на сообщения.
В [1] определены следующие свойства[1], положенные в основу создания объектно-ориентированных баз данных.
1. Сложные объекты строятся из более простых при помощи конструкторов. Простейшими объектами являются такие объекты, как целые числа, символы, и др. Минимальный набор конструкторов, который должна иметь система, - это конструкторы множеств, списков и кортежей.
2. Идентифицируемость объектов. В модели с идентифицируемостью объектов объект существует независимо от его значения. Таким образом, имеется два понятия эквивалентности объектов: два объекта могут быть идентичны (они представляют собой один и тот же объект) или они могут быть равны (имеют одно и тоже значение). Это влечет два следствия: первое – существование совместно используемых (разделяемых) объектов, а второе - изменения объектов.
3. Инкапсуляция. Идея инкапсуляции связана с одной стороны, с потребностью четко различать состояния (время) спецификации и реализации операций, а с другой, для обеспечения модульности, являющейся основой для структурирования сложных приложений, разрабатываемых группой программистов. Интерпретация этого принципа для баз данных состоит в том, что объект инкапсулирует и программу, и данные.
Таким образом, имеется единая модель для данных и операций, причем информация может быть скрыта, т.е. никакие операции, кроме указанных в интерфейсе, не могут выполняться. Инкапсуляция обеспечивает "логическую независимость данных": можно изменить реализацию типа, не меняя каких-либо программ, использующих этот тип.
4. Типы и классы. В объектно-ориентированной системе тип обобщает общие черты множества объектов с одинаковыми характеристиками. Понятие класса отличается от понятия типа. Его спецификация совпадает со спецификацией типа, но является более динамическим понятием. Классы используются не для проверки правильности программы, а скорее для создания и манипулирования объектами. В большинстве систем классами можно манипулировать во время выполнения, т. е. изменять их и передавать как параметры.
5. Иерархии классов или типов. Наследование обладает двумя положительными достоинствами. Во-первых, оно является мощным средством моделирования, поскольку обеспечивает возможность краткого и точного описания предметной области. Во-вторых, эта возможность помогает факторизовать спецификации и реализации, совместно используемые в приложениях.
6. Перекрытие, перегрузка и позднее связывание. Чтобы исключить переписывание программ при введении нового типа и добавлении нового экземпляра существующего типа, система не должна связывать имена операций с программами во время компиляции. Поэтому имена операций должны разрешаться во время выполнения. Эта отложенная трансляция называется поздним связыванием. Отметим, что хотя позднее связывание затрудняет проверку типов (а в некоторых случаях делает ее невозможной), оно не отменяет ее полностью.
7. Вычислительная полнота. С точки зрения языка программирования это свойство является очевидным: оно просто означает, что любую вычислимую функцию можно выразить с помощью языка манипулирования данными системы баз данных. С точки зрения базы данных это является новшеством, так как SQL, например, не является полным языком.
8. Расширяемость. Система базы данных поставляется с набором предопределенных типов, но этот набор должен быть расширяемым: должны иметься средства для определения новых типов и не должно быть различий в использовании системных и определенных пользователем типов. Способы поддержания системой системных и пользовательских типов могут значительно различаться, но эти различия должны быть невидимыми для приложения и прикладного программиста.
9. Стабильность. Стабильность (persistence) означает возможность обеспечить сохранность данных после завершения выполнения одного процесса для последующего использования в другом процессе.
10. Управление вторичной памятью. Управление вторичной памятью является классической чертой систем управления базами данных. Эта возможность обычно поддерживается с помощью набора механизмов, таких как управление индексами, кластеризация данных, буферизация данных, выбор метода доступа и оптимизация запросов.
11. Параллелизм. Система должна обеспечивать пользователям возможность одновременно работать с базой данных. Следовательно, система должна поддерживать стандартное понятие атомарности последовательности операций и управляемого совместного доступа.
12. Восстановление. В случае аппаратных или программных сбоев система должна восстанавливаться, т. е. возвращаться к некоторому согласованному состоянию данных.
13. Средства обеспечения незапланированных запросов. Система должна позволять обрабатывать запросы, не предусмотренные при проектировании базы данных.
С точки зрения вышеуказанных требований можно отметить следующие ограничения реляционной технологии:
1. Неестественное представление данных со сложной структурой. Реляционная модель данных не допускает «естественного» моделирования данных со сложной структурой, поскольку в ее рамках возможно моделирование лишь с помощью плоских отношений (таблиц). Так как все отношения принадлежат одному уровню, многие значимые связи между данными либо теряются, либо их поддержку приходится осуществлять в рамках конкретной прикладной программы.
2. Затруднительно должным образом смоделировать свойства данных. Чтобы смоделировать структуру сложных данных, пользователь должен иметь возможность определять свои типы данных, не ограничиваясь типами данных, предоставляемыми определенной СУБД.
3. Реляционная модель данных не позволяет определить набор операций, связанных с данными определенного типа, что часто является естественным требованием при моделировании данных со сложной структурой. Операции приходится задавать в конкретном приложении.
4. Реляционная модель не позволяет рассматривать данные послойно, на различных уровнях абстракции, при необходимости отвлекаясь от ненужных деталей.
5. Усложненный доступ к базе данных. Интерфейс между языком программирования и языком баз данных обычно усложнен, поскольку каждый язык имеет свой набор типов и свою модель вычислений. Организуя обращение к базе данных из прикладной программы, написанной, например, на C++, приходится подвергать данные структурной трансформации при передаче их из/в базу данных.
Модель данных, созданная на этапе концептуального конструирования, не находит непосредственного выражения в структуре базы данных, поскольку модель реализации не предоставляет для этого необходимых средств.
Однако также необходимо привести ряд, в той или иной степени важных, недостатков, отмеченных, например, в [10].
Большинство современных ООБД не делают существенного шага вперед к полным возможностям обработки запросов по сравнению с реляционными БД; они обладают простыми средствами извлечения постоянных объектов.
Так или иначе, объектно-оринтированные БД (ООБД) накладывают некоторые ограничения в части определения постоянных данных. В частности, большинство систем по-разному трактуют постоянные и непостоянные данные; поэтому пользователи должны явно объявлять, постоянный объект или нет.
Второй, гораздо более серьезный, показатель незрелости большей части современных ООБД - недостаток средств, к которым привыкли и появления которых ожидают пользователи баз данных, в том числе полный непроцедурный язык запросов, автоматическая оптимизация и обработка запросов, одновременный доступ, авторизация, динамическое изменение схем, обработка вложенных подзапросов, операции над множествами (объединение, пересечение, разность), функции агрегирования.
Большинство современных ООБД предоставляют возможность только добавлять новые классы к базе данных, но не позволяют добавить к классу новый атрибут или метод.
Ведутся жаркие споры о степени однородности таких систем. Является ли тип и метод объектами? На уровне реализации необходимо решить, будет ли информация о типе храниться как объект, или будет реализована некоторая специализированная система. Это тот же самый вопрос, с которым сталкиваются проектировщики систем реляционных баз данных при принятии решения о том, как следует хранить схему: в виде таблицы или некоторым специальным образом.
Наконец, на уровне интерфейса требуется принять еще одно решение. Типы, объекты и методы могут быть представлены для пользователя как однородные, если даже в семантике языка программирования они предстают как различные по своей природе понятия. Обратно, они могут быть представлены для пользователя как различные сущности, хотя язык программирования не делает между ними различия. Это решение следует принимать с учетом человеческого фактора.
Назад к разделу "Глава 11. Направления развития концепций и систем обработки данных"
[1] Эти характеристики, используемые как классификационные признаки, однозначно позволяют классифицировать СУБД с точки зрения используемых моделей данных.