 |
||
|
||
2.3. Отношения между объектами (объектно-ориентированный подход)
Информатика как научная дисциплина не имеет столь фундаментальной аксиоматической базы, как в численном анализе. В частности, набор действий над объектами не вытекает из упорядочения натурального ряда. Понятие "упорядочение" часто употребляется в узком смысле как синоним некоторой временной нефиксированной связи объектов. Например, люди, стоящие в очередь за билетами, могут быть связаны совершенно иначе в своей производственной деятельности или в спортивном клубе. В отличие от этого "прагматического" значения мы имеем в виду упорядочение, происходящее из основного содержания объекта. Например, из значения слова "шесть" следует, что данному объекту предшествует объект с именем "три" (для линейных систем), а из самого значения слова "отец" следует последующее положение объекта "сын" (для иерархических систем). Разумеется, можно было бы придумать примеры конкретных ситуаций, где эти элементы должны быть переставлены, но в этом случае мы будем использовать слова лишь в качестве временных меток, не используя вложенный в них смысл. Провести такого рода упорядочение (обычно частичное) можно и не над числами. Трудность здесь состоит в том, что нечисленная информация, выраженная словами, как правило, не поддается однозначному упорядочению ввиду многозначности значения каждого слова. Возможный выход из этого положения – многомерное упорядочение.
Из сказанного выше, можно сделать вывод, что рассмотренные подходы к построению БД (БЗ) не позволяют отразить сложные аспекты объектов и связей предметного мира. Поэтому, как возможный конкурент следующего десятилетия реляционных и сетевых СУБД рассматриваются объектно-ориентированные СУБД. Успех объектно-ориентированного подхода лежит в смещении акцента со структуры данных (в особенности, от вида связей между данными) к процессу, с помощью которого эти данные создаются и уничтожаются. Реальные структуры данных - деталь реализации, лучше всего относящаяся к внутренней работе каждого класса (совокупности объектов) - и разные классы для обеспечения наивысшей эффективности могут быть реализованы совершенно по-разному.
Объектно-ориентированные БД - относительно новая концепция и, как таковая, не имеет четкого определения.
Свойства, представляющиеся общими для большинства реализаций, таковы:
1. Абстракция: Каждая реальная "вещь", которая хранится в БД, является членом какого-либо класса. Класс определяется как совокупность свойств (properties), методов (methods), общедоступных (public) и частных (private) структур данных, а также программ, применимых к объектам (экземплярам) данного класса. Классы представляют собой ни что иное, как абстрактные типы данных. Методы - это процедуры, которые вызывается для того, чтобы произвести какие-либо действия с объектом (например, напечатать себя или скопировать себя). Свойства - это значения данных, связанные с каждым объектом класса, характеризующие его тем или иным образом (например, цвет, возраст). Свойства присутствуют не во всех реализациях, по сути дела, они являются краткой записью методов без аргументов (таких как "сообщите свой цвет", "сообщите свой возраст").
2. Инкапсуляция: Внутреннее представление данных и деталей реализации общедоступных и частных методов (программ) является частью определения класса и известно только внутри этого класса. Доступ к объектам класса разрешен только через свойства и методы этого класса или его родителей (см. ниже "наследование"), а не путем использования знания подробностей внутренней реализации.
3. Наследование (одиночное или множественное): Классы определены как часть иерархии классов. Определение каждого класса более низкого уровня наследует свойства и методы его родителя, если они только они явно не объявлены ненаследуемыми или изменены новым определением. При одиночном наследовании класс может иметь только один родительский класс (т.е. классовая иерархия имеет древовидную структуру). При множественном наследовании класс может происходить от многочисленных родителей (т.е. иерархия классов имеет структуру ориентированного нециклического графа, не обязательно древовидную). Не все объектно-ориентированные СУБД поддерживают множественное наследование.
4. Полиморфизм: Несколько классов могут иметь совпадающие имена методов и свойств, даже если они считаются различными. Это позволяет писать методы доступа, которые будут правильно работать с объектами совершенно различных классов, лишь бы соответствующие методы и свойства были в этих классах определены. Например, метод Print может быть определен во многих классах, но работать по-разному, в зависимости от класса объекта, к которому он применяется.
5. Сообщения: Взаимодействие c объектами осуществляется путем посылки сообщений с возможностью получения ответов. Это отличается от традиционного для других моделей вызова процедур. Для того, чтобы применить метод к объекту, надо послать ему сообщение типа "примени к себе данный метод" (например, "напечатай себя"). Парадигма пересылки сообщений не всегда используется в объектно-ориентированных базах данных, однако типична для "истинно" ОО-реализаций.
Каждый объект, информация о котором хранится в ООБД, считается принадлежащим какому-либо классу, а связи между классами устанавливаются при помощи свойств и методов классов. Чтобы проиллюстрировать сказанное вновь обратимся к простому примеру. Определим два класса верхнего уровня: "Отдел" и "Служащий". Также определим класс Руководитель, который является подклассом класса Служащий. Унаследованные свойства и методы показаны курсивом (рис. 2.5).
| Служащий | Руководитель | |||
(подкласс класса Служащий) |
||||
Свойство |
Тип |
Свойство |
Тип |
|
Имя Служащего |
Текстовый |
Имя Служащего
|
Текстовый Текстовый |
|
Метод |
Возвращает |
Метод |
Возвращает |
|
Повысить (Отдел) |
Ссылка на (Руководитель) | <Повысить> | Явно не унаслед. | |
Рис. 2.5. Иллюстрация классов “Служащий” и “Руководитель”
Объекты (экземпляры класса) могут быть созданы путем применения метода "Создать экземпляр", который является общим для всех классов. Объект класса "Служащий", однажды созданный, связывается с отделом при помощи метода "Нанять" класса "Отдел" (рис. 2.6) со ссылкой на объект "Служащий" в качестве аргумента.
| Отдел | |
Свойство |
Тип |
Название Отдела |
Текстовый |
Бюджет Список Служащих Руководитель Отдела |
Список ссылок на: Служащий Ссылка на: Руководитель |
Метод |
Возвращает |
Нанять(Служащий) |
<ничего> |
Рис. 2.6. Иллюстрация класса “Отдел”
Для того, чтобы сделать служащего руководителем, надо применить метод "Повысить" к служащему (аргумент - ссылка на "Отдел"). Этот метод создает новый объект класса "Руководитель" с дубликатами наследуемых свойств, и затем уничтожает существующий экземпляр "Служащего" (используя метод "Уничтожить", также общий для всех классов). Возвращается ссылка на новый объект (дескриптор объекта). Отметим, что метод также должен скорректировать свойство "Список служащих" каждого отдела, входящего в "Список отделов", в которых работает служащий. Это необходимо для сохранения целостности БД. Поскольку "Руководитель" является подклассом "Служащего", этот "Список Служащих" не будет иметь никаких конфликтов (ссылка на "Служащего", на самом деле, может быть ссылкой на Руководителя, так как он является подклассом служащего - обратное неверно).
Отметим также, что наследование метода "Повысить" явно заблокировано в подклассе Руководитель (это обычно достигается определением на уровне класса Руководитель метода "Повысить", который ничего не делает). Это годится лишь когда служащий может быть руководителем только одного отдела. Если же отдельный служащий может руководить несколькими отделами, метод "Повысить" должен быть применим и к руководителям. В этом случае метод "Повысить" обязан вносить коррективы в свойство "Руководитель отдела" для соответствующих отделов из "Список отделов" объекта "Руководитель".
Модель ООБД находится на более высоком уровне абстракции, чем реляционные или древовидные БД, поэтому классы можно реализовать, опираясь либо на одну из этих моделей, либо на какую-нибудь еще. Поскольку в центре разработки оказываются не структуры данных, а процедуры (методы), важно, чтобы выбиралась базовая модель, которая обеспечивает достаточную прочность, гибкость и производительность обработки.
Реляционные БД с их строгим определением структуры и ограниченным набором разрешенных операций, бесспорно, не подходят в качестве базовой платформы для ООБД. Система М-языка/БД с ее более гибкой структурой данных и более процедурным подходом к разработке представляется особенно хорошо приспособленной для использования в качестве базовой платформы для СУООБД.
| Site of Information
Technologies Designed by inftech@webservis.ru. |
|