В этой статье предпринимается попытка дать определение системы объектно-ориентированных баз данных. В ней описываются основные свойства и характеристики, которыми должна обладать система, претендующая на то, чтобы быть квалифицированной как система объектно-ориентированных баз данных.

Мы разделяем эти характеристики на три группы:

• Обязательные, т. е. такие, которыми система обязана обладать, чтобы ее можно было рассматривать как систему объектно-ориентированных баз данных. Это сложные объекты, идентифицируемость объектов, инкапсуляция, типы или классы, наследование, перекрытие методов совместно с отложенным связыванием, расширяемость, вычислительная полнота, стабильность, управление вторичной памятью, параллелизм, восстановливаемость и средства обеспечения незапланированных (ad hoc) запросов.
• Необязательные, т.е., такие, которые могут быть добавлены к системе для ее улучшения, но обязательными не являются. Это множественное наследование, проверка и вывод типов, распределенность, проектные транзакции и версии.
• Открытые, т. е, такие, которые проектировщик может реализовать по собственному усмотрению. Это парадигма программирования, система представления, система типов и однородность.

Мы не ожидаем, что данная статья станет последним словом, а рассматриваем ее скорее как отправную точку для дальнейшей дискуссии.

1. ВведениеВведение — в собственном смысле — предварительные сообщения общего характера, предпосылаемые произведению, обычно научного характера, с целью ввести читателя в курс предмета.

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

Можно выделить три характерные черты современного состояния дел:

1. отсутствие общепринятой модели данных,
2. отсутствие формального базиса и
3. активная экспериментаторская деятельность.

В то время как в классической статье Кодда [Codd 70] была предоставлена отчетливая спецификация систем реляционных баз данных (модель данных и язык запросов), для систем объектно-ориентированных баз данных подобная спецификация отсутствует [Maier 89]. Мы вовсе не хотим сказать, что не существует ни одной полной модели объектно-ориентированной базы данных. На самом деле, в литературе можно найти множество соответствующих предложений (см., например, [Albano et al. 1986], [Lecluse and Richard 89], [Carey et al. 88]), но отсутствует общее согласие по поводу какой-нибудь одной из предложенных моделей. Постепенно складывается общая точка зрения по поводу основных характеристик семейства объектно-ориентированных систем, однако в настоящее время отсутствует единое мнение о том, что из себя представляет объектно-ориентированная система, не говоря уже о системе объектно-ориентированных баз данных.

Второй чертой является отсутствие надежного теоретического базиса. В объектно-ориентированном программировании по сравнению с логическим программированием нет такой программной статьи, как [Van Emdem and Kowalski 76]. Необходимость в основополагающей теории очевидна: семантикаСемантика (от др.-греч. — обозначающий)— раздел языкознания, изучающий значение единиц языка. В качестве инструмента изучения применяют семантический анализ. В конце XIX— начале XX века семантика часто называлась также семасиологией (от др.-греч. smaino— указываю, означаю). Учёные, занимающиеся семантикой, до сих пор обычно называются семасиологами. Также «семантикой» может обозначаться сам круг значений некоторого класса языковых единиц (например, «семантика глаголов движения»). таких понятий, как типы или программы, зачастую часто является плохо определенной. Отсутствие надежного теоретического базиса делает практически невозможным достижениеДостижение— крупный посёлок сельского типа в Ковровском районе Владимирской области России. Входит в состав Клязьменского сельского поселения. единого мнения о модели данных.

Наконец, ведутся многочисленные экспериментальные разработки: люди реально строят системы. Некоторые из этих систем являются только прототипами [Bancilhon et al. 88], [Nixon, et al. 87], [Banerjee et al. 87], [Skarra et al. 86], [Fishman et al. 87], [Carey et al. 86], а некоторые – уже коммерческими продуктами [Atwood 85], [Maier, et al. 84], [Caruso and Sciore 87], [G-Base 88]. Как кажется, интересИнтерес— первоначально средневековый коммерческий и правовой термин (лат.interesse), обозначавший «возмещение ущерба». Отсюда развились, во-первых, чисто юридическое понятие интереса (уже в XIV веке— то, что затрагивает правовые интересы лица), и, во-вторых, финансовое понятие интереса (в XVI веке, сначала в значении «проценты за ссуду», т.е. страховка за риск невозврата). к объектно-ориентированным базам данным вызван потребностями систем поддержки проектирования (например, CAD, CASE, офисные информационные системы). Для этих приложений требуются базы данных, которые могут справляться с очень сложными данными, которые способМетод (от греч. — «способ»)— систематизированная совокупность шагов, действий, которые необходимо предпринять, чтобы решить определенную задачу или достичь определенной цели. В отличие от области знаний или исследований, является авторским, то есть созданным конкретной персоной или группой персон, научной или практической школой. В силу своей ограниченности рамками действия и результата, методы имеют тенденцию морально устаревать, преобразовываясь в другие методы, развиваясь в соответствии с временем, достижениями технической и научной мысли, потребностями общества. Совокупность однородных методов принято называть подходом. Развитие методов является естественным следствием развития научной мысли.ны развиваться, и которые обеспечивают высокую производительностьПроизводительность— внесистемная величина, равная отношению объема проделанной работы к времени, за которое она была совершена., требуемую интерактивным системам.

Ситуация с реализациями аналогична ситуации с системами реляционных баз данных в середине семидесятых (хотя в случае объектно-ориентированных систем наработок больше). В случае реляционных систем имелись некоторые разногласия по некоторым конкретным вопросВопрос— форма мысли, выраженная в языке предложением, которое произносят или пишут, когда хотят что-нибудь спросить, то есть узнать какую-то информацию. Если вопрос произносят, то используют вопросительную интонацию, а если пишут, то в конце ставят вопросительный знак. Задающий вопрос обычно ожидает ответ. Исключение составляет риторический вопрос, на который ответ не требуется.ам (например, как должен выглядеть язык запросов, или должны ли отношения быть множествами или мультимножествами), но эти различия были в большинстве случаев несущественными, и существовала общепринятая основополагающая модель. Люди, главным образом, занимались разработкой технологии реализации. СегодняСегодня — наречие, указывающее (кроме телевизионных рекламных анонсов) на «текущий» 24-часовой отрезок времени (с 00 до 24 часов по местному времени). мы одновременно решаем проблему спецификации системы и создаем технологию для поддержки ее реализации.

Таким образом, в отношении спецификации системы мы придерживаемся Дарвинистского подхода: мы надеемся, что из множества построенных экспериментальных прототипов сама собой появится подходящая модель. Мы также надеемся, что одновременно с ней появится жизнеспособная технология реализации этой модели.

К несчастью, при опоре на экспериментаторскую деятельность имеется риск принять в качестве образца некоторую систему не потому, что она является наиболее пригодной, а поскольку она окажется первой, обеспечивают значительный набор функциональных возможностей, отвечающих требованиям рынка. Это, к несчастью, типично для компьютерной области: первый продукт становится де-факто стандартом и таковым остается. Такая ситуацияСитуация— одноактность и неповторимость наступления множества событий, стечения всех жизненных обстоятельств и положений, открывающихся восприятию и деятельности человека. существует, по крайней мере, для языков и операционных систем (хорошие примеры представляют Fortran, Lisp, Cobol и SQL). Заметим, однако, что нашей целью является не стандартизация языков, а уточнение терминологииТерминология - наука о терминах. В настоящее время используется термин «терминоведение»..

