|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #04/95
|
|
М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С. Здоник
В этой статье предпринята попытка дать определение системам объектно-ориентированных баз данных. В ней дается описание основных свойств и характеристик, которыми должна обладать система, претендующая на то, чтобы быть квалифицированной как система объектно-ориентированных баз данных.
Мы разделили эти характеристики на три группы:
Мы не ожидаем, что данная статья станет последним словом, а рассматриваем ее скорее как отправную точку для дальнейшей дискуссии.
В настоящее время системам объектно-ориентированных баз данных (СООБД) уделяется много внимания как с теоретической, так и с практической точек зрения, и ведутся жаркие споры об определении таких систем.
Можно выделить три характерные черты современного состояния дел: (а) отсутствие общепринятой модели данных, (б) отсутствие формального базиса и (с) активная экспериментаторская деятельность.
В то время как классическая статья Кодда [Codd 70] предоставила отчетливую спецификацию систем реляционных баз данных (модель данных и язык запросов), для систем объектно-ориентированных баз данных подобная спецификация отсутствует [Maier 89]. Мы вовсе не хотим сказать, что не существует ни одной полной модели объектно-ориентированной базы данных. На самом деле, в литературе можно найти множество соответствующих приложений (см., например, [Albano et al. 1986], [Lecluse and Richard 89], [Carey et al. 88]), но отсутствует общее согласие по поводу какой-нибудь одной из предложенных моделей. Постепенно складывается общая точка зрения по поводу основных характеристик семейства объектно-ориентированных систем, однако в настоящее время отсутствует единое мнение о том, что из себя представляет объектно-ориентированная система, не говоря уже о системе объектно-ориентированных баз данных.
Второй чертой является отсутствие надежного теоретического базиса. В объектно-ориентированном программировании по сравнению с логическим программированием нет такой программной статьи, как [Van Emdem and Kowalski 76]. Необходимость в основополагающей теории очевидна: семантика таких понятий как типы или программы, зачастую часто является плохо определенной. Отсутствие надежного теоретического базиса делает практически невозможным достижение единого мнения о модели данных.
Наконец, ведутся многочисленные экспериментальные разработки: люди реально строят системы. Некоторые из этих систем являются только прототипами [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]. Как кажется, интерес к объектно-ориентированным базам данным вызван потребностями систем поддержки проектирования (например, CAD, CASE, офисные информационные системы). Для этих приложений требуются базы данных, которые могут справляться с очень сложными данными, которые способны развиваться, и которые обеспечивают высокую производительность, требуемую интерактивным системам.
Ситуация с реализациями аналогична ситуации с системами реляционных баз данных в середине семидесятых (хотя в случае объектно-ориентированных систем наработок больше). В случае реляционных систем хотя и были некоторые разногласия по некоторым конкретным вопросам, таким как форма языка запросов, или должны ли отношения быть множествами или мультимножествами, эти различия были в большинстве случаев несущественными, и существовала общепринятая основополагающая модель. Люди, главным образом, занимались разработкой технологии реализации. Сегодня мы одновременно решаем проблему спецификации системы и создаем технологию для поддержки ее реализации.
Таким образом, в отношении спецификации системы мы придерживаемся Дарвинистского подхода: мы надеемся, что из множества построенных экспериментальных прототипов сама собой появится подходящая модель. Мы также надеемся, что одновременно с ней появится жизнеспособная технология реализации этой модели.
К несчастью, при опоре на экспериментаторскую деятельность имеется риск принять в качестве образца некоторую систему не потому, что она является наиболее оптимальной, а поскольку она окажется первой, обеспечивают значительный набор функциональных возможностей, отвечающих требованиям рынка. Это, к несчастью, типично для компьютерной области: первый продукт становится де-факто стандартом и таковым остается. Такая ситуация существует, по крайней мере, для языков и операционных систем (Fortran, Lisp, Cobol и SQL представляют хорошие примеры). Заметим, однако, что нашей целью является не стандартизация языков, а уточнение терминологии.
Чрезвычайно важно прийти к согласию об определении систем объектно-ориентированных баз данных. В качестве первого шага к этой цели в данной статье предлагаются характеристики, которым должны отвечать такие системы. Мы надеемся, что статья будет рассматриваться как пробный шар и что другие специалисты либо докажут несостоятельность, либо подтвердят основные положения данной статьи. Отметим, что эта статья не является обзором положения дел в технологии объектно-ориентированных систем баз данных (ООСБД) и не претендует на оценку современного состояния технологии, а только предлагает набор определений.
Мы разделили характеристики систем объектно-ориентированных баз данных на три категории: обязательные (те, которым система должна удовлетворять для того, чтобы иметь право называться объектно-ориентированной), необязательные (те, которые могут быть добавлены для улучшения системы, но не являются обязательными) и открытые (те места, где проектировщик может выбрать решение из набора одинаково приемлемых решений). Кроме того, имеется некоторая возможность маневра в том, как лучше сформулировать каждую характеристику (это касается как обязательных, так и необязательных характеристик).
Статья организована следующим образом: в разделе 2 описываются обязательные свойства ООСБД. В разделе 3 - необязательные свойства, и в разделе 4 перечисляются степени свободы, которые предлагается оставить проектировщику системы.
Система объектно-ориентированных баз данных должна удовлетворять двум критериям: она должна быть СУБД и при этом являться объектно-ориентированной системой, т.е. в максимально возможной степени находиться на уровне современных объектно-ориентированных языков программирования. Первый критерий означает пять свойств: стабильность, управление вторичной памятью, параллелизм, восстанавливаемость и средства обеспечения незапланированных (ad hoc) запросов. Второй означает восемь свойств: сложные объекты, идентифицируемость объектов, инкапсуляцию, типы или классы, наследование, перекрытие методов совместно с поздним связыванием, расширяемость и вычислительную полноту.
Сложные объекты следует поддерживать. Сложные объекты строятся из более простых при помощи конструкторов. Простейшими объектами являются такие объекты, как целые числа, символы, символьные строки произвольной длины, булевские переменные и числа с плавающей точкой (можно было бы добавить другие атомарные типы). Имеются различные конструкторы сложных объектов: примерами могут служить конструкторы кортежей, множеств, мультимножеств, списков, массивов. Минимальный набор конструкторов, который должна иметь система, - это конструкторы множеств, списков и кортежей. Множества необходимы, потому что они обеспечивают естественный способ представления наборов объектов реального мира. Кортежи необходимы, потому что они представляют естественный способ представления свойств сущностей. Конечно, важны и множества, и кортежи, поскольку они получили широкое распространение в качестве конструкторов объектов благодаря реляционной модели. Списки или массивы важны потому, что они сохраняют порядок, который имеет место в реальном мире, а также потому, что они присутствуют во многих научных приложениях в виде матриц или временных рядов.
Конструкторы объектов должны быть ортогональными: любой конструктор должен быть применим к любому объекту. Конструкторы реляционной модели не являются ортогональными, потому что конструкция множества может быть применена только к кортежам, а конструкция кортежа - только к атомарным значениям. Другими примерами являются реляционные модели с не первой нормальной формой (non-first normal form), в которых конструкцией верхнего уровня всегда должно быть отношение.
Отметим, что для поддержки сложных объектов необходимы соответствующие операторы для работы с такими объектами (как бы они не были устроены). То есть операции со сложным объектом должны транзитивно распространяться на все его компоненты. Примерами могут быть выборка или удаление сложного объекта целиком или создание "глубокой" копии (в отличии от "поверхностной" копии, в которой компоненты не копируются: в копии корня объекта указываются ссылки на компоненты копируемого объекта). Конечно, пользователь должен иметь возможность определять дополнительные операции со сложными объектами (см. ниже правило расширяемости). Однако для реализации этой возможности необходимы некоторые обеспечиваемые системой средства, такие как два различаемых типа ссылок ("является частью" и "общая").
Идентифицируемость объектов следует поддерживать. Идентифицируемость объектов давно поддерживается в языках программирования. Для баз данных эта концепция сравнительно нова, см., например, [Hall и др. 76], [Maier и Price 84], [Khoshafian и Copeland 86]. Идея состоит в следующем: в модели с идентифицируемостью объектов объект существует независимо от его значения. Таким образом, имеется два понятия эквивалентности объектов: два объекта могут быть идентичны (они представляют собой один и тот же объект) или они могут быть равны (они имеют одно и тоже значение). Это влечет две следствия: первое - разделяемые объекты, а второе - изменения объектов.
Разделяемые объекты: в модели с идентифицируемыми объектами два объекта могут иметь совместно используемый компонент. Таким образом, схематическим представлением сложного объекта является граф, в то время как в системе без идентифицируемости объектов это дерево. Рассмотрим следующий пример: Человек имеет имя, возраст и некоторое количество детей. Предположим, что Питер и Сьюзан имеют 15-летнего сына по имени Джон. В реальной жизни могут иметь место две ситуации: Сьюзан и Питер являются родителями одного и того же ребенка или каждый из них имеет по сыну. В системе без идентифицируемости Питер представляется как:
(peter, 40, -(john, 15, -")"),
а Сьюзен как:
(susan, 41, -(john, 15, -")").
Таким образом, нет никакой возможности выразить, являются ли Питер и Сьюзан родителями одного и того же ребенка или разных детей. В модели с идентифицируемостью объектов эти две структуры либо имеют общую часть (john, 15, { }), либо не имеют ее, так что поддерживаются обе ситуации.
Изменения объектов: предположим, что Питер и Сьюзан действительно являются родителями мальчика по имени Джон. В этом случае все исправления, касающиеся сына Сьюзан, будут производиться с объектом Джон, а следовательно, и с сыном Питера. Идентифицируемость объектов, кроме того, обеспечивает мощный примитив манипулирования данными, который может служить основой для манипулирования множествами, кортежами или рекурсивными сложными объектами [Abiteboul and Kanellakis 89].
Поддержка идентифицируемости объектов обеспечивает возможность реализации таких операций, как присваивание объекта, копирование объекта (как глубокое, так и поверхностное) и проверка идентичности объектов и их равенства (как глубокого, так и поверхностного равенства).
Конечно, можно моделировать идентифицируемость объектов в системе, основанной на идентификации посредством значений, путем введения явных идентификаторов объектов. Однако такой подход перекладывает на пользователя бремя обеспечения уникальности идентификаторов объектов и поддержки ссылочной целостности (и это бремя может быть весьма значительным для таких операций, как "сборка мусора" (garbage collection)).
Заметим, что модели с идентифицируемостью объектов являются нормой в императивных языках программирования: каждый объект, с которым имеет дело программа, идентифицируем и может быть изменен. Идентифицируемость объекта возможна за счет наличия имени переменной или соответствующего физическому адреса памяти. Однако эта концепция совершенно нова для чисто реляционных систем, где идентифицируемость кортежей отношения основывается на значениях.
Объекты следует инкапсулировать. Идея инкапсуляции происходит (а) из потребности отчетливо различать спецификации и реализации операций и (б) из потребности в модульности. Модульность необходима для структурирования сложных приложений, разрабатываемых и реализуемых группой программистов. Она также необходима как средство защиты и авторизации.
Имеются две точки зрения на проблему инкапсуляции: точка зрения с позиций языка программирования (которая является исходной точкой зрения, так как эта концепция ведет свое начало отсюда) и адаптация этой точки зрения применительно к базам данных.
Идея инкапсуляции в языках программирования происходит от абстрактных типов данных. С этой точки зрения объект делится на интерфейсную часть и реализационную часть. Интерфейсная часть является спецификацией набора допустимых над объектом операций. Только эта часть объекта видима. Реализационная часть состоит из части данных и процедурной части.
Часть данных - это представление или состояние объекта, а в процедурной части на некотором языке программирования описываются реализации каждой операции.
Интерпретация этого принципа для баз данных состоит в том, что объект инкапсулирует и программу, и данные. В мире баз данных не вполне ясно, является или нет структурная часть типа частью интерфейса (это зависит от системы), в то время как в мире языков программирования структура данных явно является частью реализации, а не интерфейса.
Рассмотрим, например, объект Служащий. В реляционной системе служащий представляется кортежем. Запрос к нему осуществляется с помощью реляционного языка, а прикладной программист пишет программы для изменения этой записи, например повышение зарплаты служащего или прием на работу. Такие программы обычно пишутся либо на императивном языке программирования с включением в него операторов языка манипулирования данными или на языке четвертого поколения и хранятся в обычной файловой системе, а не в базе данных. Таким образом, при таком подходе имеются кардинальные различия между программой и данными, а также между языком запросов (для незапланированных запросов) и языком программирования (для прикладных программ).
В объектно-ориентированной системе служащий определяется как объект, который состоит из части данных (очень даже вероятно, что эта часть практически совпадает с записью, определенной для реляционной системы) и части операций (эта часть состоит из операций повышения зарплаты и приема на работу и других операций для доступа к данным сотрудника). При хранении набора сотрудников как данные, так и операции хранятся в базе данных.
Таким образом, имеется единая модель для данных и операций, и информация может быть скрыта. Никакие иные операции, помимо указанных в интерфейсе, не выполняются. Это ограничение справедливо как для операций изменения, так и для операций выборки.
Инкапсуляция обеспечивает что-то вроде "логической независимости данных": мы можем изменить реализацию типа, не меняя каких-либо программ, использующих этот тип. Таким образом, прикладные программы защищены от реализационных изменений на нижних слоях системы.
По-нашему мнению, правильной инкапсуляцией является такая, когда видны только операции, а данные и реализация операций скрыты в объектах.
Однако имеются случаи, когда инкапсуляция не нужна, и использование системы может быть значительно упрощено, если система допускает нарушение инкапсуляции при некоторых условиях. Например, при незапланированных запросах инкапсуляция является не столь необходимой, так как такие вопросы, как сопровождаемость, в этом случае не являются важными. Таким образом, ООСБД должна обеспечивать механизм инкапсуляции, но имеются случаи, когда его принудительное использование неуместно.
Следует поддерживать типы или классы. Это весьма болезненный вопрос: имеются две основные категории объектно-ориентированных систем - те, которые поддерживают классы, и те, которые поддерживают типы. К первой категории относятся такие системы, как 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. Представителями второй категории являются такие системы как, C++ [Stroustrup 86], Simula [Simula 67], Trellis/Owl [Schaffert, и др. 86], Vbase [Atwood 85] и O2 [Bancilhon et al. 88].
В объектно-ориентированной системе тип обобщает общие черты множества объектов с одинаковыми характеристиками. Он соответствует понятию абстрактного типа данных. Он делится на две части: интерфейс и реализация (реализации). Пользователям типа видна только интерфейсная часть, а реализация объекта видна только проектировщику типа. Интерфейс состоит из списка операций вместе с их сигнатурами (т. е. типом вводимых параметров и типом результата).
Реализация типа состоит из части данных и части операций. Часть данных описывает внутреннюю структуру данных объекта. В зависимости от мощности системы часть данных может быть более или менее сложной. Часть операций состоит из процедур, которые реализуют операции интерфейсной части.
В языках программирования типы являются средствами увеличения продуктивности программиста за счет обеспечения правильности программ. Принуждая пользователя объявлять типы переменных и выражений, которые он или она используют для манипулирования, система судит о правильности программ на основе этой информации о типах. Если система типов тщательно разработана, то система может произвести проверку типов во время компиляции, иначе некоторые проверки могут быть отложены до времени выполнения. Таким образом, типы главным образом используются во время компиляции для проверки правильности программ. Вообще говоря, в основанных на типах системах тип не является "гражданином первого сорта", а имеет специальный статус и не может быть изменен во время выполнения.
Понятие класса отличается от понятия типа. Его спецификация совпадает со спецификацией типа, но является более динамическим понятием. Класс характеризуется двумя аспектами: фабрика объектов и склад объектов. Фабрика объектов может быть использована для создания новых объектов посредством выполнения операции new данного класса операции или клонирования некоторого объекта-прототипа, являющегося представителем данного класса. Склад объектов означает, что к классу присоединяется его расширение, т.е. набор объектов, которые являются экземплярами класса. Пользователь может манипулировать складом, применяя операции ко всем экземплярам класса. Классы используются не для проверки правильности программы, а скорее для создания и манипулирования объектами. В большинстве систем, которые используют механизм классов, классы являются "гражданами первого сорта" и, как таковыми, ими можно манипулировать во время выполнения, т. е. изменять их и передавать как параметры. В большинстве случаев это делает невозможным проверку типов во время компиляции, но придает системе большую гибкость и однородность.
Конечно, между классами и типами имеется значительное сходство, оба термина использовались в каждом из значений, а в некоторых системах отличие между ними и вовсе едва заметно.
Мы не чувствуем себя вправе отдать предпочтение одному из двух подходов и оставляем право выбора за проектировщиком системы (см. раздел 4.3). Однако мы требуем, чтобы система предоставляла некоторый механизм структурирования данных, будь это классы или типы. Таким образом, классическое понятие схемы базы данных будет заменено на понятие множества классов или множества типов.
Однако мы не видим необходимости в том, чтобы система автоматически поддерживала экстент типа (т. е. набор объектов данного типа в базе данных) или, если экстент типа поддерживается, чтобы система предоставляла пользователю доступ к нему. Рассмотрим, например, тип "прямоугольник", который может использоваться в различных базах данных многими пользователями. Не имеет смысла говорить о множестве всех прямоугольников, поддерживаемых системой, или производить операции над ними. Мы думаем, что более оправдано отдать на откуп пользователю поддержку его множества прямоугольников и манипулирование ими. С другой стороны, в случае такого типа как "служащий" весьма удобно, чтобы система автоматически сопровождала экстент этого типа.
Для классов или типов следует поддерживать наследование. Наследование обладает двумя положительными достоинствами. Во-первых, оно является мощным средством моделирования, поскольку обеспечивает возможность краткого и точного описания мира. Во-вторых, эта возможность помогает факторизовать совместно используемые в приложениях спецификации и реализации.
Следующий пример иллюстрирует необходимость наличия наследования в системе. Допустим, что мы имеем дело со служащими и студентами. Каждый служащий имеет имя, возраст более 18 лет и оклад, он или она может умереть, выйти замуж или жениться или получить зарплату (как скучна жизнь служащего!). Каждый студент имеет имя, возраст и множество оценок. Он или она может умереть, выйти замуж или жениться и для него или нее может быть вычислен GPA.
В реляционной системе проектировщик базы данных определяет отношение для служащего, отношение для студента, пишет программы для реализации операций "умереть", "жениться" и "получить зарплату" над отношением "сотрудник" и программы для реализации операций "умереть", "жениться", и "вычислить GPA" над отношением "студент". Таким образом, прикладной программист должен написать шесть программ.
В объектно-ориентированной системе, используя свойство наследования, мы распознаем, что сотрудники и студенты являются людьми; таким образом, они имеют кое-что общее (то, что каждый из них является человеком) и некоторые различия.
Мы вводим тип "человек", атрибутами которого являются имя и возраст и пишем программы для реализации операций "умереть" и "жениться" для этого типа. Затем мы объявляем, что служащие являются особым типом людей, которые наследуют атрибуты и операции типа "человек" и обладают своими собственными атрибутом "оклад" и операцией "получить зарплату". Аналогично, мы объявляем, что студент является особой разновидностью человека со своими собственными атрибутом "набор оценок" и операцией "вычислить GPA". В этом случае мы имеем более структурированное и краткое описание схемы (мы факторизовали спецификацию), и нам потребовалось написать всего четыре программы (мы факторизовали реализацию). Наследование способствует повторному использованию кода, потому что каждая программа находится на том уровне, на котором ее может совместно использовать наибольшее число объектов.
Имеется по крайней мере четыре типа наследования: наследование через подстановку, наследование путем включения, наследование через ограничение и наследование через специализацию.
Говоря про наследование через подстановку, мы имеем в виду, что тип t наследует от типа t`, если мы можем выполнить больше операций над объектами типа t, чем над объектом типа t`. Таким образом, вместо объекта t` мы всегда можем подставить объект типа t. Этот тип наследования базируется на поведении, а не на значениях.
Наследование путем включения соответствует понятию классификации. В этом случае утверждается, что тип t является подтипом t`, если каждый объект типа t является также объектом типа t`. Этот тип наследования базируется на структуре, а не на операциях. Примером является тип "квадрат" с методами "получить", "установить"(размер) и "раскрашенный квадрат" с методами "получить", "установить"(размер) и "раскрасить"(цвет).
Наследование через ограничение является частным случаем наследования путем включения. Тип t является подтипом типа t`, если к нему относятся все объекты типа t`, которые удовлетворяют данному ограничению. Примером такого наследования является класс "подросток" как подкласс класса "человек": объекты класса "подросток" не имеют дополнительных полей или операций по сравнению с объектами класса "человек", но они удовлетворяют более специфичным ограничениям (возраст подростков ограничен снизу 13, а сверху 19 годами).
При наследовании через специализацию тип t является подтипом t`, если объекты типа t являются объектами типа t`, но при этом содержат более специфичную информацию. Примером являются типы "люди" и "служащие", где информация о служащих является той же самой, что и информация о людях, но включает некоторые дополнительные поля.
Существующие системы и прототипы в той или иной мере поддерживают эти четыре типа наследования. Мы, в свою очередь, не хотим навязывать какой-либо конкретный стиль наследования.
Не следует производить преждевременное связывание. По контрасту с предыдущим примером, имеются случаи, когда желательно иметь одно и то же имя для различных операций. Рассмотрим, например, операцию отображения: она принимает на входе объект и отображает его на экране. В зависимости от типа объекта используются разные механизмы отображения. Если объект является изображением, то мы хотим, чтобы оно действительно появилось на экране. Если объект является человеком, то мы хотим, чтобы в том или ином виде был напечатан описывающий человека кортеж. Наконец, если объект является графом, то мы хотели бы иметь его графическое представление. Рассмотрим теперь задачу отображения множества, тип членов которого не известен во время компиляции.
В приложениях, использующих традиционные системы, мы имели бы три операции: "отобразить объект типа "человек"", "отобразить растровое изображение" и "отобразить граф". Программист проверил бы тип каждого объекта, входящего во множество, и использовал бы соответствующую операцию отображения. Это обязывает программиста знать все возможные типы объектов, которые могут входить в заданное множество, а также соответствующие им операции отображения, и использовать их согласованным образом.
for- x in X do begin
cas-e of type(x)
person: display(x);
bitmap: display-bitmap(x); graph: display-graph(x);
end
end
В объектно-ориентированной системе мы определяем операцию отображения на уровне типа "объект" (наиболее общий тип в системе). Таким образом, операция отображения имеет единственное имя и может быть одинаковым образом применена к графам, людям и изображениям. Однако, мы переопределяем реализацию операции для каждого типа в соответствии с его особенностями (такое переопределение называется перекрытием). В результате три разные программы имеют одно имя "отобразить" (это называется перегрузкой). Для отображения множества элементов мы просто применяем операцию отображения к каждому элементу, оставляя за системой выбор соответствующей реализации во время выполнения.
for x in X do display(x)
Здесь мы получаем иную выгоду: реализатор типов по-прежнему должен писать то же количество программ. Но прикладному программисту уже не нужно заботиться о трех различных программах. Кроме того, код проще, так как оператор case над типами отсутствует. Наконец, код становится более сопровождаемым, поскольку и при введении нового типа, и при добавлении нового экземпляра существующего типа программа отображения будет работать без изменения (при условии, что для этого нового типа мы обеспечим перекрытие метода отображения).
Чтобы обеспечить эти новые функциональные возможности, система не может связывать имена операций с программами во время компиляции. Поэтому имена операций должны разрешаться (транслироваться в адреса программ) во время выполнения. Эта отложенная трансляция и называется поздним связыванием.
Отметим, что хотя позднее связывание затрудняет проверку типов (а в некоторых случаях делает ее невозможной), оно не отменяет ее полностью.
Вычислительную полноту следует поддерживать. С точки зрения языка программирования это свойство является очевидным: оно просто означает, что любую вычислимую функцию можно выразить с помощью языка манипулирования данными системы баз данных. С точки зрения базы данных это является новшеством, так как SQL, например, не является полным языком.
Мы не призываем проектировщиков объектно-ориентированных систем баз данных к созданию новых языков программирования: вычислительной полноты можно, разумным образом опираясь на существующие языки программирования. И на самом деле, в большинстве систем используются уже существующие языки программирования [Banerjee et al. 87], [Fishman et al. 87], [Atwood 85], [Bancilhon et al. 88]; обсуждение этой проблемы см. в [Bancilhon and Maier 88].
Заметим, что вычислительная полнота - это не то же самое, что "ресурсная полнота", т.е. возможность доступа ко всем ресурсам системы (например, к экрану и удаленным ресурсам) с использованием внутренних средств языка. Поэтому система, даже будучи вычислительно полной, может быть не способна выразить полное приложение. Тем не менее, такая система является более мощной, чем система баз данных, которая только хранит и извлекает данные и выполняет простые вычисления с атомарными значениями.
Расширяемость следует поддерживать. Система базы данных поставляется с набором предопределенных типов. Эти типы могут при желании использоваться программистами для написания приложений. Набор предопределенных типов должен быть расширяемым в следующем смысле: должны иметься средства для определения новых типов и не должно быть различий в использовании системных и определенных пользователем типов. Конечно, способы поддержания системой системных и пользовательских типов могут значительно различаться, но эти различия должны быть невидимыми для приложения и прикладного программиста. Напомним, что определение типов включает определение операций этих типов. Заметим, что требование инкапсуляции подразумевает наличие механизма для определения новых типов. Требование расширяемости усиливает эту возможность, указывая, что вновь созданные типы должны иметь тот же статус, что и существующие.
Однако мы не требуем, чтобы совокупность конструкторов типов (кортежей, множеств, списков и т. д.) была расширяемой.
Данные следует помнить. Это требование очевидно с точки зрения баз данных, но является новым с точки зрения языков программирования [Atkinson et al. 83]. Стабильность (persistence) означает возможность программиста обеспечить сохранность данных после завершения выполнения процесса с целью последующего использования в другом процессе. Свойство стабильности должно быть ортогональным, т.е. для каждого объекта вне зависимости от его типа должна иметься возможность сделать его стабильным (т.е. без какой-либо явной переделки объекта). Стабильность должна быть неявной: пользователь не должен явно перемещать или копировать данные, чтобы сделать их стабильными.
Следует уметь управлять большими базами данных. Управление вторичной памятью является классической чертой систем управления базами данных. Эта возможность обычно поддерживается с помощью набора механизмов. Среди них управление индексами, кластеризация данных, буферизация данных, выбор пути доступа и оптимизация запросов.
Ни один из механизмов не является видимым для пользователя - это просто средства повышения производительности системы. Однако эти средства настолько важны с точки зрения эффективности, что при их отсутствии система не сможет выполнять некоторые задачи (просто потому, что их выполнение будет занимать слишком много времени). Подчеркнем еще раз важность невидимости таких средств. Прикладной программист не должен писать программы для сопровождения индексов, распределять память на диске или перемещать данные между диском и основной памятью. Таким образом, должна обеспечиваться четкая независимость между логическим и физическим уровнями системы.
Следует поддерживать параллельную работу нескольких пользователей. Что касается управления параллельным взаимодействием с системой нескольких пользователей, то должны обеспечиваться услуги того же уровня, который предоставляют современные системы баз данных. Поэтому система должна обеспечивать гармоническое сосуществование пользователей, одновременно работающих с базой данных. Следовательно, система должна поддерживать стандартное понятие атомарности последовательности операций и управляемого совместного доступа. Должна, по крайней мере, обеспечиваться сериализуемость (serializability) операций, хотя могут и менее жесткие альтернативы.
Следует обеспечивать восстановление после аппаратных и программных сбоев. И в этом случае систем, должна обеспечивать услуги того же уровня, который предоставляют современные системы баз данных. Следовательно, в случае аппаратных или программных сбоев система должна восстанавливаться, т. е. возвращаться к некоторому согласованному состоянию данных. Аппаратные сбои включают как сбои в работе процессора, так и сбои дисков.
Следует обеспечивать простой способ запросов данных. Здесь основной проблемой является обеспечение функциональности языка незапланированных (ad hoc) запросов. Мы не призываем к тому, чтобы это обязательно было реализовано в виде языка запросов, а только к тому, чтобы была такая услуга существовала. Например, графическая программа просмотра вполне достаточна для обеспечения этой функциональной возможности. Услуга состоит в том, что пользователь может без затруднений сделать простой запрос к базе данных. Очевидной мерой являются, конечно, реляционные системы. Поэтому проверка наличия средства незапланированных запросов состоит в том, чтобы взять на пробу несколько реляционных запросов и проверить, можно ли их сформулировать с теми же затратами труда. Заметим, что это средство могло бы поддерживаться языком манипулирования данными или его подмножеством.
Мы полагаем, что средство обеспечения запросов должно удовлетворять следующим трем критериям:
(а) -Оно должно быть средством высокого уровня, т. е., пользователь должен иметь возможность кратко выразить нетривиальные запросы (в нескольких словах или несколькими нажатиями клавиш мыши). Это означает, что средство формулирования должно быть достаточно декларативным, т. е., упор должен быть сделан на "что", а не на "как".
(б) -Оно должно быть эффективным. Т.е., формулировка запросов должна допускать возможность оптимизации запросов.
(в) -Средство запросов не должно зависеть от приложения, т. е., оно должно работать с любой возможной базой данных. Это последнее требование устраняет потребность в специфических средствах обеспечения запросов для конкретных приложений и необходимость написания дополнительных операций для каждого определенного пользователем типа.
Этим исчерпывается список обязательных характеристик. Надеемся, что нам удалось прояснить различия между системами традиционными и объектно-ориентированными системами баз данных. Реляционные системы баз данных не удовлетворяют правилам с первого по восьмое. Системы баз данных CODASYL частично удовлетворяет правилам 1 и 2. Некоторые люди придерживаются того мнения, что объектно-ориентированные системы баз данных есть ни что иное, как системы CODASYL. Следует отметить, что (а) системы CODASYL не удовлетворяют полностью этим двум правилам (конструкторы объектов не являются ортогональными, и не обеспечивается однородная идентифицируемость объектов, поскольку допускаются только связи 1:n), и (б) эти системы не удовлетворяют правилам 3, 5, 6, 8 и 13.
Приведем те свойства, по поводу которых авторы не достигли согласия, должны ли они быть обязательными или нет. Эти свойства включают следующее:
Под этим заголовком собраны возможности, которые улучшают систему, но не являются обязательными для того, чтобы система была объектно-ориентированной системой баз данных.
Некоторые из этих возможностей являются объектно-ориентированными по свой природе (например, множественное наследование). Они отнесены к категории необязательных возможностей потому, что хотя и делают систему более объектно-ориентированной, не входят в набор ключевых требований.
Другие возможности являются просто возможностями систем баз данных (например, управление проектными транзакциями). Эти характеристики обычно улучшают функциональные возможности систем баз данных, но не относятся к ключевым требованиям, предъявляемым к таким системам, и они не связаны с аспектом объектной-ориентированности. В действительности, многие из этих возможностей предназначены для обслуживания "новых" приложений (CAD/CAM, CASE, офисная автоматизация и т. д.) и являются более ориентированными на приложения, чем на технологии. Так как многие системы объектно-ориентированных баз данных нацелены на эти новые приложения, то существует некоторая путаница между этими возможностями и объектно-ориентированной природой системы.
Обеспечение или не обеспечение системой множественного наследования не является обязательным. Поскольку сообщество специалистов в области объектно-ориентированного подхода еще не достигло согласия относительно множественного наследования, мы рассматриваем обеспечение такого наследования как необязательное. Отметим, что в случае принятия решения о поддержке множественного наследования предстоит выбор из множества возможных решений проблемы разрешения конфликтов.
Вопрос о том, в какой степени система должна производить проверку типов во время компиляции, остается открытым, однако чем больше проверок во время компиляции, тем лучше. Оптимальной ситуацией является такая, когда успешно откомпилированная программа не может породить во время выполнения ошибки, связанные с несоответствием типов. Вопрос об объеме вывода типов также остается открытым на усмотрение системного проектировщика: чем больше, тем лучше; идеальной ситуацией является такая, в которой необходимо объявить только базовые типы, а система выводит временные типы.
Ясно, что эта характеристика является ортогональной к объектно-ориентированной природе системы. Таким образом, система баз данных может быть как распределенной, так и нет.
Для большинства новых приложений модель транзакций бизнес-ориентированной системы баз данных является неудовлетворительной: транзакции могут длиться слишком долго, и обычный критерий сериализуемости не является адекватным. Поэтому многие ООСБД поддерживают проектные транзакции (протяженные транзакции или вложенные транзакции).
Большинство новых приложений (CAD/CAM и CASE) включают проектную деятельность и требуют поддержки версий в том или ином виде. Поэтому многие ООСБД поддерживают версии. И в этом случае обеспечение механизма поддержки версий не является ключевым требованием к системе.
Любая система, удовлетворяющая правилам с первого по тринадцатое, заслуживает названия ООСБД. При проектировании такой системы все равно еще остаются возможности выбора. Это степени свободы людей, реализующих ООСБД. Эти характеристики отличаются от обязательных в том смысле, что относительно них научное сообщество еще не достигло согласия. Они отличаются от необязательных возможностей тем, что мы не знаем, какая из альтернатив является более, а какая менее объектно-ориентированной.
Мы не видим причины, по которой одной парадигме программирования следует отдать предпочтение перед другой: в качестве парадигмы программирования можно выбрать стиль логического программирования [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)".
Система представления определяется набором атомарных типов и набором конструкторов. Хотя мы и указали минимальный набор атомарных типов и конструкторов (элементарные типы языков программирования и конструкторы множеств, кортежей и списков), который должен быть доступен для описания представления объектов, этот набор может быть расширен множеством разнообразных способов.
Также остается свобода в выборе формирователей типов. Единственным средством формирования типов, наличия которого мы требуем, является инкапсуляция. Возможны другие формирователи типов, такие как родовые типы или генераторы типов (например, set[T], где T может быть произвольным типом), ограничение, объединение или стрелка (функции).
Система типов может быть первого или второго порядка. Наконец, система типов для переменных может быть богаче системы типов для объектов.
Ведутся жаркие споры о степени однородности таких систем. Является ли тип объектом? Является ли метод объектом? Следует ли эти три понятия рассматривать отдельно? Эту проблему можно рассматривать на трех разных уровнях: уровне реализации, уровне языка программирования и уровне интерфейса.
На уровне реализации необходимо решить, будет ли информация о типе храниться как объект или будет реализована некоторая специализированная система. Это тот же самый вопрос, с которым сталкиваются проектировщики систем реляционных баз данных при принятии решения о том, как следует хранить схему: в виде таблицы или некоторым специальным образом. Решение следует принимать с учетом эффективности и простоты реализации. Какое бы ни было принято решение, оно не зависит от решения, принимаемого на более высоком уровне.
На уровне языка программирования вопрос состоит в том, являются ли типы сущностями первого сорта в семантике языка. Споры ведутся главным образом вокруг этого вопроса. По-видимому, имеются различные стили однородности (синтаксический и семантический). Полная однородность на этом уровне также не согласуется со статической проверкой типов.
Наконец, на уровне интерфейса требуется принять еще одно независимое решение. Типы, объекты и методы могут быть представлены для пользователя как однородные, если даже в семантике языка программирования они предстают как различные по своей природе понятия. Обратно, они могут быть представлены для пользователя как различные сущности, хотя язык программирования не делает между ними различия. Это решение следует принимать с учетом человеческого фактора.
Некоторые авторы [Kim 88] и [Dittrich 1986] придерживаются той точки зрения, что ООСБД есть СУБД, основанная на объектно-ориентированной модели данных. Если использовать понятие модели данных в широком смысле, учитывая, в частности, дополнительные аспекты, выходящие за рамки ориентированности на работу с записями, то эта точка зрения, несомненно, согласуется с нашей. В [Dittrich 1986] и [Dittrich 1988] вводится классификация объектно-ориентированных моделей данных (и следовательно, ООСБД): модель называется структурно объектно-ориентированной, если она поддерживает сложные объекты; модель называется поведенчески объектно-ориентированной, если она обеспечивает расширяемость; для того чтобы модель была полностью объектно-ориентированной, она должна обладать обоими свойствами. В соответствии с определением требуется также поддержка свойства стабильности, управления дисками, параллелизма и восстанавливаемости; определение, по крайней мере, неявно, подразумевает наличие большинства других свойств (в тех случаях, где они применимы в зависимости от класса системы); в целом, это определение является более либеральным, чем наше. Однако, поскольку большинство систем и прототипов все равно не удовлетворяют всем требованиям, которые налагает наше определение, эта классификация предоставляет основу для сравнения выполненных и продолжающихся работ.
Мы предложили набор определяющих характеристик объектно-ориентированной системы баз данных. Насколько нам известно, золотые правила, данные в этой статье, являются в настоящее время наиболее детальным определением объектно-ориентированной системы базы данных. Выбор характеристик и наша интерпретация опирается на опыт в спецификации и реализации систем нынешнего поколения. Накопление опыта в проектировании, реализации и формализации объектно-ориентированных баз данных без сомнения приведет к изменению наших взглядов и более глубокому пониманию проблемы (другими словами, не удивляйтесь, если услышите в будущем, что одни из авторов ниспровергают приведенное здесь определение). Нашей целью было предоставление научному сообществу конкретного предложения для обсуждения, критики и анализа. Поэтому наше последнее правило можно сформулировать следующим образом:
Ставьте под сомнения "золотые" правила.
В заключении мы хотели бы выразить признательность Philippe Bridon, Gilbert Harrus, Paris Kanellakis, Philippe Richard и Fernando Velez за предложения и замечания, высказанные ими по поводу статьи. Работа Дэвида Майера частично финансировалась NSF через грант IST 83-51730 при поддержке Tektronix Foundation, Intel, Digital Equipment, Servio Logic, Mentor Graphics и Xerox.
|
|