Объектно-ориентированный подход в сфере баз данных

ОО подход получил отражение и в сфере баз данных. Можно выделить три основных направления его реализации:

1) «интерфейсный»;

2) смешанный (объектно-реляционный);

3) «чистый».

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

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

«Чистый» подход в корне меняет представление об ОО автоматизированной информационной системе. Ее не нужно делить на базу данных и программу. Система представляет собой некую среду, состоящую из объектов, обменивающихся сообщениями. Такой подход требует от разработчика смены концепции, что не просто. Однако уже предпринимаются попытки его реализации (например, в СУБД Cache’). В целом такой подход выходит за рамки курса «Базы данных» и поэтому здесь не рассматривается[12].

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

Пример структуры ОО базы данных

Ниже приведен пример ОО модели для задачи «Сессия». Для простоты модель описывается только диаграммой классов.

ОО модель для задачи «Сессия» на уровне анализа приведена на слайде 11. Основными классами являются: Преподаватель, Дисциплина, Студент. К связи Преподаватель – Дисциплина прикреплен класс-ассоциация «Читает», а к связи Дисциплина – Студент прикреплен класс-ассоциация «Оценка». Эти классы позволяют отразить семантику связей, а при необходимости описать атрибуты связей.

На уровне проектирования ОО модель для задачи «Сессия» приведена на слайде 12. Классы Преподаватель и Студент являются наследниками более общего родительского класса Персона, в котором описаны общие атрибуты (фамилия, имя, отчество и т.д.). Связь Преподаватель – Дисциплина реализована с помощью класса «Дисциплина в плане». Этот класс является наследником родительского класса «Дисциплина». Связь Студент – Дисциплина реализована с помощью класса «Запись сводной ведомости».

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

14.2.4. Обзор распространенных ОО СУБД (слайд 13)

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

Большинство производителей придерживаются первого направления. (ОО интерфейсы к реляционной базе данных). Такое направление избрала компания Microsoft, разработав для MS SQL Server компонент LINQ (Language-Integrated Query), позволяющий обращаться к записям базы данных как к объектам. Аналогично поступила компания MySQL AB (СУБД MySQL), разработав специальное средство Object-relational mapping tool.

Наиболее ярким представителем второго направления (объектно-реляционных СУБД) можно считать компанию Oracle (СУБД Oracle Database). Oracle Database позволяет объявлять классы (содержащие атрибуты и методы), которые затем могут использоваться либо как типы данных (при описании столбцов таблиц), либо в качестве описания структуры таблицы целиком (атрибуты класса трактуются как столбцы таблицы). В первом случае объектом является поле в записи, во втором случае – целая запись, причем сама таблица трактуется как класс. Эти два подхода являются взаимоисключающими.

Поддержка объектно-реляционного подхода реализована также в СУБД Progress. К этой же группе можно (условно) отнести и СУБД Postgres, реализующую принцип наследования при описании структуры базы данных. Среди не реляционных СУБД, поддерживающих ОО подход, можно выделить документальную СУБД Lotus Domino. Она реализует механизм инкапсуляции. Документ (основная структурная единица этой СУБД) можно рассматривать как объект, содержащий данные и методы. Реализован механизм сокрытия данных.

Наиболее яркой «чистой» ОО СУБД можно считать Cache’. Объектная модель данных в ней реализована на основе стандарта ODMG (Object Database Management Group – группа по объектному управлению базами данных). В СУБД реализованы все базовые механизмы ОО подхода (инкапсуляция, наследование, полиморфизм, абстракция).