Чрезвычайно важно прийти к согласию об определении систем объектно-ориентированных баз данных. В качестве первого шага к этой цели в данной статье предлагаются характеристики, которым должны отвечать такие системы. Мы надеемся, что статья будет рассматриваться как пробный шар, и что другие специалисты либо докажут несостоятельность, либо подтвердят основные положения данной статьи. Отметим, что эта статья не является обзором положения дел в технологии объектно-ориентированных систем баз данных (ООСБД) и не претендует на оценку современного состояния технологии, а только предлагает набор определений.

Мы разделяем характеристики систем объектно-ориентированных баз данных на три категории:

1. обязательные (те, которым система должна удовлетворять, чтобы иметь право называться объектно-ориентированной),
2. необязательные (те, которые могут быть добавлены для улучшения системы, но не являются обязательными) и
3. открытые (те места, где проектировщик может выбрать решение из набора одинаково приемлемых решений).

Кроме того, имеется некоторая возможность маневра в том, как лучше сформулировать каждую характеристику (это касается как обязательных, так и необязательных характеристик).

Статья организована следующим образом: в разд. 2 описываются обязательные свойства ООСБД, в разд. 3 – необязательные свойства, и в разд. 4 перечисляются степени свободы, которые предлагается оставить проектировщику системы.

2. Обязательные свойства: золотые правила

СистемаСистема (от др.-греч. — «сочетание»)— множество взаимосвязанных элементов, обособленное от среды и взаимодействующее с ней, как целое. объектно-ориентированных баз данных должна удовлетворять двум критериям: она должна быть СУБД и при этом являться объектно-ориентированной системой, т.е. в максимально возможной степени находиться на уровне современных объектно-ориентированных языков программирования. Первый критерий означает пять свойств: стабильность (persistence), управление вторичной памятью, параллелизм (concurrency), восстанавливаемость (recoveryRecovery (рус. Восстановление) — седьмой студийный альбом американского рэпера Eminem.Самый продаваемый альбом 2010 года в США.'а. Выход Recovery был подтвержден во время пресс-релиза Eminem’а, состоявшегося 5 марта 2009, и альбом был первоначально назван Relapse 2. Все было намечено на выпуск альбома продолжения в 2009, после выпуска альбома Relapse, но релиз был перенесен на следующий 2010 год. Позже было опубликованно окончательное название альбома, Recovery; также была подтверждена дата выпуска альбома: 21 июня в Соединенном Королевстве, (в остальных странах Европы 18 июня) 21 июня в Соединенных Штатах. Альбом дебютировал на первой строчке Billboard 200, Top Ramp;B/Hip-Hop Albums и Rap Albums Chart.) и средства обеспечения незапланированных (ad hoc) запросов. Второй означает восемь свойств: сложные объекты, идентифицируемость объектов (object identity), инкапсуляцию, типы или классы, наследование (object identity), перекрытие методов (overriding) совместно с отложенным связыванием (late binding), расширяемостьРасширяемость (англ.extensibility) означает возможность сравнительно легкого добавления отдельных элементов сети (пользователей, компьютеров, приложений, служб), наращивания длины сегментов сети и замены существующей аппаратуры более мощной. и вычислительную полноту.

2.1. Сложные объекты

Следует поддерживать сложные объекты

Сложные объекты строятся из более простых путем применения конструкторов. Простейшими являются такие объекты, как целые числа, символы, символьные строки произвольной длины, булевские значения и числа с плавающей точкой (можно было бы добавить другие атомарные типы). Имеются различные конструкторы сложных объектов: примерами могут служить кортежи (tuple), множества (set), мультимножества (bag), списки (list), массивы (array). Минимальный набор конструкторов, который должна иметь система, – это множества, списки и кортежи. МножестваМножество— одно из ключевых понятий математики, в частности, теории множеств и логики. необходимы, потому что они обеспечивают естественный способ представления коллекций реального мира. Кортежи необходимы, потому что они представляют естественный способ представления свойств сущностей. Конечно, важны и множества, и кортежи, поскольку они получили широкое распространение в качестве конструкторов объектов благодаря реляционной модели. Списки или массивы важны потому, что они сохраняют порядок, который имеет место в реальном мире, а также потому, что они присутствуют во многих научных приложениях в виде матриц или временных рядов.

Конструкторы объектов должны быть ортогональными: любой конструктор должен быть применим к любому объекту. Конструкторы реляционной модели не являются ортогональными, потому что конструкция множества может быть применена только к кортежам, а конструкция кортежа – только к атомарным значениям. Другими примерами являются реляционные модели с не первой нормальной формой (non-first normal form), в которых конструкцией верхнего уровня всегда должно быть отношение.

Отметим, что для поддержки сложных объектов необходимы соответствующие операции для работы с такими объектами (как бы они не были устроены). То есть операции со сложным объектом должны транзитивно распространяться на все его компоненты. Примерами могут быть выборка или удаление сложного объекта целиком или создание "глубокой" ("deep") копии (в отличии от "поверхностной" ("shallow") копии, в которой компоненты не копируются: в копии корня объекта указываются ссылки на компоненты копируемого объекта). Конечно, пользователь должен иметь возможность определять дополнительные операции со сложными объектами (см. ниже правило расширяемости). Однако для реализации этой возможности необходимы некоторые обеспечиваемые системой средства, такие как два различаемых типа ссылок ("является частью" ("is-part-of") и "общая" ("general")).

2.2. Идентифицируемость объектов

Следует поддерживать идентифицируемость объектов

Идентифицируемость объектов давно поддерживается в языках программирования. Для баз данных эта концепция сравнительно нова, см., например, [Hall и др. 76], [Maier и Price 84], [Khoshafian и Copeland 86]. Идея состоит в следующем: в модели с идентифицируемостью объектов объект существует независимо от его значения. Таким образом, имеется два понятия эквивалентности объектов: два объекта могут быть идентичны (они представляют собой один и тот же объект) или они могут быть равны (они имеют одно и тоже значение). Это влечет две следствия: первое – разделениеРазделение (организации) — прекращение юридического лица с передачей всех его прав и обязанностей нескольким (двум и более) вновь создаваемым юридическим лицам. объектов, а второе – изменения объектов.

РазделениеРазделение (организации) — прекращение юридического лица с передачей всех его прав и обязанностей нескольким (двум и более) вновь создаваемым юридическим лицам. объектов: в модели с идентифицируемыми объектами два объекта могут иметь совместно используемый компонент. Таким образом, схематическим представлением сложного объекта является граф, в то время как в системе без идентифицируемости объектов это дерево. Рассмотрим следующий пример: Человек имеет имя, возраст и некоторое количество детей. Предположим, что Питер и Сьюзан имеют 15-летнего сына по имени Джон. В реальной жизни могут иметь место две ситуации: Сьюзан и Питер являются родителями одного и того же ребенка или каждый из них имеет по сыну. В системе без идентифицируемости Питер представляется как:

(peter, 40, {(john, 15, {})}),

а Сьюзен как:

(susan, 41, {john, 15, {})}).

