Теория и практика построения баз данных (1088289), страница 157
Текст из файла (страница 157)
Таким образом, имя класса Сотрудник и требование, чтобы НомерСотрудника был уникальным, являсотся свойствами класса. Сам по себе НомерСотрудника, однако, является свойством экземпляра класса Сотрудник. Поскольку ОВМС представляет собой стандарт на интерфейс, а не на его реализацию, здесь не делаются попытки описать, как должно осушествляться хранение типов и подтипов и манипулирование имн. Интерфейс просто показывает, что объекты должны записываться и считываться классом и что должно быть обеспечено наследование. Состояние определяется значениями данных и связями В соответствии со стандартом ОВМС, состояние любого объекта представляется его свойствамц.
Этими свойствами могут быть либо атрибуты, либо связи. Атрибут — зто символьное значение или набор значений. ДатаНайма и ТекущаяЗарплата — зто значения констант. Зарплатаранее — набор значений констант. Связь— это свойство, указывающее на налично отношений между экземпляром одного объекта и одним или несколькими экземплярами других объектов. В качестве примера связи можно привести свойство Отдел, ОВМС указывает набор операций, которые могут выполняться над связями. Эти операции перечислены в табл. 18.5. Операции различаются по максимальной кардинальцостп связи.
Это делается потому, что в случае связи 1:1 свойства являются однозначнымп, и наборы свойств рассматривать не требуется. В случае связи 1:1ч нли ййМ свойство имеег много элементов, поэтому создается множество, и программа должна уметь перебирать его элементы. Таблица 18.5. Операции над связями в ООМО Операция Действие Бес Создает связь 1И Уничтожает связь Н1 добавляет злемен на множественную сторону связи Пн или ы;М удаляет элемент с мномесгвенной стороны связи ПЫ или и:М Возвращает ссылку на объект в связи 1 1 Возвращает ссылку на набор объектов на множественной стороне связи пы ипи ы:ел Гяеаг !пвеп е1етепс йегпоче е!етепг Оес тгаяесве Создает структурудпя обработки объектов из набора, ссылка на который получена с помощью операции тгаяесве Сгеасе пега1ог Когда объекты имеют связь, эта связь должна становиться постоянной, когда делается постоянным олин из объектов.
Стандарт не указывает, как должна 724 Глава 18. Объектно-ориентированные базы данных Резюме 725 представляться связь и какими способами должна осуществляться настройка связей по адресам, Эти вопросы должны решаться при создании ООСУБД. Поведение объекта определяется его операциями Поведение объектного типа определяется его методами.
Все объекты заданного .Е- типа имеют одинаковые методы, и объекты подтипов наследуют эти методы. ели объект подтипа переопрсдсляст метод, он тем самым замещает метод, унаследованный от родителя. Если, например, объект Сотрудник имеет метод узнать Зарплату, и объект Продавец, подтнп объекта Сотрудник, также имеет метод узнать За плату, ля получения сведений о зарплате проданна будет использоваться собр гу, л ственный метод этого объекта, Продавец!узнать Зарплату.
Объекты взаимодействуют между собой, вызывая методы друг друга. Иногда говорят, что объекты передают друг другу сообщения, где сообщением является строка наподобие Продавец!узнать Зарплату, включающая имя объектного типа и имя метода этого типа. У сообщений, разумеется, могут быть параметры. Назначение ООСУБД состоит в обеспечении постоянного хранения объектов. Стандарт ООМО указывает, что объекты име|от методы, поэтому в число функций ООСУБД, претендующей на соответствие атому стандарту, должно входить хранение и управление методами.
На самом деле совремашые ООСУБД весьма отличаются по степени поддержки постоянного хранения методов. Нскоторыс из них в действительности вообще не обеспечивают такой поддержки. Другие поддерживают в какой-то степени, но ис позволяют создавать версии объектов. Хранение методов является важным вопросом, и, вероятно, возможности ООСУБД в этой сфере в будущем будут улучшены.
Ни одно приложение нс является статичным; трсбования меняются, и необходимо адаптировать повеление объектов к этим изменениям. Более того, методы могут меняться и при отсутствии изменений в структуре данных объекта. Без средств управления методами у у двух экземпляров объекта могут оказаться разлпчныс версии методов. Рассмотрим пример.
Допустим, экземпляр класса Продавец, который мы обозначим Продавец А, создается и сохраняется с одной версией метода назначить Зарплату. Теперь предположим, что способ вычисления зарплаты продавца изменился, и соответственно был изменен метод назначить Зарплату. После этого был создан и сохранен объект Продавец Б. Теперь Продавец А и Продавец Б будут казаться эквивалентными в том, что касается их данных, но в действительности это не так. Без управления метолами со стороны СУБД не су|цествует способа определить, что Продавец А и Продавец Б представляют собой различные версии объекта Продавец. Эта ситуация не отличается от того, что происходит сегодня в приклалных про|раммах, не имеющих отношения к ООСУБД, поэтому сторонник Д и ООСУБД могут утверждать, что ООСУБД не ухузвпили ситуаци1о.
Однако это представляется лишь отговоркой. Если определено, что объекты имеют свойства, описывающие их данные, и свойства, описыва|ощие их поведение, то неправомочно утверждать, что постоянное хранение объектов относится только к одной разновидности свойств и нс относится к другой. Слишком многое из того, что обещает нам объектное мышление, останется за бортом, если наряду с управлением данными ООСУБД не будут обеспечивать управление методами.
Резюме Реляционные базы данных не слишком приспособлены лля хранения объектов ООП, поскольку объекты могут содержать сложные структуры, плохо подходя|цпе для хранения в таблицах. Кроме того, объекты имеют методы, которые также нужно хранить. Для постоянного хранения объектов были разработаны специализированные объсктно-ориентированные СУБД, но они не имели коммерческого успеха, так как требовали преобразования существующих реляционных данных в формат ООСУБД.
Выигрыш нс стоил затраченных средств. Вместо этого начали появляться СУБД, сочетающие реляционный и объектный подходы к хранению объектов. Такие СУБД получили название объектно-реляционных. В объектно-ориентированном программировании (ООП) программы состоят пз инкапсулированных объектов — логических структур, имеющих элементы данных и характеризуемых определенным повелением. Интерфейс — это как бы «внешний внд» объекта, а реализация — его инкапсулированная внутренняя структура. Объекты могут иметь подклассы, которые наследуют атрибуты и методы своих надклассов. Полиморфизм допускает существование нескольких версий одного и того же метода: компилятор вызывает правильную версию метода во время выполнения, в зависимости от класса объекта.
Класс -- зто логическая структура объекта; группа объектных классов называется библиотекой объектных классов. Экземпляры объектного класса называются экземплярами объекта, или просто объектами. Конструкторы объектов— это методы, выделяющие память под объекты и создающие соответствующие структуры; деструкторы уничтожают объекты и освобождают оперативную память. Временные объекты существуют только во время выполнения программы, а постоянные объекты записываются на физический носитель и существуют впе рамок работы программы. Постоянное хранение объектов может быть обеспечено с помощью традиционных систем обработки файлов, реляционных СУБД или объектно-ориентированных СУБД.
Использование традиционных систем обработки файлов создает существенную нагрузку на программиста и имев~ смысл только в приложениях, содержащих несколько простых объектов, структура которых меняется редко. Постоянное хранение объектов возможно также с помощью реляционных СУБД, но программист при этом должен преобразовывать объектные структуры в отношения, писать ЯОЕ-запросы и разрабатывать алгоритмы настройки по адресам. Использование ООСУБД вЂ” это наиболее простой и прямолинейный способ постоянного хранения объектов. СУБД Огас1е полдерживает постоянное хранение объектов с использованием объектно-реляционного подхода.
Можно определять типы объектов и применять их в таблицах как столбцовые обьекты, массивы переменной длины, вложенные таблицы или строчные объекты. Можно также определять и «чистые» объекты; такие объекты могут включать массивы переменной длины и вложенные таблицы. Они могут также содержать указатели иа объекты, опрелеленные как КЕР-атрибуты. Наконец, такие объекты могут иметь методы, которые могут обращаться к библиотекам классов Огас1е. 726 Глава т 8. Объектно-ориентированные базы данных Вопросы! группы 727 50? 3 — это расширение 5Я?.-92, которое предусматривает абстрактные типы данных (АТД), дополнения к концепции таблиц и новые возможности язьиса 5Я?.. Лбстрактные типы данных, постоянное хранение которых обеспечивается путем записи нх в таблицу, могут быть двух типов: АТД-объект и АТД-значение.