Теория и практика построения баз данных (1088289), страница 156
Текст из файла (страница 156)
В ВЯ1.3 методы абстрактных типов могут быть сами написаны на ЯЯ1.. Чтобы сделать эту возможность более реальной, предложены дополнительные языковые элементы, делающие ВОТ. полноценным в вычислительном отношении языком программирования. Предложенные расширения перечислены в табл. 18А. Таблица 18.4. Предложенные расширения стандарта ЯОСЗ Оператор Цель ОЕЗТНОУ АЗЗ)ВММЕМТ Уничтожает АТД-объект; допустим только в функциях-деструкторах Позволяет присвоить результат выполнения ЗОС-запроса локальной переменной, столбцу нли АТД-атрибуту Вызывает ЗОС-процедуру Возвращает значение, вычисленное процедурой нлн функцией Выбирает путь, по которому пойдет выполнение программы в зависимости от значения управляющей переменной Условный оператор Оператор цикла САСС ЯЕТОЯМ САЗЕ )Р ТНЕМ ЕСЗЕ ууНГЬЕ СООР До сих пор 5Я1 был языком, ориентироваинылс на множества.
Операторы 5ЕСЕСТ выделяли множество строк и выполняли с ними неко~орые действия. Добавление языковых элементов, представленных в табл 18А, измен~тт эту характеристику. В ЯЯ) станет возможна реализация логики крана строка за один приемы Это изменение сделает ВО!. еще более похожим на традиционные языки программирования. Это необхолилю, если предполагается использовать ВЯ). для написштия методов абстрактных типов данных, но означает также фундаментальную смену парадигмы ВО1. Поразмыслите немного над последствиями добавления к понятию таблиц абстрактных типов данных и подтипов, Как абстрактные т~шы данных, так и таблицы могут иметь подтипы, но это не одно и то же.
Подтипы абстрактных типов данных определяют одну иерархшо обобщения, а подтипы таблцц — другую. Иерархии могут быть вложенными одна в другую, раздельнылги или частично перекрывающимися. Это является поводом для критики ВЯь3 за его чрезмерную сложность в этом отношении, и интересно будет увидеть, какая часть этой сложной структуры будет в действительности реализована в СУБД. 00МО-93 ОВМС (ОЬ)есс Раса Мапайепшпс Сгоцр, Группа управления объектными данными) — зто консорциум производителей объектных баз данных и других заинтересованных промышленных экспертов, который применил идеи другой группы, ОМС (ОЬ)есс Мапайеспепс Сгоцр, Группа управления обьектами), к проблеме объектных баз данных.
Первый отчет ОВМС был представлен в 1993 г, и поэтому называется ОВМС-93, Этот стандарт вышел из объектно-ориентированного программирования, а не из традиционных реляционных баз данных. Следовательно, в качестве базовой конструкции в нем выступает объект, а не таблица, как в 5О).3. ОВМС-93 — это определение интерфейсов для продуктов, работающих с объектнымп данными. Реализация идей ОВМС-93 может весьма различаться.
Продукт ОВМС-93, предназначенный для хранения и манипулирования данными объектов Сч-ч-, может иметь совершенно другую организацию, чем продукт для хранения и манипулирования объектами языка 5ша1!са!к. Эти дпа продукта могут быть весьма различными, и все же реализующими пнтерфет!сы ОВМС-93. Поскольку ОВМС-93 вырос из контекста обьектно-ориентированного программирования, его детальное описание требует сусцествециого знания ООП. Такое описание выходит за рамки этой книги.
Мы сосредоточим наше внимание на фундаментальных концепциях, лежащих в основе отчета ОВМС-93. В следующем списке представлены пять ключевых идеИ, согласно описанию Мэри Лумис (Магу 1 оопиз)Е + Объекты являются фундаментальными единицами. + Каждый объект имеет постоянный, сохраняюцшйся в течение всего времени существования обьекта уникальный идентификатор. + Объекты могут классифицироваться по типам и полтинам.
+ Состояние объекта определяется его данными и связями. + Поведение объекта определяется его методами. Объекты — фундаментальные единицы Согласно объскпюй модели ОВМС, объекты являются фундаментальными единицами хранения и манипулирования. В отличие от 501 3, где в качестве фундалсентальной единицы выступает таблица, а объекты хранятся в столбцах таблип, баювой суппгостью в ОВМС является объект. Конпспция ОВМС более похожа на концепцию объектноп программы в листинге 18.1. То есть прикладная программа определяет объекты сами по себе, а сделать ли их постоянными — решает ООСУБД.
Никаких других структур типа таблиц нс требуется. В соответствии с моделью ОВМС, объект может быть изменяемым ТшцгаЫс) и пеизмепяемым (1пт1пцсаЫе) Изменяемые объекты, как следуе~ из их названия, могут быть изменены; неизменяемые объекты являются постоянными, и пи одно приложение не может изменить состояние такого объекта.
Реализация неизменяемости возлагается на ООСУБД. ' Магу Е. 3. Соопнк, Оа)ем !)лгааозез, Г)и Емвлпадк исаа)пй МА: Аак!Ьоп-'Мвкъу, 1995, с. ВЗ вЂ” 110. 722 Глава 18. Объектно-ориентированные базы данных Стандарты ООСУБД 723 Каждый объект имеет пожизненный уникальный идентификатор Вторая фундаментальная идея объектной модели ОВМС состоит в том, что каждому объекту присваивается уникальный идентификатор, который является действительным на протяжешш времени сушествоваппя объекта. Более того, идентификатор должен быть действительным вце зависимости от того, где хранится объект — на внешнем носителе илп в оперативной памяти.
Настройка по адресам должна выполняться ООСУБД явно; прикладные программы могут использовать указатели на объекты так, как если бы онп всегда были действительны. Этот стандарт оставляет свободу в определении конкретной формы объектного идентификатора. Таким образом, различные производители ООСУБД могут использовать различные способы задания идентификаторов объектов. Это означает, что идентификаторы объектов пз различных баз данных, управляемых разными СУБД, не обязательно будут совместимыми. Для нераспределенных баз данных это вряд ли составит проблему, так как все объекты в данной объектной базе данных будут создаваться ц храниться одной н той же СУБД.
В распределенной системе проблема идентификации объектов является более сложной по двум причинам: во-первых, потому, что идентификаторы объектов в различных СУБД могут иметь различные форматы, а во-вторых, потому, что идентификаторы объектов не обязательно Будут уникальными в масштабе нес кольких баз данных. Этот вопрос оставлен без внимания в стандарте ОВМС-93. Объекты могут организовываться в иерархии ТИПОВ И ПОДТИПОВ Объектная модель стандарта ОВМС-93 указывает, что объекты организуются в группы по типу. Объекты создаются как припадлежашие к определенному типу.
Все объекты одного и того же типа имеют одинаковые характеристики н поведение. Объекты могут определяться как подтипы других объектов. В этом случае они наследуют все характеристики и поведение родительского типа. Согласно стандарту, объект создается как экземпляр определенного типа, и этот акземпляр не может изменить свой тип. Терлшны тип и кяисс часто используются как синонимы. Согласно Марн Лумис, зто неправильно. Объектный класс — это логическая группа объектов, как онп определены в ОВМС-93; классы имеют подюпассы, наследующие от своих родителей нх характеристики и поведение. Тип зто реализация класса на конкретном языке. Так, например, класс Сотрудник представляет сооой логическое определение данных и методов; он может иметь подклассы Продавец и Бухгалтер, являюшиеся его наследниками.
Реализапия класса Сотрудник на С++ называется типом, а реализации на С-н- подклассов Продавец и Бухгалтер называются подтипамп'. В языке Бп1а11еа)к класс Сотрудник может реализовываться по-другому. Эта реализация будет являть собой другой тпп. Различение класса н типа помогает отделить логические определения от конкретных реализаций логссческих структур. Объектные классы (а следовательно, и типы) могут иметь свойства. Стандарт ОВМС указывает, что каждый класс имеет имя и ограничения уникальности, Мму Г.
3. Еояяпь ОЬУеег ттатьпяеа Гъе ЕаепеЬЬ. Неагдпя, ите Адйюя-'Мейеу, 1995, с. 96. являющиеся его свойствами. Совокупность всех экземпляров объектного класса называется экстептом (ехгесн) объекта. Любой атрибут или комбинация атрпбутон может быть объявлена уникальной в масштабе экстента. Например, в классе Сотрудник атрибут НомерСотруднияа может беять объявлен уникальным, как может быть объявлено уникальным сочетание (Имя, Фамилия) н т. д. Поскольку требования уникальности относятся ко всему экстенту, а не к любому данному экземпляру объекта, такие требования являются свойствами класса, а не экземпляра класса.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