Таким образом, нет никакой возможно«Возможно» (фр.Peut-tre)— фильм режиссёра Седрика Клапиша 1999 года.сти выразить, являются ли Питер и Сьюзан родителями одного и того же ребенка или разных детей. В модели с идентифицируемостью объектов эти две структуры либо имеют общую часть (john, 15, { }), либо не имеют ее, так что поддерживаются обе ситуации.

Изменения объектов: предположим, что Питер и Сьюзан действительно являются родителями мальчика по имени Джон. В этом случае все исправления, касающиеся сына Сьюзан, будут производиться с объектом Джон, а следовательно, и с сыном Питера. Идентифицируемость объектов, кроме того, обеспечивает мощный примитив манипулирования данными, который может служить основой для манипулирования множествами, кортежами или рекурсивными сложными объектами [Abiteboul and Kanellakis 89].

Поддержка идентифицируемости объектов обеспечивает возможность реализации таких операций, как присваиваниеПрисваивание — механизм в программировании, позволяющий динамически изменять связи объектов данных (как правило, переменных) с их значениями. Строго говоря, изменение значений является побочным эффектом операции присвоения, и во многих современных языках программирования сама операция также возвращает некоторый результат (как правило, копию присвоенного значения). На физическом уровне результат операции присвоения состоит в проведении записи и перезаписи ячеек памяти или регистров процессора. объекта, копированиеКопирование (от лат.copia— множество)— процесс изготовления копии, то есть воспроизведения объекта, процесса, явления, информации. объекта (как глубокое, так и поверхностное) и проверка идентичности объектов и их равенства (как глубокого, так и поверхностного).

Конечно, можно моделировать идентифицируемость объектов в системе, основанной на идентификации посредством значений, путем введения явных идентификаторов объектов. Однако такой подход перекладывает на пользователя бремя обеспечения уникальности идентификаторов объектов и поддержки ссылочной целостности (и это бремя может быть весьма значительным для таких операций, как сборка мусора (garbageGarbage— американская рок-группа, образованная в США в городе Мэдисон, штат Висконсин в 1994 году. collection)).

Заметим, что модели с идентифицируемостью объектов являются нормой в императивных языках программирования: каждый объект, с которым имеет дело программа, идентифицируем и может быть изменен. Идентифицируемость объекта возможна за счет наличия имени переменной или соответствующего физического адреса памяти. Однако эта концепция совершенно нова для чисто реляционных систем, где идентифицируемость кортежей отношения основывается на значениях.

2.3. Инкапсуляция

Объекты следует инкапсулировать

Идея инкапсуляции происходит

1. из потребности отчетливо различать спецификации и реализации операций и
2. из потребности в модульности.

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

Имеются две точки зрения на проблему инкапсуляции: точка зрения с позиций языка программирования (которая является исходной точкой зрения, так как эта концепция ведет свое начало отсюда) и адаптация этой точки зрения применительно к базам данных.

Идея инкапсуляции в языках программирования происходит от абстрактных типов данных. С этой точки зрения объект делится на интерфейсную часть и реализационную часть. ИнтерфейсИнтерфейс (от англ.interface— поверхность раздела, перегородка)— совокупность средств, методов и правил взаимодействия (управления, контроля ит.д.) между элементами системы.ная часть является спецификацией набора допустимых над объектом операций. Только эта часть объекта видима. Реализационная часть состоит из части данных и процедурной части.

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

Интерпретация этого принципа для баз данных состоит в том, что объект инкапсулирует и программу, и данные. В мире баз данных не вполне ясно, является или нет структурная часть типа частью интерфейса (это зависит от системы), в то время как в мире языков программирования структура данных явно является частью реализации, а не интерфейса.

Рассмотрим, например, объект Служащий. В реляционной системе Служащий представляется кортежем. ЗапросЗапрос— это формулирование своей информационной необходимости пользователем некоторой базы данных, как, например, поисковой системы. Для составления запроса используется язык поисковых запросов. к нему осуществляется с помощью реляционного языка, а прикладной программист пишет программы для изменения этой записи, например повышение зарплаты Служащего или прием на работу. Такие программы обычно пишутся либо на императивном языке программирования с включением в него операторов языка манипулирования данными или на языке четвертого поколения и хранятся в обычной файловой системе, а не в базе данных. Таким образом, при таком подходе имеются кардинальные различия между программой и данными, а также между языком запросов (для незапланированных запросов) и языком программирования (для прикладных программ).

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

Таким образом, имеется единая модель для данных и операций, и информация может быть скрыта. Нельзя выполнить никакие иные операции, помимо указанных в интерфейсе. Это ограничение справедливо как для операций изменения, так и для операций выборки.

ИнкапсуляцияИнкапсуляция (лат.in-в, capsula- коробочка; итал. incapsulare - закупоривать) обеспечивает разновидность логической независимости данных (logical data independence): мы можем изменить реализацию типа, не меняя каких-либо программ, использующих этот тип. Таким образом, прикладные программы защищены от реализационных изменений на нижних слоях системы.

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

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

2.4. Типы и классы

Следует поддерживать типы или классы

Это весьма деликатный вопрос: имеются две основные категории объектно-ориентированных систем – те, которые поддерживают классы, и те, которые поддерживают типы. К первой категории относятся такие системы, как SmalltalkSmalltalk (произносится [смолток])— объектно-ориентированный язык программирования с динамической типизацией, разработанный в Xerox PARC Аланом Кэйем, Дэном Ингаллсом, Тедом Кэглером, Адель Голдберг, и другими в 1970-х годах. Язык был представлен как Smalltalk-80. Smalltalk продолжает активно развиваться и собирает вокруг себя сообщество пользователей. [Goldberg and Robson 83], Gemstone [Maier, et al. 84], Vision [Caruso and Sciore 81], все системы семейства Smalltalk: Orion [Banerjee et al. 87], Flavors [Bobrow and Steifik 81], G-Base [G-Base 88], Lore [Caseau 89] и, вообще говоря, все системы, ведущие свое происхождение от языка Lisp. Представителями второйВторой — второй по счёту альбом песен Владимира Высоцкого в исполнении Григория Лепса, записанный и вышедший в 2007 году категории являются такие системы, как C++ [Stroustrup 86], SimulaСимула-67 (Simula 67)— первый в мире объектно-ориентированный язык программирования. Разработан в конце 60-х сотрудниками Норвежского Вычислительного Центра (Осло) Кристеном Нюгордом и Оле-Йоханом Далем для моделирования сложных систем. [Simula 67], Trellis/Owl [Schaffert, и др. 86], Vbase [Atwood 85] и O2 [Bancilhon et al. 88].

В объектно-ориентированной системе тип обобщает общие черты множества объектов с одинаковыми характеристиками. Он соответствует понятию абстрактного типа данных. Он делится на две части: интерфейс и реализация (реализации). Пользователям типа видна только интерфейсная часть, а реализация объекта видна только проектировщикПроект (от лат.projectus— брошенный вперед, выступающий, выдающийся вперёд)— это уникальная (в отличие от операций) деятельность, имеющая начало и конец во времени, направленная на достижение заранее определённого результата/цели (уникального продукта) при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска.у типа. Интерфейс состоит из списка операций вместе с их сигнатурами (т. е. типами входных параметров и типом результата).

Реализация типа состоит из части данных и части операций. Часть данных описывает внутреннюю структуру данных объекта. В зависимости от мощности системы часть данных может быть более или менее сложной. Часть операций состоит из процедур, которые реализуют операции интерфейсной части.

В языках программирования типы являются средствами увеличения продуктивности программиста за счет обеспечения корректности программ. Принуждая пользователя объявлять типы переменных и выражений, которые он манипулирует, система судит о корректности программ на основе этой информации о типах. Если система типов тщательно разработана, то система может произвести проверку типов во время компиляции, иначе некоторые проверки могут быть отложены до времени выполнения. Таким образом, типы главным образом используются во время компиляции для проверки корректности программ. Вообще говоря, в основанных на типах системах тип не является "гражданином первого сорта", а имеет специальный статус и не может быть изменен во время выполнения.

ПонятиеПонятие— отображённое в мышлении единство существенных свойств, связей и отношений предметов или явлений; мысль или система мыслей, выделяющая и обобщающая предметы некоторого класса по определённым общим и в совокупности специфических для них признаков. класса отличается от понятия типа. Его спецификация совпадает со спецификацией типа, но это понятие является более динамическим. Класс характеризуется двумя аспектами: фабрика объектов (object factory) и склад объектов (object warehouse). Фабрика объектов может быть использована для создания новых объектов посредством выполнения операции new данного класса или клонирования некоторого объекта-прототипа, являющегося представителем данного класса. Склад объектов означает, что к классу присоединяется его расширение (extension), т.е. множество объектов, которые являются экземплярами класса. Пользователь может манипулировать складом, применяя операции ко всем экземплярам класса. КлассыКласс (от лат.classis— группа) в классификации— группа предметов или явлений, обладающих общими признаками. используются не для проверки правильности программы, а скорее для создания и манипулирования объектами. В большинстве систем, которые используют механизм классов, классы являются "гражданами первого сорта" и, как таковыми, ими можно манипулировать во время выполнения, т. е. изменять их и передавать как параметры. В большинстве случаев это делает невозможным проверку типов во время компиляции, но придает системе большую гибкость и однородностьОднородная функция степени q— числовая функция такая, что для любого и 2.5. Иерархии классов или типов

Для классов или типов следует поддерживать наследование

Наследование обладает двумя достоинствами:

• оно является мощным средством моделирования, поскольку обеспечивает возможность краткого и точного описания мира;
• эта возможность помогает факторизовать, спецификации и реализации, совместно используемые в приложениях.

Следующий пример иллюстрирует потребность наличия в системе наследования. Допустим, что мы имеем дело со Cлужащими и Студентами. Каждый Cлужащий имеет имя, возраст более 18 лет и оклад, он или она может умереть, выйти замуж или жениться или получить зарплату (как скучна жизнь Cлужащего!). Каждый Студент имеет имя, возраст и множество оценок. Он или она может умереть, выйти замуж или жениться, и для него или нее может быть вычислен GPA (Grade Point Average, средний академический балл).

В реляционной системе проектировщик базы данных определяет отношение для Cлужащего, отношение для Студента, пишет программы для реализации операций умереть, жениться и получить зарплату над отношением Cлужащий и программы для реализации операций умереть, жениться, и вычислить GPA над отношением Студент. Таким образом, прикладной программист должен написать шесть программ.

В объектно-ориентированной системе, используя свойствоСвойство (в философии, математике и логике)— атрибут предмета (объекта). Например, о красном предмете говорится, что он обладает свойством красноты. Свойство можно рассматривать как форму предмета самого по себе, притом, что он может обладать и другими свойствами. Свойства, следовательно, подпадают под действие парадокса Рассела и парадокса Греллинга-Нельсона. наследования, мы распознаем, что каждый Cлужащий и Студент является Человеком; таким образом, они имеют кое-что общее (то, что каждый из них является Человеком) и некоторые различия.

Мы вводим тип Человек, атрибутами которого являются имя и возраст и пишем программы для реализации операций умереть и жениться для этого типа. Затем мы объявляем, что Cлужащие являются особой разновидностью Человека, в которой наследуются атрибуты и операции типа Человек и имеются свои собственные атрибут оклад и операция получить зарплату. Аналогично, мы объявляем, что Студент является специальной разновидностью Человека со своими собственными атрибутом набор оценок и операцией вычислить GPA. В этом случае мы имеем более структурированное и краткое описание схемы (мы факторизовали спецификацию), и нам потребовалось написать всего четыре программы (мы факторизовали реализацию). Наследование способствует повторному использованию кода, потому что каждая программа находится на том уровне, на котором ее может совместно использовать наибольшее число объектов.

Имеется по крайней мере четыре типа наследования:

1. наследование через подстановку (substitution inheritance),
2. наследование путем включения (inclusion inheritance),
3. наследование через ограничение (constraint inheritance) и
4. наследование через специализацию (specialization inheritance).

Говоря про наследование через подстановку, мы имеем в виду, что тип t наследует от типа t', если мы можем выполнить больше операций над объектами типа t, чем над объектом типа t'. Таким образом, вместо объекта t' мы всегда можем подставить объект типа t. Этот тип наследования базируется на поведении, а не на значениях.

Наследование путем включения соответствует понятию классификации. В этом случае утверждается, что тип t является подтипом t', если каждый объект типа t является также объектом типа t'. Этот тип наследования базируется на структуре, а не на операциях. Примером являются тип квадрат с методами получить(размер), установить(размер) и тип раскрашенный квадрат с методами получить(размер), установить(размер) и раскрасить(цвет).

Наследование через ограничение является частным случаем наследования путем включения. Тип t является подтипом типа t', если к нему относятся все объекты типа t', которые удовлетворяют данному ограничению. Примером такого наследования является класс подросток как подкласс класса человек: объекты класса подросток не имеют дополнительных полей или операций по сравнению с объектами класса человек, но они удовлетворяют более специфичным ограничениям (возраст подростков ограничен снизу 13, а сверху 19 годами).

При наследовании через специализацию тип t является подтипом t', если объекты типа t являются объектами типа t', но при этом содержат более специфичную информацию. Примером являются типы люди и служащие, где информация о служащих является той же самой, что и информация о людях, но включает некоторые дополнительные поля.

Существующие системы и прототипы в той или иной мере поддерживают эти четыре типа наследования. Мы, в свою очередь, не хотим навязывать какой-либо конкретный стиль наследования.

2.6. Перекрытие, перегрузка и позднее связывание

Не следует производить преждевременное связывание

По контрасту с предыдущим примерПример рассматривается в риторике чаще всего в контексте доказательств и аргументов. Для Квинтилиана пример является одним из дополняющих, наглядных доводов к высказыванию, либо упоминанием полезного, настоящего или якобы существующего образца убеждения того, что определено тобой одним. Правда, в отличие от доказательств, связь с предметом обсуждения должна быть установлена прежде автором или оратором.ом, имеются случаи, когда желательно иметь для различных операций одно и то же имя. Рассмотрим, например, операцию отображения: она принимает на входе объект и отображает его на экране. В зависимости от типа объекта используются разные механизмыМеханизм (греч. mechan— машина)— это совокупность совершающих требуемые движения тел (обычно— деталей машин), подвижно связанных и соприкасающихся между собой. Механизмы служат для передачи и преобразования движения. отображения. Если объект является изображением, то мы хотим, чтобы оно действительно появилось на экране. Если объект является человеком, то мы хотим, чтобы в том или ином виде был напечатан описывающий человека кортеж. Наконец, если объект является графом, то мы хотели бы иметь его графическое представление. Рассмотрим теперь задачу отображения множества, тип членов которого не известен во время компиляции.

В приложениях, использующих традиционные системы, мы имели бы три операции: отобразить объект человек (display-person), отобразить растровое изображение (display-bitmap) и отобразить граф (display-graph). Программист проверил бы тип каждого объекта, входящего во множество, и использовал бы соответствующую операцию отображения. Это обязывает программиста знать все возможные типы объектов, которые могут входить в заданное множество, а также соответствующие им операции отображения, и использовать их согласованным образом.

for x in X do 
  begin
    case of type(x)
      person: display(x);
      bitmap: display-bitmap(x); 
      graph: display-graph(x);
  end
end

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

for x in X do display(x)

Здесь мы получаем иную выгоду: реализатор типов по-прежнему должен писать то же количество программ. Но прикладному программисту уже не нужно заботиться о трех различных программах. Кроме того, код проще, так как оператор case над типами отсутствует. Наконец, код становится более сопровождаемым, поскольку и при введении нового типа, и при добавлении нового экземпляра существующего типа программа отображения будет работать без изменения (при условии, что для этого нового типа мы обеспечим перекрытиеПерекрытие— горизонтальная внутренняя защитная конструкция, которая разделяет по высоте смежные помещения в здании. методаМетод (от греч. — «способ»)— систематизированная совокупность шагов, действий, которые необходимо предпринять, чтобы решить определенную задачу или достичь определенной цели. В отличие от области знаний или исследований, является авторским, то есть созданным конкретной персоной или группой персон, научной или практической школой. В силу своей ограниченности рамками действия и результата, методы имеют тенденцию морально устаревать, преобразовываясь в другие методы, развиваясь в соответствии с временем, достижениями технической и научной мысли, потребностями общества. Совокупность однородных методов принято называть подходом. Развитие методов является естественным следствием развития научной мысли. отображения).

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

Отметим, что хотя отложенное связывание затрудняет проверку типов (а в некоторых случаях делает ее невозможной), оно не отменяет ее полностью.

2.7. Вычислительная полнота

Следует поддерживать вычислительную полноту

С точки зрения языка программирования это свойство является очевидным: оно просто означает, что любую вычислимую функцию можно выразить с помощью языка манипулирования данными системы баз данных. С точки зрения базы данных это является новшеством, так как SQL, например, не является полным языком.

Мы не призываем проектировщиков объектно-ориентированных систем баз данных к созданию новых языков программирования: вычислительной полноты можно добиться, разумным образом опираясь на существующие языки программирования. И на самом деле, в большинстве систем используются уже существующие языки программирования [Banerjee et al. 87], [Fishman et al. 87], [Atwood 85], [Bancilhon et al. 88]; обсуждениеДиалог (греч. — первоначальное значение— разговор, беседа двух людей) в обыденном смысле— литературная или театральная форма устного или письменного обмена высказываниями (репликами) в разговоре между двумя и более людьми;— в философском и научных смыслах— специфическая форма и организация общения, коммуникации. Традиционно противопоставляется монологу. этой проблемы см. в [Bancilhon and Maier 88].

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

2.8. РасширяемостьРасширяемость (англ.extensibility) означает возможность сравнительно легкого добавления отдельных элементов сети (пользователей, компьютеров, приложений, служб), наращивания длины сегментов сети и замены существующей аппаратуры более мощной.

Cледует поддерживать расширяемость

Система базы данных поставляется с набором предопределенных типов. Эти типы могут при желании использоваться программистами для написания приложений. Набор предопределенных типов должен быть расширяемым в следующем смысле: должны иметься средства для определения новых типов и не должно быть различий в использовании системных и определенных пользователем типов. Конечно, способы поддержки системой системных и пользовательских типов могут значительно различаться, но эти различия должны быть невидимыми для приложения и прикладного программиста. Напомним, что определение типов включает определение операций этих типов. Заметим, что требование инкапсуляции подразумевает наличие механизма для определения новых типов. Требование расширяемости усиливает эту возможность, указывая, что вновь созданные типы должны иметь тот же статусСтатус— абстрактный многозначный термин, в общем смысле обозначающий совокупность стабильных значений параметров объекта или субъекта. С упрощённой точки зрения статус объекта или субъекта— это его состояние., что и существующие.

Однако мы не требуем, чтобы расширяемой была совокупность конструкторов типов (кортежей, множеств, списков и т.д.).

2.9. Стабильность

Данные не должны забываться

Это требование очевидно с точки зрения баз данных, но является новым с точки зрения языков программирования [Atkinson et al. 83]. Стабильность (persistence) означает возможность программиста обеспечить сохранность данных после завершения выполнения процесса с целью последующего использования в другом процессе. Свойство стабильности должно быть ортогональным, т.е. для каждого объекта вне зависимости от его типа должна иметься возможность сделать его стабильным (т.е. без какой-либо явной переделки объекта). СтабильностьСтабильность— способность системы функционировать, не изменяя собственную структуру, и находиться в равновесии. Это определение должно быть неизменным во времени. должна быть неявной: чтобы сделать данныеДанные (калька от лат.data) — это представление фактов и идей в формализованном виде, пригодном для передачи и обработки в некотором информационном процессе. стабильными, пользователь не должен быть обязан явно перемещать их или копировать.

2.10. Управление вторичной памятью

Следует уметь управлять очень большими базами данных

Управление вторичной памятью является классической чертой систем управления базами данных. Эта возможность обычно поддерживается с помощью набора механизмов. Среди них управление индексами, кластеризацияКластерный анализ (англ.Data clustering)— задача разбиения заданной выборки объектов (ситуаций) наподмножества, называемые кластерами, так, чтобы каждый кластер состоял изсхожих объектов, аобъекты разных кластеров существенно отличались. Задача кластеризации относится к статистической обработке, а также к широкому классу задач обучения без учителя. Кластерный анализ— это многомерная статистическая процедура, выполняющая сбор данных, содержащих информацию о выборке объектов, и затем упорядочивающая объекты в сравнительно однородные группы (кластеры)(Q-кластеризация, или Q-техника, собственно кластерный анализ). Кластер— группа элементов, характеризуемых общим свойством, главная цель кластерного анализа— нахождение групп схожих объектов в выборке (примечание 1). Спектр применений кластерного анализа очень широк: его используют в археологии, медицине, психологии, химии, биологии, государственном управлении, филологии, антропологии, маркетинге, социологии и других дисциплинах. «Тематика исследований варьирует от анализа морфологии мумифицированных грызунов в Новой Гвинее до изучения результатов голосования сенаторов США, от анализа поведенческих функций замороженных тараканов при их размораживании до исследования географического распределения некоторых видов лишая в Саскачеване» (примечание 1). Однако универсальность применения привела к появлению большого количества несовместимых терминов, методов и подходов, затрудняющих однозначное использование и непротиворечивую интерпретацию кластерного анализа. данных, буферизацияБуферизация (от англ.buffer) — метод организации обмена, в частности, ввода и вывода данных в компьютерах и других вычислительных устройствах, который подразумевает использование буфера для временного хранения данных. При вводе данных одни устройства или процессы производят запись данных в буфер, а другие — чтение из него, при выводе — наоборот. Процесс, выполнивший запись в буфер, может немедленно продолжать работу, не ожидая, пока данные будут обработаны другим процессом, которому они предназначены. В свою очередь, процесс, обработавший некоторую порцию данных, может немедленно прочитать из буфера следующую порцию. Таким образом, буферизация позволяет процессам, производящим ввод, вывод и обработку данных, выполняться параллельно, не ожидая, пока другой процесс выполнит свою часть работы. Поэтому буферизация данных широко применяется в многозадачных ОС. данных, выбор пути доступа и оптимизация запросов.

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

2.11. Параллелизм

Следует поддерживать параллельную работу нескольких пользователей

Что касается управления параллельным взаимодействием с системой нескольких пользователей, то должны обеспечиваться услуги того же уровня, который предоставляют современные системы баз данных. Поэтому система должна обеспечивать гармоническое сосуществование пользователей, одновременно работающих с базой данных. Следовательно, система должна поддерживать стандартное понятие атомарности последовательности операций и управляемого совместного доступа. Должна, по крайней мере, обеспечиваться сериализуемость (serializability) операций, хотя могут и менее жесткие альтернативы.

2.12. Восстановление

Следует обеспечивать восстановление после аппаратных и программных сбоев

И в этом случае систем, должна обеспечивать услугиУслуга— совершённое одним лицом (физическим или юридическим) в интересах другого лица действие или деятельность. того же уровня, который предоставляют современные системы баз данных. Следовательно, в случае аппаратных или программных сбоев система должна восстанавливаться, т.е. возвращаться к некоторому согласованному состоянию данных. Аппаратные сбои включают как сбои в работе процессора, так и сбои дисков.

2.13. Средства обеспечения незапланированных запросов

Следует обеспечивать простой способ запросов данных

Здесь основной проблемой является обеспечение функциональности языка незапланированных (ad hoc) запросов. Мы не призываем к тому, чтобы это обязательно было реализовано в виде языка запросов, а только к тому, чтобы была такая услуга существовала. Например, для обеспечения этой функциональной возможности вполне достаточна графическая программа просмотра. Услуга состоит в том, что пользователь может без затруднений сделать простой запрос к базе данных. Очевидной мерой являются, конечно, реляционные системы. Поэтому проверка наличия средства незапланированных запросов состоит в том, чтобы взять на пробу несколько реляционных запросов и проверить, можно ли их сформулировать с теми же трудозатратами. Заметим, что это средство могло бы поддерживаться языком манипулирования данными или его подмножеством.

Мы полагаем, что средство обеспечения запросов должно удовлетворять следующим трем критериям:

1. Оно должно быть средством высокого уровня, т. е., пользователь должен иметь возможность кратко выразить нетривиальные запросы (в нескольких словах или несколькими нажатиями клавиш мыши). Это означает, что средство формулирования должно быть достаточно декларативным, т. е. упор должен быть сделан на что, а не на как.
2. Оно должно быть эффективным. Т.е., формулировка запросов должна допускать возможность оптимизации запросов.
3. Средство запросов не должно зависеть от приложения, т.е. оно должно работать с любой возможной базой данных. Это последнее требование устраняет потребностьПотребность, нужда— внутреннее состояние психологического или функционального ощущения недостаточности чего-либо и проявляются в зависимости от ситуационных факторов. в специфических средствах обеспечения запросов для конкретных приложений и необходимость написания дополнительных операций для каждого определенного пользователем типа.

2.14. Заключение

Этим исчерпывается списокСписок— письменный перечень, число, состав; документ, содержащий перечень каких-либо сведений; в переносном смысле— буквальное, точное воспроизведение, копия; рукописная копия древнего памятника письменности. обязательных характеристик. Надеемся, что нам удалось прояснить различия между системами традиционными и объектно-ориентированными системами баз данных. Реляционные системы баз данных не удовлетворяют правилам с первого по восьмое. Системы баз данных CODASYL частично удовлетворяет правилам 1 и 2. Некоторые люди придерживаются того мнения, что объектно-ориентированные системы баз данных есть ни что иное, как системы CODASYL. Следует отметить, что

1. системы CODASYL не удовлетворяют полностью этим двум правилам (конструкторы объектов не являются ортогональными, и не обеспечивается однородная идентифицируемость объектов, поскольку допускаются только связи 1:n), и
2. эти системы не удовлетворяют правилам 3, 5, 6, 8 и 13.

Приведем те свойства, по поводу которых авторы не достигли согласия, должны ли они быть обязательными или нет. Эти свойства включают следующее:

• определение представлений и порождаемых данных;
• утилиты администрирования баз данных;
• ограничения целостности;
• утилиты, поддерживающие эволюцию схемы.

3. Необязательные возможности: конфетки

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

Некоторые из этих возможностей являются объектно-ориентированными по свой природе (например, множественное наследование). Они отнесены к категории необязательных возможностей потому, что хотя и делают систему более объектно-ориентированной, не входят в набор ключевых требований.

Другие возможности являются просто возможностями систем баз данных (например, управление проектными транзакциями). Эти характеристики обычно улучшают функциональные возможности систем баз данных, но не относятся к ключевым требованиям, предъявляемым к таким системам, и они не связаны с аспектом объектной-ориентированности. В действительности, многие из этих возможностей предназначены для обслуживания "новых" приложений (CAD/CAM, CASE, офисная автоматизация и т. д.) и являются более ориентированными на приложения, чем на технологии. Так как многие системы объектно-ориентированных баз данных нацелены на эти новые приложения, то существует некоторая путаница между этими возможностями и объектно-ориентированной природой системы.

3.1. Множественное наследование

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

3.2. Проверка и вывод типов

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

3.3. Распределенность

Ясно, что эта характеристика является ортогональной к объектно-ориентированной природе системы. Таким образом, система баз данных может быть как распределенной, так и нет.

3.4. Проектные транзакции

Для большинства новых приложений модель транзакций классической бизнес-ориентированной системы баз данных является неудовлетворительной: транзакции могут длиться очень долго, и обычный критерий сериализуемости не является адекватным. Поэтому во многих ООСБД поддерживаются проектные транзакции (протяженные транзакции или вложенные транзакцииТранзакция (англ.transaction)— в информатике, группа последовательных операций, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще и тогда она не должна произвести никакого эффекта. Транзакции обрабатываются транзакционными системами, в процессе работы которых создаётся история транзакций.).

3.5. Версии

Большинство новых приложений (CAD/CAM и CASE) предполагает проектную деятельность, и для этого требуется какая-либо поддержка версий. Поэтому многие ООСБД поддерживают версии. И в этом случае обеспечение механизма поддержки версий не является ключевым требованием к системе.

4. Открытые возможности

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

4.1. Парадигма программирования

Мы не видим причины, по которой одной парадигме программирования следует отдать предпочтение перед другой: в качестве парадигмы программирования можно выбрать стиль логического программирования [Bancilhon 86], [Zaniolo 86], стиль функционального программирования [Albano et al. 1986], [Banerjee et al. 87] или стиль императивного программирования [Stroustrup 86], [Eiffel 87], [Atwood 85]. Другим решением может быть независимость системы от стиля программирования и поддержка нескольких парадигм программирования [Skarra и др. 86], [Bancilhon и др. 88].

Конечно, каждый волен свободно выбирать синтаксис, и программисты будут вечно спорить, правильнее ли писать john hire, john.hire, hire john, или hire(john).

4.2. Система представления

Система представления определяется набором атомарных типов и набором конструкторов. Хотя мы и указали минимальный набор атомарных типов и конструкторов (элементарные типы языков программирования и конструкторы множеств, кортежей и списков), который должен быть доступен для описания представления объектов, этот набор может быть расширен множеством разнообразных способов.

4.3. Система типов

Также остается свобода в выборе формирователей типов. Единственным средством формирования типов, наличия которого мы требуем, является инкапсуляция. Возможны другие формирователи типов, такие как родовые типы или генераторы типов (например, set[T], где T может быть произвольным типом), ограничение, объединение или стрелка (функции).

Система типов может быть первого или второго порядка. Наконец, система типов для переменных может быть богаче системы типов для объектов.

4.4. Однородность

Ведутся жаркие споры о степени однородности таких систем. Является ли тип объектом? Является ли метод объектом? Следует ли эти три понятия рассматривать отдельно? Эту проблему можно рассматривать на трех разных уровнях: уровне реализации,

уровне языка программирования и

уровне интерфейса.

На уровне реализации необходимо решить, будет ли информация о типе храниться как объект или будет реализована некоторая специализированная система. Это тот же самый вопрос, с которым сталкиваются проектировщики систем реляционных баз данных при принятии решения о том, как следует хранить схему: в виде таблицы или некоторым специальным образом. Решение следует принимать с учетом эффективности и простоты реализации. Какое бы ни было принято решение, оно не зависит от решения, принимаемого на более высоком уровне.

На уровне языка программирования вопрос состоит в том, являются ли типы сущностями первого сорта в семантике языка. Споры ведутся главным образом вокруг этого вопроса. По-видимому, имеются различные стили однородности (синтаксический и семантический). Полная однородность на этом уровне также не согласуется со статической проверкой типов.

Наконец, на уровне интерфейса требуется принять еще одно независимое решение. Типы, объекты и методы могут быть представлены для пользователя как однородные, если даже в семантике языка программирования они предстают как различные по своей природе понятия. И наоборот, они могут быть представлены для пользователя как различные сущности, хотя язык программирования не делает между ними различия. Это решение следует принимать с учетом человеческого фактора.

5. Заключительные замечания

Некоторые авторы [Kim 88] и [Dittrich 1986] придерживаются той точки зрения, что ООСБД есть СУБД, основанная на объектно-ориентированной модели данных. Если использовать понятие модели данных в широком смысле, учитывая, в частности, дополнительные аспекты, выходящие за рамки ориентированности на работу с записями, то эта точка зрения, несомненно, согласуется с нашей. В [Dittrich 1986] и [Dittrich 1988] вводится классификация объектно-ориентированных моделей данных (и, следовательно, ООСБД): модель называется структурно объектно-ориентированной, если она поддерживает сложные объекты; модель называется поведенчески объектно-ориентированной, если она обеспечивает расширяемость; для того чтобы модель была полностью объектно-ориентированной, она должна обладать обоими свойствами. В соответствии с определением требуется также поддержка свойства стабильности, управленияУправление— воздействие субъекта, направленное на достижение абстрактной (неконкретной), но вынужденно-корректируемой цели (задачи, идеи) в уже сложившихся рамках правил, которые неизбежно-совершенствуются когда субъект непротиворечивее познаёт реальность, с которой сосуществует. дисками, параллелизма и восстанавливаемости; определение, по крайней мере, неявно, подразумевает наличие большинства других свойств (в тех случаях, где они применимы в зависимости от класса системы); в целом, это определение является более либеральным, чем наше. Однако, поскольку большинство систем и прототипов все равно не удовлетворяют всем требованиям, которые налагает наше определение, эта классификация предоставляет основу для сравнения выполненных и продолжающихся работ.

Мы предложили набор определяющих характеристик объектно-ориентированной системы баз данных. Насколько нам известно, золотые правила, данные в этой статье, являются в настоящее время наиболее детальным определением объектно-ориентированной системы базы данных. Выбор характеристик и наша интерпретация опирается на опыт в спецификации и реализации систем нынешнего поколения. Накопление опыта в проектировании, реализации и формализации объектно-ориентированных баз данных без сомненияСомнение— психическое состояние или состояние ума в котором возникает воздержание от окончательно определённого суждения, или/и раздвоения (троення ит.п.) его становления, из-за неспособности сознания сделать дискретный однозначный вывод. Если ум не может обнаружить причин, аргументов, которые бы позволили ему прийти к однозначному решению относительно правильности или ошибочности своего мнения, тогда сомнение является отрицательным (то есть фактически блокирование дальнейшего анализа и выводов, «избегание» дискретизации). Если же разум выявил причины и они равной, подобной, сравнительной важности, делая таким образом унитарное решающее мнение невозможным, тогда сомнение считается позитивным (включающим инвариантность). В обоих случаях результатом является: невозможность формирования окончательного суждения (воздержание от него). Существует множество примеров где человек не может победить дискретизировать, перевести в стадию определенности) свои сомнения. приведет к изменению наших взглядов и более глубокому пониманию проблемы (другими словами, не удивляйтесь, если услышите в будущем, что одни из авторов ниспровергают приведенное здесь определение). Нашей целью было предоставление научному сообществу конкретного предложения для обсуждения, критики и анализа. Поэтому наше последнее правило можно сформулировать следующим образом:

Ставьте под сомнения "золотые" правила

Благодарности

В заключении мы хотели бы выразить признательность Филиппу Брайдону (Philippe Bridon), Джильберту Харрусу(Gilbert Harrus), Парису Канеллакису (Paris Kanellakis), Филиппу Ричарду (Philippe Richard) и Фернандо Велецу (Fernando Velez) за предложения и замечания, высказанные ими по поводу статьи.

Литература

1. [Abiteboul and Kanellakis 89] S. Abiteboul and P. Kanellakis, "Object identity as a query language primitivePrimitive — второй студийный альбом нью-метал-группы Soulfly.Вышел в сентябре 2000 года на лейбле Roadrunner Records.", Proceedings of the 1989 ACM SIGMOD, PortlandКлассификация роз— разделение роз на классы и условные группы на основе устойчивых садовых признаков. Создана Американским обществом розоводов (ARS). Утверждена в 1976 году Всемирной федерацией обществ розоводов (WFRS). Последняя версия опубликована в «Modern Roses» XI. The World Encyclopedia of Roses. Academic Press. 2000. Русские названия приведены по Флоре Восточной Европы (т. X, 2001), книге Бумбеева Л.И.Плетистые розы., Oregon, June 89
2. [Albano et al. 1986] A. Albano, G. Gheli, G. Occhiuto and R. Orsini, "Galileo: a strongly typed interactive conceptual language", ACM TODS, Vol 10, No. 2, June 1985.
3. [Atkinson et al. 83] M. Atkinson, P.J. Bayley, K. Chilsom, W. Cockshott and R. Morrison, "An approach to persistent programming", Computer Journal, 26(4), 1983, pp 360-365.
4. [Atwood 85] T. Atwood, "An object-oriented DBMS for design support applications", Ontologic Inc. Report.
5. [Bancilhon 86] F. Bancilhon, "A logic programming object oriented cocktail", ACM SIGMOD Record, 15:3, pp. 11-21, 1986.
6. [Bancilhon and Maier 88] F. Bancilhon and D. Maier, "Multilanguage object-oriented systems: new answer to old database problems", in Future Generation Computer II, K. Fuchi and L. Kott editors, North-Holland, 1988.
7. [Bancilhon et al. 88] F. Bancilhon, G. Barbedette, V. Benzaken, C. Delobel, S. Gamerman, C. Lecluse, P. Pfeffer, P. Richard et F. Velez, "The design and implementation of O2, an object-oriented database system", Proceedings of the ooDBS II Workshop, Bad Munster, FRG, September 1988.
8. [Banerjee et al. 87] J. Banerjee, H.T. Chou, J. Garza, W. Kim, D. Woelk, N. Ballou and H.J. Kim, "Data model issues for object-oriented applications", ACM TOIS, January 1987.
9. [G-Base 88] "G-Base version 3, Introductory guide", Graphael, 1988.
10. [Bobrow and Steifik 81] D. Bobrow and M. Steifik, " The Loops Manual", Technical Report LB-VLSI-81-13, Knowledge Systems Area, Xerox Palo Alto Research Center, 1981.
11. [Carey et al. 86] M. Carey, D. DeWitt, J.E. RichardsonДжон Ричардсон (англ.John Richardson, 5 ноября 1787 — 5 июня 1865)— шотландский ботаник, ихтиолог, врач, хирург, натуралист (естествоиспытатель). and E.J. Shekita, "Object and file management in the EXODUS Extensible Database System", Proceedings of the 12th VLDB, pp 91-10, August 1986.
12. [Carey et al. 88] M. Carey, D. DeWitt and S. Vandenberg, "A Data Model and Query Language for EXODUS", Proceedings of the 1988 ACM SIGMOD Conference, Chicago, June 1988.
13. [Caruso and Sciore 87] "The VISION Object-Oriented Database Management System", Proceedings of the Workshop on Database Programming Languages, Roscoff, France, September 1987
14. [Caseau 89] "A model for a reflective object-oriented language", Sigplan Notices, Special issue on Concurrent Object-Oriented Programming, March 1989.
15. [Codd 70] E. F. Codd, "A relational model for large shared data banks", Communication of the ACM, Volume 13, Number 6, (June 1970), pp 377-387.
16. [Dittrich 1986] K.R. Dittrich, "Object-Oriented Database System : The Notions and the issues", in : Dittrich, K.R. and Dayal, U. (eds): Proceedings of the 1986 International Workshop on Object-Oriented Database Systems, IEEE Computer Science Press
17. [Dittrich 1988] K. R. Dittrich, "Preface", In : Dittrich, K.R. (ed): Advances in Object-Oriented Database Systems, Lecture Notes in Computer Science, Vol, 334, Springer-Verlag, 1988
18. [Eiffel 87] "Eiffel user"s manualManual (баланс, произносится «мэньюал»)— езда на двух парных колёсиках скейта или на заднем/переднем колесе велосипеда, не касаясь земли остальными колёсами. Часто исполняется в качестве связки нескольких трюков, например kickflip to manual shove it out на скейте или manual to tailwhip на велосипеде.", Interactive SoftwareПрограммное обеспечение (допустимо также произношение обеспечение), ПО— совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ (ГОСТ 19781-90). Engineering Inc., TR-EI-5/UM, 1987.
19. [Fishman et al. 87] D. Fishman et al, "Iris: an object-oriented database management system", ACM TOIS 5:1, pp 48-69, January 86.
20. [Hall et al. 76] P. Hall, J. Owlett, S. Todd, "Relations and Entities", in "Modeling in Data Base Management Systems", G.M. Nijssen (ed.), pp 201-220, North-Holland, 1976.
21. [Goldberg and Robson 83] A. Goldberg and D. Robson, "Smalltalk-80: the language and its implementation", Addison-Wesley, 1983.
22. [Kim 88] W. Kim, "A foundation for object-oriented databases", MCC Technical Report, 1988.
23. [Khoshafian and Copeland 86] S. Khoshafian and G. Copeland, "Object identity", Proceedings of the 1st ACM OOPSLA conference, Portland, Oregon, September 1986
24. [Lecluse and Richard 89] C. Lecluse and P. Richard, "The O2 Database Programming Languages", Proceedings of the 15th VLDB Conference, Amsterdam, August 1989.
25. [Maier and Price 84] D. Maier and D. Price, "Data model requirements for engineering applications", Proceedings of the First International Workshop on Expert Database Systems, IEEE, 1984, pp 759-765
26. [Maier 89] D. Maier, "Why isn"t there an object-oriented data model?" Proceedings IFIP 11th World Computer Conference, San Francisco, CA, August-September 1989.
27. [Maier, et al. 84] D. Maier, J. Stein, A. Otis, A. Purdy, "Development of an object-oriented DBMS" Report CS/E-86-005, Oregon Graduate Center, April 86
28. [Nixon, et al. 87] B. Nixon, L. Chung, D. Lauzon, A. Borgida, J. Mylopoulos and M. Stanley, "Design of a compiler for a semantic data model", Technical note CSRI-44, University of Toronto, May 1987.
29. [Simula 67] "Simula 67 Reference Manual"
30. [Schaffert, et al. 86] C. Schaffert, T. Cooper, B. Bullis, M. Kilian and C. Wilpolt, "An introduction to Trellis/Owl", Proceedings of the 1st OOPSLA Conference, Portland, Oregon, September 1986
31. [Skarra et al. 86] A. Skarra, S. Zdonik and S. Reiss, "An object server for an object oriented database system," Proceedings of the 1986 International Workshop on Object Oriented Database System, Computer Society Press, IEEE, pp. 196-204, 1986
32. [Stroustrup 86] B. Stroustrup, "The C++ programming language", Addison-Wesley, 1986.
33. [Van Emdem and Kowalski 76] M. Van Emdem and R. Kowalski, "The semantics of predicate logic as a programming language", JACM, Vol 23, No. 4, pp. 733-742, October1976.
34. [Zaniolo 86] C. Zaniolo, "Object-oriented programming in Prolog ", Proceedings of the first workshop on Expert Database Systems, 1985.