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

Характеристики ООСУБД подразделяются на триопределяющие группы:

- базовые, определяющие принадлежность СУБД кобъектно-ориентированному классу;

- по выбору, позволяющие улучшать ООСУБД, но не являющиесябазовыми,

- открытости, позволяющие пользователю делать осознанный выбор из ряда одинаково приемлемых реализации ООСУБД.

В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД в ее классическом понимании и быть объектно-ориентированной системой (ООС), т.е. в определенной степени она должна быть совместимой с современными объектно-ориентированными ЯВУ.Первый критерий включает следующие пять характеристик, присущих классической СУБД: сохранность и реентерабельность данных, развитое управление внешней памятью, возможность совмещения обработки и поиска данных, поддержка средств восстановления и возможность быстрого доступа к БД по запросу пользователя. Отмеченные характеристики в той или иной мере обсуждались выше.Второй критерий предполагает наличие следующихвосьми характеристик, присущих собственно объектно-ориентированной технологии: понятие сложных объектов, идентичность объектов, инкапсуляция, типы или классы, наследование, настройка (сочетающаяся с отложенным присвоением), расширяемость и вычислительная полнота. Характеристики первого критерия хорошо известны пользователям традиционных СУБД (INGRES, dBase, R:Base, IMS, Reflex и др.), поэтому кратко остановимся на характеристикахвторого критерия, соотнося их с уже рассмотренными вопросами ООП-технологии.

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

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

2. Понятиеидентичности объектов давно существует в языках программирования и относительно недавно вСУБД. Суть данного понятия состоит в том, что существование объектане зависит от его значения. В этом плане существует два понятияэквивалентности объектов:

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

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

3. Понятиеинкапсуляции связано с необходимостью как прояснить различие между спецификацией и реализацией операции, так и с применением модульного принципа организации ПС. Наинкапсуляцию существует две точки зрения: (1) со стороны ЯВУ (именно здесь зародилось это понятие) и (2) адаптированная со стороны СУБД точка зрения. Впервом случае понятие инкапсуляции восходит к абстрактным типам данных, когдаобъект имеет интерфейсную и обрабатывающую части. Интерфейсная часть специфицирует множество операций, которые могут быть выполнены над объектом. Тогда как обрабатывающая часть, в свою очередь, состоит из данных и процедур: данные определяют состояние или представление объекта, а процедуры на некотором ЯВУ (например Turbo-Pascal, C++, SmallTalk и др.) описывают применение к объекту каждой допустимой для него операции.

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

4. В ООС существуют две основные категории, поддерживающие соответственно понятиекласса и типа. К первой категории можно отнести SmallTalk - подобные системы (SmallTalk, Vision, GemStone и др.) и все созданные на основе Zi"sp-языка системы (Flavors, G-Base, Orion, Lore и др.). Тогда как ко второй категории можно отнести такие системы, как: C++, Trellis, VBase, Simula и др. Понятиетипа в ООС суммирует общие черты множества объектов с одинаковыми характеристиками. Оно соответствует понятию типа абстрактных данных. Тип состоит из двух частей: интерфейсной и обрабатывающей. Для пользователя видна толькоинтерфейсная часть, содержащая список допустимых для данного типа операций с их сигнатурой (типы входных параметров и результата). Тогда какобрабатывающая часть скрыта от пользователя и состоит, в свою очередь, также из двух частей: данных и процедур. Частьданных описывает собственно внутреннюю структуру данных объекта и в зависимости от возможностей ООС данная часть может быть более или менее сложной.Процедуры поддерживают выполнение операций из интерфейсной части объекта.

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

Понятиекласса отличается от понятиятипа большей динамичностью и включает следующие два аспекта: генерация объекта и принадлежность объектов.Генерация используется для создания новых объектов класса посредством операции New или соответствующей модификацией некоторого представителя данного класса. В свою очередь, принадлежность определяет вхождение того или иного объекта в данный класс. Классы не используются для проверки корректности программ, а предназначены для организации работы с объектами. В большинстве систем, базирующихся на этом подходе, классы играют первостепенную роль и могут динамически обрабатываться, обновляясь или передаваясь в качестве параметров. Естественно, устанавливаются строгие соотношения между классами и типами (так, для обоих понятий используются в качестве идентификаторов имена) и в некоторых ООС различия между ними могут быть едва уловимыми. В любом случае, ООСУБД должна включать некоторый механизм структурирования данных, базирующийся наклассах илитипах. Следовательно, классическое понятие структуры БД заменяетсяпонятием, базирующимся на множествеклассов или множестветипов.

5. Наследование является весьма существенной характеристикой ООСУБД, имеющей два основных преимущества: (1) предоставляет мощные средства моделирования (на основе компактного и точного описания среды) и (2) помогает в выработке разделяемых спецификаций и реализации в приложениях. Наследование существенно облегчает также создание многократно используемых программ. На сегодня существует, по крайней мере, четыретипа наследования: подстановка, включение, ограничение и специализация. Наследованиеподстановки означает, что тип А наследуется из типа В, если можно производить больше операций над объектом А -типа, чем В поведенческие, а не семантические аспекты объектов. Наследованиевключения соответствует понятию классификации и устанавливает тот факт, что А -тип является подтипом В -типа, если каждый объект А -типа является также объектом В -типа. Данный тип наследования отражает структурные, а не функциональные аспекты объектов. Наследованиеограничения образует подкласс класса наследованиявключения, а именно: А -тип является подтипом В -типа, если он состоит из всех объектов А -типа, удовлетворяющих заданному ограничению. Наконец, наследованиеспециализации заключается в том, что А -тип является подтипом В -типа, если объекты А -типа являются объектами и В -типа, содержащими более специфическую информацию. Следует отметить, что с различной степенью полноты указанные четыре типа наследования поддерживаются всеми существующими на сегодня ООСУБД.

6. В целом ряде случаев необходимо располагать однимименем, используемым для различныхреализации одной и той же операции. Например, используется операция GS(X), которая в зависимости от типа Х -объекта обеспечиваетразличные алгоритмы обработки. Естественно, что в момент компиляции программы тип Х -объекта неизвестен. Поэтому в традиционной технологии программист в своей программе обеспечивает проверку на тип Х -объекта (переменной) и в зависимости от ее результата осуществляет ветвление вычислительного алгоритма. В условиях ООСУБД такая операция GS(X) определяется на уровнеобъектного (наиболее общего в системе) типа; однако реализация операции переопределяется (настраивается) для каждого из типов обрабатываемых Х -объектов. В этом случае, применяя операцию GS(X), мы предоставляем возможность самой системе динамически отыскивать (настраивать) подходящую реализацию операции согласно типа Х -объекта. Для обеспечения этой новой черты ООС не может связывать имена операций с программами их реализации в период компиляции. Следовательно, присваивание имен реализациям должно осуществляться динамически, т.е. поддерживается принципотложенного присвоения имен операционным программам. Следует отметить, что несмотря на то, что отложенное присвоение существенно усложняет проверкутипов (а в ряде случаев делает ее просто невозможной), полностью оно такую проверку не исключает.

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

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

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

9. Современные ООСУБД, представляющие собой четвертое поколение в технологии управления данными, в коммерчески пригодном исполнении появились относительно недавно. Они поддерживают все рассмотренные выше черты и характеристики как традиционных СУБД, так и объектно-ориентированной технологии (ООТ). В плане выразительных возможностей прикладной семантики ООСУБД существенно мощнее традиционных реляционных СУБД. Превосходный сравнительный анализ реляционных СУБД и ООСУБД можно найти в . Первыми разработчиками ООСУБД в 1990 г. явились фирмы Object Design, OBJECT-Sciences, Objectivity, OntoLogic и Servio (США). Наряду с ними ряд разработчиков классических реляционных СУБД расширили свои системы объектно-ориентированными средствами. Среди наиболее удачных разработок можно отметить, в первую очередь, ООСУБД VERSANT фирмы Versant Object Technology, которая поддерживает ряд широко используемых стандартов, а также концепцию ООСУБД, рассмотренную выше. В качестве примера кратко рассмотрим вопросы VERSANT-технологии управления данными, базирующейся на ООСУБД VERSANT, на сегодня являющейся одним из стандартов дефакто для такого типа ООС.

10. На основе технологии разработан достаточно широкий спектр высокопроизводительных объектно-ориентированных ПС, позволяющих создавать гибкие интегрированные информационные системы (ИИС), включая в них уже существующие СУБД пользователя. Дополнительно к ООСУБД-технологии VERSANT-технология в целом поддерживает средства интегрирования однородных БД, набор языковых интерфейсов, наборы средств для администратора БД, системного и прикладного программистов, а также специальные средства, обеспечивающие нужды пользователя. Наряду с ООТ VERSANT-технология позволяет создавать пользовательские ИИС более производительными, гибкими и реактивными. При этом обеспечивается интегрирование существующих пользовательских РБД и ООСУБД VERSANT в единую унифицированную информационную систему; VERSANT-технология для любой БД системы допускает режимклиент-сервер, а для ООСУБД - многопользовательский и многосерверный режимы. Следовательно, информация такой системы может разделяться на весьма широкой основе пользователями, получающими доступ к любому количеству однородных распределенных БД, функционирующих на широком спектре программных и технических средств. При этом все различия между компонентами системы невидимы и несущественны (инкапсулированы) для конечного пользователя - относительно конечного пользователя такая ИИС представляется как единое целое.

Использование VERSANT-технологии позволяет повышать производительность прикладных программистов на порядок и более, а производительность самих ИИС почти на два порядка. Полученный опыт подтверждает, что современные ООСУБД обладают примерно на два порядка большей производительностью, чем реляционные СУБД при поиске сложной информации. Например, при использовании самой быстрой реляционной СУБД для поиска описания некоторого объекта, содержащего несколько тысяч элементов, потребовалось порядка 15 мин, тогда как ООСУБД VERSANT на эту же задачу потребовалось менее 10 с. На рисунке 5.6 представлена общая 8-уровневая архитектура ИИС VERSANT, начиная с ООСУБД и кончая конечным пользователем.

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

Второй уровень содержит единственную компоненту VERSANT Star системы, осуществляющую интеграцию различных СУБД. Она управляет доступом кобъектам, находящимся в системе БД первого уровня архитектуры. С этой целью она использует набор БД-драйверов, поддерживающих индивидуальные БД-форматы. По этой причине в настоящее время поддерживаютсятолько наиболее популярные СУБД (ORACLE, DB/2, IMS и др.), но данный список постоянно расширяется. Этому способствует и переход к новому единому ASCII-стандарту для реляционных СУБД.

В отличие от некоторых ООСУБД система VERSANT не использует единого языка программирования и не требует от пользователя использования какого-либо конкретного компилятора или транслятора. Она позволяет для работы со своими БД использовать многие как традиционные, так и объектно-ориентированные ЯВУ(третий уровень; смотри рисунок 5.6). Достигается это посредством введения языковых интерфейсов в виде библиотек классов и функций. Посредством использования данных библиотек в своих прикладных программах пользователь получает доступ ко всем ресурсам VERSANT-системы на широком спектре различных ЯВУ. В настоящее время поддерживаются пять базовых языков: Pascal, С, C++, SmallTalk и Object SQL. Последний является расширением SQL-стан-дарта, позволяющим управлять структурами объектно-ориентированных данных. В свою очередь, С-интерфейс может быть использован любым языком программирования, допускающим вызовы внешних С -функций (Pascal, Fortran, Cohol и др.). Это позволяет пользователю писать свои прикладные программы на подходящем ЯВУ, обеспечивая доступ к любой БД, интегрированной в VERSANT-систему. Следующие три уровня архитектуры определяют (ЗхЗ)-матрицу средств, предназначенных для облегчения разработки прикладных программ и администрирования интегрированной ООСУБД VERSANT-системы.

Четвертый уровень содержит средства, расширяющие возможности прикладных программ, написанных на ЯВУ уровня 3 и совместимых с ними. Компонента этого уровня Object Modeler является наиболее многоцелевым средством, позволяющим средствами графического интерфейса на экране определять объектно-атрибутные структуры данных. Затем эти структуры данных могут автоматически транслироваться в С -структуры, {С+SmallTalk} -классы или SQL-таблицы, позволяя существенно сокращать время разработки прикладных программ.

Средство Object Modeler оказывает неоценимую помощь в деле повышения продуктивности пользователя, так как позволяет только один раз определять структуры данных, а затем повторно использовать их во многих различных приложениях безотносительноязыка, на котором они были запрограммированы, или БД, к которым организуется доступ. Вторым важным преимуществом данного средства является то, что оно может непосредственно использоваться системотехниками, воспитанными на традиционной технологии, а не на ООТ. Два других средства уровня 4 обеспечивают поддержку языка запросов SQL-стандарта. Так, на базе средства SQL Gateway (шлюза) пользователь в своих программах на языках C++ и/или SmallTalk может организовывать запросы в SQL-стандарте и автоматически получать результаты запросов в соответствующие объекты программы. Средство же Embedded SQL позволяет использовать предложения языка Object SQL для расширенного доступа к объектно-ориентированным структурам данных.

Пятый уровеньархитектуры (смотри рисунок 5.6) включает средства для администратора БД, предназначенные для настройки и управления распределенными БД. Данные средства пригодны также и для прикладных программистов, но только первое из них обычно ими используется. Средство Designer представляет собой графический инструмент для программистов и администратора БД, позволяющий в рамках VERSANT-баз создавать и управлять иерархиями классов. Средство автоматически генерирует определения классов для языка C++ из их графического представления. Более того. Designer может просматривать БД, позволяя пользователю или администратору проверять (просматривать) определения классов в БД, включая их атрибуты, отношения и методы. С его помощью можно проверять, изменять или удалять (т.е.редактировать} отдельные элементы в БД. Средство Repository Builder позволяет администратору БД определять и обслуживать метаданные из архива данных системы. По функционированию данное средство несколько напоминает предыдущее, но включает ряд специальных возможностей для обеспечения доступа именно к информации архива системы. Наконец,Administrator представляет собой набор средств администратора БД, поддерживающих: командный (оперативный) режим управления пользователями и доступом к БД, операции восстановления, а также выполнять другие стандартные сервисные функции по обслуживанию ООСУБД VERSANT-системы.

Шестой уровень включает средства, предназначенные для быстрой генерации мощных объектно-ориентированных прикладных программ на основе библиотек классов, поддерживаемых системой. Графическое Screen -средство ориентировано на разработку необходимыхграфических интерфейсов для приложений. Наряду с этимScreen имеет развитые средства для управленияшироким набором носителей информации Например, можно вводить диаграммы, производить поиск в БД фотографий, карт или осуществлять другие процедуры (не поддерживаемые традиционными пакетами) по работе с форматированной информацией. Средство Report предназначено для подготовки отчетов и при необходимости может выполнять роль традиционногогенератора отчетов. Наконец, Object 4GL представляет собой ЯВУ программирования БД, который может быть использован для состыковки операций и объектов, созданных другими средствами системы. Следует отметить, что графические интерфейсы, отчеты и процедуры, созданные средствами шестого уровня, сохраняются в архиве системы (Repository) и становятся доступными для всех приложений в среде VERSANT-системы. Более того, по причине определения этих прикладных конструкций в терминах абстрактных категорий и атрибутов, они могут использоваться и с другими типами СУБД.

Седьмой уровень архитектуры (смотри рисунок 5.6) представляютспециализированные приложения (библиотеки классов), специально адаптированные к нуждам той или иной области приложений VERSANT-системы (проектирование, конструирование, производство, строительство, сетевое моделирование и др.). Средства данного уровня стали возможными благодаря принципу многократного использования, поддерживаемому ООТ.

Наконец, навосьмом уровнеархитектуры представлены фактические (конечные) приложения VERSANT-технологии. Используя средства седьмого уровня или создавая свои собственные, пользователь завершает создание конкретного функционально полного приложения VERSANT-системы. На рисунке 5.6 условно показано, какнекоторый интегрированный пакет для проектирования в области разработки и производства интегральных схем (CIM Applications) может быть перенастроен на основе средств седьмого уровня (Engineering, Manufacturing, Finance), используя их функциональные возможности, чтобы быстро связывать изменения проектных решений с производственными затратами и оценивать их влияние на себестоимость конечного изделия. Практическое использование VERSANT-технологии позволяет говорить о ее большихпотенциях для разработчиков АСУП и АСУТП всех уровней.

Первоначально средства VERSANT-технологии были разработаны и эксплуатировались на платформах Sun 3/4, мини-ЭВМ IBM RISC System/6000, DEC -станциях, HP 9000/400, системах Silicon Graphics, InterGraph 6000 и последующих сериях мультипроцессорных ЭВМ. В настоящее время указанныеООС функционируют также на платформах Unix, Windows, OS/2 и Macintosh. Эти реализации делают VERSANT-технологию доступной для широкого круга пользователей IBM-совместимых ПК и существенно расширяют ее возможности для обеспечения распределенной обработки информации в условиях функционирования различного назначения ИИС.

Лекция 7 (2 часа)

Нет необходимости говорить, насколько широкое распространение получила в последнее время идеология обьектов в самых разных областях информатики. Обьектный подход присутствует, кажется, во всех мыслимых разработках, начиная от операционных систем, таких как Gairo и Taligent, и кончая текстовыми процессорами и электронными таблицами. Системы управления базами данных не представляют в данном случае исключения. Один из самых насущных вопросов, стоящих перед разработчиками СУБД, состоит в том, как обеспечить возможность хранения и работы с данными бурно развивающихся сейчас нетрадиционных приложений. Практика показала, что наиболее распространенная сегодня реляционная технология мало пригодна для работы со сложными обьектами, встречающимися в приложениях мультимедиа, GAD/GAM, CASE, географических информационных системах, полнотекстовых базах данных, системах управления большими компьютерными сетями. Объектно-ориентированный подход - это попытка преодолеть ограничения, связанные с использованием традиционной (реляционной) технологии СУБД.

Примеры использования объектно-ориентированных СУБД

Объектно-ориентированная СУБД - это система, позволяющая создавать, хранить и использовать информацию в форме объектов (см. ). Полностью объектно-ориентированная СУБД обеспечивает также объектно-ориентированный интерфейс взаимодействия с пользователем .

Наиболее широкое применение объектно-ориентированные базы данных нашли в таких областях, как системы автоматизированного конструирования/производства (CAD/CAM), системы автоматизированной разработки програмного обеспечения (CASE), системы управления составными документами - словом, в областях не вполне традиционных для баз данных. Особенно заметно присутствие объектноориентированных СУБД в сфере CAD/CAM .

Ряд американских компаний - Auto-trol Tecnology, STEP Tools, DEC и другие - используют объектно-ориентированные СУБД (например, ObjectStore производства компании Object Design) для работы со сложноконструированными данными, соответствующими стандарту STEP (Standart of Exchange of Product Model Data - Стандарт обмена данными моделей продуктов). Этот стандарт идет гораздо дальше своих предшественников, таких как IGES, поскольку, помимо информации о геометрии детали, он должен включать информацию о версиях, спецификациях материалов, допусках, о том, как отдельные детали соединяются в агрегаты.

Компания Computervision, крупный производитель программного обеспечения для CAD, интегрировала в свои продукты СУБД ObjectStore. К СУБД предъявлялись требования хранить и манипулировать объектами, которые могут состоять из сотен тысяч элементов, причем объем данных по одному проекту CAD мог быть до 1000 гигабайт. Ни одна из реляционных СУБД, имеющихся на рынке, не могла поддерживать приемлемого быстродействия при работе с данными такой сложности и объема.

Компания Enterprise Integration Tecnologies предлагает продукт MKS (Manufacturing Knowledge System - система знаний о производстве). В рамках этого продукта возможно интегрировать разработку технологических процессов, разработку оборудования, управление предприятием, проектирование производственных помещений, диагностику, мониторинг, моделирование и планирование. Основная применения продукта - заводы по производству микросхем, хотя он пригоден для управления производством во многих отраслях. В качестве СУБД системы, хранящей информацию о всех составляющих производственного процесса, используется Objectivity/DB. Вполне естественно задаться вопросом, почему приходится отказываться от зарекомендовавшей себя реляционной технологии и пробовать не вполне проверенные временем объектно-ориентированные подходы.

Ограничения реляционно технологии, или почему ООБД

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

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

гибкость - насколько легко в рамках данной модели можно решать сложные ситуации приложений;

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

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

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

2. Затруднительно должным образом смоделировать свойства данных. Чтобы естественно смоделировать структуру сложных данных, пользователь должен иметь возможность определять свои типы данных, не ограничиваясь типами данных, предоставляемыми определенной СУБД.

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

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

5. Усложненный доступ к базе данных. Интерфейс между языком программирования и языком баз данных обычно усложнен, поскольку каждый язык имеет свой набор типов и свою модель вычислений. Организуя обращение к базе данных из прикладной программы, написанной, например, на C++, приходится подвергать данные структурной трансформации при передаче их из/в базу данных.

Технология объектно-ориентированных СУБД

Создание базы данных, как правило, включает несколько этапов . Среди них можно выделить:

1. Создание концептуальной модели данных (см. ). Как правило, на этом этапе происходит уточнение требований пользователей; модель не связывается с каким-либо конкретным способом реализации, какой-либо конкретной СУБД. Такие свойства технологии моделирования, как выразительность и гибкость, играют здесь первостепенное значение. Довольно часто на практике этап создания концептуальной модели пропускается, что чревато просчетами, которые трудно и дорого исправлять на последующих этапах.

2. Логическое конструирование. На этом этапе создается модель, пригодная для реализации средствами какой-либо определенной СУБД. Здесь уже приходится считаться с ограничениями по типам данных, набору операций, налагаемыми конкретной СУБД.

3. Физическое конструирование. На этом этапе прорабатываются вопросы, связанные с реализацией модели данных во внешней памяти, - кластеризации, разбиения (partitioning), индексирования.

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

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

2. Подклассы и суперклассы - экземпляры некоторого класса могут образовывать подмножество другого класса. Так, классы "студент" или "преподаватель" могут рассматриваться как подкласс класса "человек". Для "студента" и "преподавателя" "человек" является суперклассом.

3. Подклассы наследуют атрибуты и поведение своих суперклассов (например, "студент" и "преподаватель" наследуют у "человека" такие атрибуты, как "имя", "пол", "возраст" и т.д.).

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

5. Агрегирование - по зволяет создать сложные объекты из объектов-компонентов, определять отношения типа "часть-целое".

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

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

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

СУБД РОЕТ - пример реализации объектно-ориентированной технологии

Уже сейчас на рынке программных средств имеется более дюжины первоклассных систем, поддерживающих работу с объектно-ориентированными базами данных (см. ). Остановимся подробнее на разработке компании BKS Software - СУБД РОЕТ. Система РОЕТ - это типичный пример объектно-ориентированной СУБД (следуя нотации Питера Коада и Эдварда Йордона ), которая является многопользовательской, переносимой и интегрируемой, обеспечивающей двухступенчатый механизм транзакций и блокировку конкурентного доступа к обрабатываемым объектам.

В настоящее время СУБД РОЕТ доступна не только в нескольких вариантах для UNIX платформ, но и для систем Windows 3.1, NT, OS/2, Мас System 7 и NextStep.

По сути, объектно-ориентированная СУБД РОЕТ представляет собой библиотеку классов на языке С++ и препроцессор, выполняющий обработку объектно-ориентированной структуры данных и генерацию баз данных.

Использование СУБД РОЕТ позволяет разработчикам баз данных:

1. свести к минимуму барьеры между стадиями разработки информационной системы;

2. работать с данными практически любых типов;

3. использовать стандартный С++ интерфейс для разработки как самих баз данных, так и для интеграции баз данных с другими системами (графический интерфейс с пользователем, например).

Структура служебных классов СУБД РОЕТ схематически изображена на Рисунке 1. Эта упрощенная схема (на самом деле, взаимосвязи между классами намного сложнее) позволяет оценить основные возможности системы. Центральное место системы занимает класс PtObject, который является базовым для всех классов базы данных (например, класс "клиент", "заказ" и т.п.). Подклассы, образованные от класса PtObject, для работы со строками, датами, временем могут использовать классы PtString PtDate, PtTime. Для агрегирования объектов используется класс PtSet - своеобразный контейнер классов PtObject. Например, человек может иметь несколько имен, и, таким образом, подкласс "человек" класса PtObject содержит в себе класс PtSet - набор классов "имя", образованных от класса PtObject, которые, в свою очередь, для хранения имен, отчеств и фамилий содержат строковые объекты, образованные от класса PtString.

Отношения один-ко-многим получаются использованием класса PtOnDemand. Вся база данных (на логическом уровне) - это объект класса PtAllSet, а часть базы данных может быть представлена как объект класса PtSet. Объект класса PtQuery генерирует запрос к объекту класса PtAllSet, и результат обычно записывается в объект класса PtSet. Объекты классов PtAllSet и PtObject связаны с объектом класса PtBase, представляющим собой базу данных в целом на уровне файловой системы. Создавая приложение, разработчику программисту необходимо выполнить следующие шаги:

1. Описать все типы и структуры данных, используя POET/C++ нотацию. В результате получается *.hcd файл описания структуры базы данных.

2. Написать интерфейс для работы с базой данных (ввод, просмотр, поиск объектов и т.п.), используя, например, язык С++.

3. Откомпилировать составные части разрабатываемой системы.

На рисунке 3 схематически представлена структура объектов, описывающая данные о работниках, которые трудятся над проектами, и рядом представлен фрагмент соответствующего.hcd файла. Каждый работник связан с одним проектом. Над проектом может трудиться несколько человек. Работник (класс Person) может быть программистом (класс Programmer). Программист отличается от обычного работника знанием языков программирования, и, следовательно, класс Programmer содержит не только дополнительные данные (language), но и разные методы ввода и вывода.

Проблемы и перспективы

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

Неясным пока остается положение со стандартами объектно-ориентированной технологии. Борьба идет между стандартами OLE 2.1 (Object Linking and Embedding, фирма Microsoft) и CORBA 2 (Common Object Request Broker Architecture, группа OMG - Object Management Group, объединяющая компании IBM, HP, Sun, Novell, ВЕС и др.). За спиной Microsoft стоят тысячи независимых разработчиков программного обеспечения для ПК, которые, как предполагается, с появлением системы Cairo перейдут на технологию Distributed OLE. Группа OMG отстаивает стандарт, ориентированный на все платформы и предназначенный для всех производителей, включая и Microsoft. Ясно, что отсутствие компромисса и война стандартов на модели объектов и способы обслуживания объектов всего лишь заставит производителей программного обеспечения на неопределенное время занять выжидательную позицию.

Тем не менее, современное системное программное обеспечение (операционные системы и средства разработки) становится всерьез объектно-ориентированным, и возможно, что к концу 1995 года объекты будут повсюду. Это обещают три конкурирующих проекта : объектно-ориентированная среда OpenStep (компании Sun, HP, NeXT обещают создать ее к началу 1995 года), объектно-ориентированная среда и файловая система Cairo - объектно-ориентированная версия Windows-NT вместе с новой системой хранения файлов Object File System (фирма Microsoft планирует выпустить рабочую версию к лету 1995 года) и объектно-ориентированная операционная система Taligent (компании IBM, Apple, HP планируют завершить создание системы в 1995-96 годах).

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

Следует обратить серьезное внимание на попытки интеграции реляционного и объектно-ориентированного подхода . Эти попытки заметны как со стороны известных поставщиков реляционных СУБД, так и со стороны компаний-производителей объектно-ориентированных СУБД. Можно ожидать, что такие компании-поставщики реляционных СУБД, как Oracle, Informix, SyBase, ASK Group (СУБД Ingres), IBM (СУБД DB2) в течение 1994-1996 годов в той или иной мере начнут поддерживать объектно-ориентированные технологии в своих продуктах. Большие надежды при этом возлагаются на язык запросов SQL-3, находящийся пока в стадии рассмотрения, который должен включать объектные расширения. Со своей стороны, производители объектно-ориентированных баз данных пытаются интегрировать в свои продукты элементы реляционной технологии. Так, фирма Objectivity Inc. включила в третью версию своего продукта поддержку ANSI-стандарта языка SQL. Ряд продуктов, так или иначе интегрирующих реляционный и объектно-ориентированный подходы, включают OpenODB (производитель - компания Hewlett-Packard), семейство продуктов UniSQL, производимых одноименной компанией, Montage, производства компании Montage Software, Inc. Остается, однако, вопросом, насколько глубоко и естественно можно интегрировать реляционную и объектно-ориентированную технологии. На данном этапе журнал "Datamation" считает целесообразным исследовать применимость объектно-ориентированных СУБД для данной предметной области путем реализации локальных проектов.

Заключение

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

Литература

Andleigh P.K., Grelzinger M.R. Distributed Object-Oriented Data Systemss Design. - Prentice Hall, 1992.

Coad Р., Yourdon E. Object-Oriented Analysis. - Prentice Hall, 1991.

Navathe S.B. Evolulion of Data Modelling for Databases // Communications of the ACM. - 1992. - September. - p.112-123.

Semich W.J. What"s the Next Step after Client/Server // Dalamation. - 1994. - March, 15. - p.26-34.

Stone C.M., Hentchel D. Database Wars Revisited. - Byte. - 1990. - December. - p.233-244.

The Lee Wedding Bells Sound for Objects And Relational Data // Datamation. - 1994. - March, 1. - р.49-52.

Объектно-ориентированный подход

Идеология объектно-ориентированного программирования получила развитие в рамках разработки таких языков, как SmallTalk или С++.

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

В основе объектной идеологии, естественно, лежит понятие объекта.

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

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

3. Полиморфизм - различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, как реализованы у них методы, реагирующие на сообщения. Например, объект класса "линия" отреагирует на сообщение "нарисовать" рисованием линии, тогда как объект класса "окружность" - рисованием окружности.

Объектно-ориентированный системный анализ

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

Основной принцип системного анализа - декомпозиция. Исторически сперва использовалась функциональная декомпозиция с построением иерархий функций. Взаимосвязи функций во времени представлялись потоками функций. Однако в большинстве систем, если говорить, например, о базах данных, типы данных являются наиболее статичным элементом. Действительно, типы паспортных данных о человеке остаются (имя, фамилия, год рождения и т.п.), а способы их обработки, виды запросов могут меняться относительно часто. Поэтому получили развитие такие методы системного анализа, как диаграммы потоков данных - DFD (Data Flow Diagram). Развитие реляционных баз данных подтолкнуло к совершенствованию методик построения моделей данных, в частности, ER-диаграмм (Entity Relationship Diagram). Однако, ни функциональная декомпозиция, ни потоки данных, ни модели данных, являясь мощными инструментами, дающими срез исследуемой предметной области, не позволяют получить естественное формальное представление системы в целом.

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

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

Объектно-ориентированные базы данных - компании и разработки

Управление информацией всегда было основной сферой применения компьютеров и, надо думать, будет играть еще большую роль в будущем. Системы управления базами данных (СУБД, DBMS – Database Management System) на протяжении всего пути развития компьютерной техники совершенствовались, поддерживая все более сложные уровни абстрактных данных, заданных пользователем, и обеспечивая взаимодействие компонентов, распределенных в глобальных сетях и постепенно интегрирующихся с телекоммуникационными системами. Позволив себе рассуждения в стиле Билла Гейтса, предположим, что результатом будет становление систем управления информацией одной из частей повседневной жизни каждого.

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

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

Эволюция систем управления информацией шла параллельно этому прогрессу, начиная с низкоуровневых программ, которые, например, напрямую производили операции чтения и записи со всей памятью без ограничения доступа, лентой, цилиндрами и дорожками диска и более высокоуровневыми средствами – файловыми системами, которые оперировали с такими понятиями, как массивы, записи и индексы для повышения производительности. Базы данных в свою очередь начинали с модели записей и индексов (ISAM и др.), приобретая со временем способность восстановления после сбоев, проверки целостности данных и возможности работы нескольких пользователей одновременно. Эти ранние модели данных (CODASYL) относились скорее к уровню машинной ориентации. В дальнейшем реляционные базы данных , пришедшие на смену в 1980‑х годах, приобрели механизм запросов , позволяющий пользователю указать требуемое, предоставив СУБД самой оптимальным образом найти результат, используя динамическую индексацию.

Обьектно-ориентированные СУБД (ООСУБД ) стали разрабатываться с середины 80‑х годов в основном для поддержки приложений САПР. Сложные структуры данных систем автоматизированного проектирования оказалось очень удобно оформлять в виде объектов, а технические чертежи проще хранить в базе данных, чем в файлах. Это позволяет обойтись без декомпозиции графических структур на элементы и записи их в файлы после завершения работы с чертежом, выполнения обратной операции при внесении любого изменения. Если типичные реляционные базы данных имеют связи глубиной в два уровня, то иерархическая информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для “сборки” результата. Объектные базы данных хорошо соответствовали подобным задачам, и эволюция многих СУБД началась именно с рынка САПР.

Между тем рынок САПР был быстро насыщен, и в начале 90‑х годов производители ООСУБД обратили внимание на другие области применения, уже прочно занятые реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями оперативной обработки транзакций (OLTP), утилитами администратора баз данных (database administrator – DBA), средствами резервного копирования/восстановления и т. д. Работы в данном направлении продолжаются и сегодня, но уже можно сказать, что переход к коммерческим приложениям идет достаточно успешно.

2. Реляционные базы данных.

В реляционных базах данных (Relational Database System, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.

Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70‑х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.

Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк.

Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key) .

Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько нибудь сложных взаимосвязей в базе данных. Желающим убедится, что это действительно так и не пожалевшим на это определенный отрезок времени, компания POET Software любезно предоставляет возможность ознакомиться с примером в своей “белой книге” “POET Technical Reference”. База данных рядового предприятия общепита (клиенты – Джордж Буш и Эдди Мэрфи) состоит из четырех таблиц.

Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость манипулирования информацией и изменения связей.

3. Объектно-реляционные методы.

Несмотря на рассмотренные в п. 2 недостатки реляционных баз данных, они обладают рядом достоинств:

· разделение таблиц разными программами;

· развернутый “код возврата” при ошибках;

· высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию);

Существуют два подхода к организации реакции СУБД для предотвращения потери данных. Большинство систем передают приложению указатели на объекты, и рано или поздно такие указатели обязательно становятся неверными. Так, они всегда неправильны после перехода объекта к другому пользователю (например, после перемещения на другой сервер). Если программист, разрабатывающий приложение, пунктуален, то ошибки не возникает. Если же приложение попытается применить указатель в неподходящий для этого момент, то в лучшем случае произойдет крах системы, в худшем – будет утеряна информация в середине другого объекта и нарушится целостность базы данных. Есть метод, лучший, чем использование прямых указателей (Рисунок 3). СУБД добавляет дополнительный указатель и при необходимости, если объект перемещается, система может автоматически разрешить ситуацию (перезагрузить, если это необходимо, объект) без возникновения конфликтной ситуации. Существует еще одна причина для применения косвенной адресации: благодаря этому можно отслеживать частоту вызовов объектов для организации эффективного механизма свопинга. Это необходимо для реализации уже второго необходимого свойства баз данных – масштабируемости. Опять следует упомянуть организацию распределенных компонентов. Классическая схема клиент-сервер, где основная нагрузка приходится на клиента (такая архитектура называется еще “толстый клиент-тонкий сервер”), лучше справляется с этой задачей, чем мэйнфреймовая структура, однако ее все равно нельзя масштабировать до уровня предприятия. Благодаря многозвенной архитектуре клиент-сервер (N-Tier architecture) происходит равномерное распределение вычислительной нагрузки между сервером и конечным пользователем. Нагрузка распределяется по трем и более звеньям, обеспечивающим дополнительную вычислительную мощность. К чему же еще ведет такая практика? “Архитектура клиент-сервер, еще совсем недавно считавшаяся сложной средой, постепенно превратилась в исключительно сложную среду. Почему? Благодаря ускоренному переходу к использованию систем клиент-сервер нескольких звеньев” (PC Magazine). Разработчикам приходится расплачиваться дополнительными сложностями, большими затратами времени и множеством проблем, связанных с интеграцией. Оставим очередное упоминание распределенных компонентов на этой не лишенной оптимизма ноте. Третье необходимое качество базы данных – это отказоустойчивость. Именно это свойство отличает программный продукт от “прилады”. Существуют несколько способов обеспечения отказоустойчивости: · резервное копирование и восстановление; · распределение компонентов; · независимость компонентов; · копирование. Руководствуясь первым принципом, программист определяет потенциально опасные участки кода и вставляет в программу некоторые действия, соответствующие началу транзакции – сохранение информации, необходимой для восстановления после сбоя, и окончанию транзакции – восстановление или, в случае невозможности, принятие каких-то других мер, например, отправка сообщения администратору. В современных СУБД этот механизм обеспечивает восстановление в случае возникновения практически любой ошибки системы, приложения или компьютера, хотя, конечно, нельзя говорить об идеальной защите от сбоев. В мэйнфреймовой архитектуре единственным источником сбоев была центральная ЭВМ. При переходе к распределенной многозвенной организации ошибки могут вызывать не только компьютеры, включенные в сеть, но и коммуникационные каналы. В многозвенной архитектуре при сбое одного из звеньев без специальных мер результаты работы других окажутся бесполезными. Поэтому при разработке распределенных систем обеспечивается принципиально более высокий уровень обеспечения отказоустойчивости. Назовем обязательные для современных распределенных СУБД свойства: · прозрачный доступ ко всем объектам независимо от их местоположения, благодаря чему пользователю доступны все сервисы СУБД и может производиться перераспределение компонентов без нежелательных последствий. Что произойдет, если один из компонентов выйдет из строя? Система, созданная в соответствии только с вышеизложенными доводами, приостановит работу всех пользователей и прервет все транзакции. Поэтому важно такое свойство СУБД, как независимость компонентов. При сетевом сбое сеть разделяется на части, компоненты каждой из которых не могут сообщаться с компонентами другой части. Для того, чтобы сохранить возможность работы внутри каждой такой части, необходимо дублирование критически важной информации внутри каждого сегмента. Современные системы позволяют администратору базы данных динамически определять сегменты сети, варьируя таким образом уровень надежности всей системы в целом. И, наконец, о копировании (replication) данных. Простейшим способом является добавление к каждому (основному) серверу резервного. После каждой операции основной сервер передает измененные данные резервному, который автоматически включается в случае выхода из строя основного. Естественно, такая схема не лишена недостатков. Во-первых, это приводит к значительным накладным расходам при дублировании данных, что не только сказывается на производительности, но и само по себе является потенциальным источником сбоев. Во-вторых, в случае сбоя, повлекшего за собой разрыв соединения между двумя серверами, каждый из них должен будет работать в своем сегменте сети в качестве основного сервера, причем изменения, сделанные на серверах за время работы в таком режиме, будет невозможно синхронизовать даже после восстановления работоспособности сети. Более совершенным является подход, когда создается необходимое (подбираемое в соответствии с требуемым уровнем надежности) число копий в сегменте. Таким образом увеличивается доступность копий и даже (при распределении нагрузки между серверами) повышается скорость чтения. Проблема невозможности обновления данных несколькими серверами одновременно в случае их взаимной недоступности решается за счет разрешения проведения модификаций только в одном из сегментов, например имеющем наибольшее число пользователей. При хорошо настроенной схеме кэширования затраты на накладные расходы при дублировании модифицированных данных близки к нулю. 4.3 Стандарты объектных баз данных. Для обеспечения переносимости приложений (приложение может работать на разных СУБД) и совместимости с СУБД (может взаимодействовать с разными СУБД), естественно, необходима выработка стандартов. Сразу заметим, что установление стандартов лишает производителя в некоторой степени свободы в принятии решений и увеличивает стоимость продукта за счет лицензионных отчислений и больше не будем обсуждать целесообразность (прямо скажем, очевидную) стандартизации. В области объектных СУБД в настоящее время выработаны стандарты для: · объектной модели; · языка описания объектов; · языка организации запросов (Object Query Language – OQL ); · “связующего” языка (C++ и, конечно же, Smalltalk); · администрирования; · обмена (импорт/экспорт); · интерфейсов инструментария и др. Хотя у Microsoft и свое мнение на этот счет, организацией, выработавшей наиболее используемые на сегодня и устоявшиеся стандарты, является консорциум поставщиков ООСУБД ODMG (ООСУБД), которого поддерживают практически все действующие лица отрасли. В сотрудничестве с OMG , ANSI, ISO и другими организациями был создан стандарт ODMG-93. Этот стандарт включает в себя средства для построения законченного приложения, которое будет работать (после перекомпиляции) в любой совместимой с этой спецификацией ООСУБД. В книгу ODMG-93 входят следующие разделы: · Язык определения объектов (Object Definition Language – ODL); · Язык объектных запросов (Object Query Language – OQL); · Связывание с C++; · Связывание со Smalltalk. ODL. В качестве языка определения объектов (ODL) ODMG был выбран существующий язык IDL (Interface Definition Language – язык описания интерфейсов), который был дополнен такими необходимыми для объектных БД свойствами, как определение коллекций, двунаправленных связей типа “многие-ко-многим”, ключей и др. В сочетании со средствами языка IDL определения атрибутов и операций, это позволяет определять практически любые объекты. Все дополнения реализованы в виде доопределения методов, что обеспечивает совместимость со стандартами OMG, например стандартом CORBA. Рисунок 4 показывает работоспособную схему для построения приложения на стандартных языках программирования, в процессе которой автоматически генерируются метаданные , заголовочные файлы и методы. Приведем также пример на языке ODL из “белой книги” компании Objectivity, который иллюстрирует связи типа “один-ко-многим”, объявленные между преподавателем и студентами: interface professor: employee { attribute string <32> name; unique attribute lang unsigned ssn; relationship dept works_in inverse faculty; relationship set teaches inverse taught_by; . . . operations . . . { interface section: class { . . . taught_by: professor . . . ; . . . } OQL. За основу языка OQL была взята команда SELECT языка SQL2 (или SQL-92) и добавлены возможность направлять запрос к объекту или коллекции объектов и возможность вызывать методы в рамках одного запроса. Данные, полученные в результате запроса, могут быть скалярными (включая кортежи), объектами или коллекциями объектов. Некоторые примеры на языке OQL (тот же источник): Select x from x in faculty where x.salary > x.dept.chair.salary sort s in (select struct (name: x.name, s:x.ssn) from x in faculty where for all y in x.advisees:y.age<25) by s.name Chair.salary Students except TAs list (1,2) + list (count (jse.advisees), 1+2) exists x in faculty : x.spouse.age<25 C++. Спецификация ODMG-93 позволяет программистам легко использовать объекты в то время как ООСУБД прозрачным образом управляет ими. При определении стандарта члены ODMG руководствовались следующими принципами: · Использование стандартных компиляторов обеспечивается тем, что все расширения реализуются средствами языка – библиотеками классов и перегрузкой операторов. · Определение временных экземпляров (Transient Instance) и экземпляров, создаваемых на длительный срок (Transient Instance) при помощи оператора new(). При перегрузке оператора new() оба типа экземпляров могут создаваться от одного класса, который может существовать продолжительное время. · Обеспечение устойчивости через стандартный механизм наследования; пользователь может определять экземпляры временные и рассчитанные на продолжительное использование средствами оригинальной версии языка. · Использование специального механизма указателей (Smart Pointers). Связи между объектами объявляются при помощи шаблона Ref<> и перегрузки оператора ->; это позволяет использовать специальные указатели (контролируемые системой; см., например, идентичность в словарике (стр. 21) и упоминание косвенной адресации (стр. 10) как обычные. class Professor: Employee { long ssn; char* name; int age; Refdept inverse faculty; Set teaches inverse taught_by; . . . void grant_tenure() void assign_course(section) } . . . Refprof; . . . prof = new(db, Professor); prof->name="Smith"; prof->age+prof->age+1; На этом, пожалуй, чувство благодарности компании Objectivity в значительной мере ослабеет, так как примеров на языке Smalltalk найти не удалось. Smalltalk . ODMG-93 поддерживает ту же объектную модель для Smalltalk, что и для С++, IDL и запросы на языке OQL; это позволяет разделять один и тот же объект пользователям С++ и Smalltalk. Спецификация поддерживает типы (возможны бестиповые поля) и синтаксис оригинальной версии Smalltalk. Рисунок 5 ООСУБД, построенная на основе стандартов ODMG во взаимодействии с CORBA. Взаимодействие с другими стандартами. Многие стандарты совместимы с объектными базами данных, например STEP, CFI, TINA-C, ISO ODP, ANSI X3H7, OpenGIS и др. Сейчас они могут напрямую взаимодействовать с любой стандартной ООСУБД, хотя в некоторые из них и были внесены изменения для обеспечения совместимости. Два других стандарта заслуживают более детального описания – OMG и SQL . Стандарты OMG . Первым результатом деятельности OMG стало утверждение (OMG не создает стандартов, а принимает одну из существующих реализаций) Архитектуры Брокера Объектных Запросов (Common Object Request Broker Architecture – CORBA ) – средства диспетчеризации запросов между объектами и пользователями; в дальнейшем были добавлены некоторые сервисы. Интерфейс ODMG сейчас полностью адаптирован к спецификации Persistence Object Service консорциума OMG, что позволяет пользователям систем, основанных на архитектуре CORBA, пользоваться преимуществами от ООСУБД, которые могут содержать объекты, отвечающие стандарту OMG и используемые так же, как и любые другие (“мелкие”) объекты спецификации OMG (Рисунок 5). Объекты OMG в свою очередь доступны через интерфейс ODMG. Язык SQL . Из-за распространенности SQL был заложен в основу OQL , который был дополнен средствами поддержки объектной модели. В настоящее время разрабатывается версия языка SQL, известная под названием SQL3, в которой будут реализована поддержка объектов и SQL будет приведен в соответствие современным понятиям о полноценном языке программирования. В отличие от ODMG, в SQL не планируется привязка к ODL, а также C++ и Smalltalk, которые важны для пользователей ООСУБД. Несмотря на это, возможности SQL3 в организации запросов совпадают с возможностями OQL. Когда SQL3 будет готов (разработки ведутся сейчас на ранней стадии обсуждения основных вопросов относительно объектной модели), ODMG, вероятно, дополнит его, как это уже сделано для С++ и Smalltalk. 4.4 Поставщики ООСУБД. Рисунок 6 Современный рынок СУБД. Список современных коммерческих объектно-ориентированных систем включает в себя следующие продукты: · Objectivity/DB компании Objectivity, Inc. (последняя версия – 2.1) идеально, по заявлениям фирмы, подходит для приложений, которые работают в распределенных средах, требуют гибкой модификации данных, организации сложных связей, а также нуждаются в высокой производительности и работы с большими объемами данных. Вероятно, все компании, производящие ООСУБД, ставят своей целью сложить такое впечатление относительно собственных разработок у читателей распространяемых ими документов (хотя некоторые и делают это в более деликатной форме). Более содержательно, Objectivity обеспечила интеграцию инструментария СУБД и разработки приложений с такими средствами программирования, как SoftBench и C++ SoftBench. Благодаря интегрированному графическому интерфейсу разработки схемы БД и инструментам отладки и анализа упрощается задание модели базы данных и, соответственно, разработки приложений для Objectivity/DB. · СУБД GemStone корпорации GemStone Systems, Inc. известна в последней редакции под номером 5.0. GemStone традиционно сосредоточена на рынке Smalltalk (хотя не так давно и была выпущена версия для С++) и имеет заказчиков, способных продемонстрировать на производстве крупномасштабные, целевые применения ее продуктов. К сожалению, списком этих заказчиков объем информации, которую компания хочет донести до интересующихся (WWW), ограничивается. · ONTOS Corp., разработчик СУБД ONTOS (кто бы подумал), по традиции занимается развитием сервера объектно-ориентированной СУБД, но в последнее время придает особое значение своим Службам Интеграции Объектов (Object Integration Services). · Построенная на основе реляционной СУБД AllBase, система OpenODB фирмыHewlett-Packard также, как и Objectivity/DB, интегрирована с системой SoftBench и существует в версии для С++. Благодаря глубокой интеграции, SoftBench распознает файлы приложений OpenODB для установки оптимальной конфигурации, может создавать базы данных формата OpenODB из своей интегрированной среды, обеспечивает оперативную помощь из среды разработки и т. д. · Object Design Inc. со своей СУБД ObjectStore занимает лидирующее положение в отрасли, осуществляя около 33% поставок на рынке объектно-ориентированных СУБД и последняя модернизация системы (клиент языка SQL и шлюз к реляционной СУБД) должны только укрепить положение фирмы. Object Design поддерживает версии своей СУБД как для С++, так и для Smalltalk. · Versant Object Technology, Inc. (СУБД Versant ) проводит двойную стратегию, предлагая средство обеспечения объектно-ориентированной СУБД высокого класса для телекоммуникаций и инструментальные средства Smalltalk для более общих случаев разработки приложений. Используя разработанный фирмой интерфейс VERSANT Smalltalk Language Interface, СУБД совместима как с версией языка Smalltalk компании ParcPlace-Digitalk, так и с Visual Age for Smalltalk корпорации IBM. · СУБД UniSQL компании UniSQL Inc. – хорошо устоявшаяся система, позволяющая пользователям осуществлять запросы и модификацию базы при помощи разработанного компанией языка SQL/X (подобные языки, носящие условное название Object SQL, разработаны и некоторыми другими поставщиками). Вся БД UniSQL может состоять одновременно из связей в локальных РСУБД и классов в локальных объектных базах UniSQL. Благодаря механизму каталогов, СУБД передает запросы и модификации данных в локальные базы данных и, обработав (перевод в другой формат, группирование, сортировка и т. д.) полученный от них результат, возвращает его пользователю. Кроме того ООСУБД предлагают: Object Database, Inc. (Object Database), Itasca Systems Inc. (Itasca) O2 Technology (O2) и некоторые другие компании. 5. Заключение. В 1996 г. наметился заметный сдвиг в области освоения объектных СУБД. Уже существуют примеры практического их использования крупными биржами, банками, страховыми компаниями, а также в сфере производства и телекоммуникаций, где базам данных, содержащим гигабайты информации, приходится обслуживать сотни пользователей. Они оказались хорошей альтернативой в тех случаях, когда применение реляционных БД вынуждало строить сложную схему с чрезмерно большим числом межтабличных связей. Благодаря значительному прогрессу в развитии объектной технологии, за последние пять лет производителям удалось довести свои ООСУБД до такого уровня, что они стали вполне отвечать реальным требованиям рынка. Несмотря на то, что технология объектных СУБД созрела для крупных проектов, для действительно массового ее распространения необходим специальный инструментарий. В настоящий момент ощущается настоятельная потребность в интеграции ООСУБД с существующими инструментальными средствами. Разработчики уже сегодня могли бы продуктивно использовать версии Visual Basic, Power Builder, Forte или Delphi, поддерживающие ООСУБД. Большинство продуктов для создания приложений в той или иной мере являются объектно-ориентированными, но работают по-прежнему с реляционными БД. Специалисты считают, что партнерство производителей ООСУБД и средств программирования способно привести к появлению столь необходимого инструментария. Эксперты уже неоднократно объявляли наступающий год “годом объектных баз данных”, однако сейчас все говорит о том, что 1997 г. действительно имеет шансы наконец им стать. Основными стимулами растущего интереса к ООСУБД аналитики считают расширение применения мультителиа-приложений и новых средств, улучшающих их стыкуемость с существующими базами данных. 6. Глоссарий 4GL (4 th Generation Language) – Язык программирования четвертого поколения ¨Язык программирования, при создании которого используются языки программирования третьего уровня (3GL) – процедурные языки типа C и Pascal. 4GL проще в использовании, чем 3GL, им обычно отдают предпочтение при составлении программ обслуживания баз данных и применяют в сочетании с соответствующими средствами разработки. Blob (Binary Large Object) – Двоичный большой объект, блоб. ¨Длинный линейный блок данных (например, цифровое изображение или видеоклип), который наиболее подходит для хранения в ООСУБД . CORBA (Common Object Request Broker Architecture) Архитектура брокера объектных запросов ¨Стандарт взаимодействия распределенных компонентов, разработанный OMG . DBMS (Database Management System) – Система управления базами данных, СУБД N - звенная архитектура (N-Tier Model) ¨Архитектура клиент-серврер , в которой применяются средства разбиения программ или распределенные объекты для разделения вычислительной нагрузки среди такого количества серверов приложений, которое необходимо при имеющемся уровне нагрузки. При многозвенной модели системы количество возможных клиентских мест значительно больше, чем при использовании двухзвенной модели. См также middleware . ODBMS (Object Database Management System) – Объектно-ориентированная СУБД – ООСУБД . ¨СУБД, хранящая данные и взаимосвязи между ее элементами непосредственно в самой базе данных в виде объектов, содержащих, как правило, алгоритмы обработки этих данных. ODMG (Object Database Management Group) ¨Консорциум производителей объектных баз данных для выработки стандартов (ODMG-93, ODMG-95). OMG (Open Management Group) ¨Консорциум поставщиков в сфере объектной технологии для выработки стандартов межкомпонентного взаимодействия. Объединяет практически всех ведущих производителей (более чем 500); членство Microsoft, видимо, лишь условно. OQL (Object Query Language) Язык объектных запросов ¨Разработанный консорциумом ODMG язык описания запросов, за основу которого был принят SQL -92. RDBMS (Relational Database Management System) – Реляционная СУБД – СУБД , хранящая взаимосвязи между элементами в виде двумерных таблиц и использующая для запросов язык SQL . SQL (Structured Query Language) – Язык структурированных запросов ¨Интерпретируемый язык, описывающий операции (создание, обработка и извлечение) над реляционными базами данных. Архитектура клиент-сервер (Client-server architecture) ¨Архитектура, обеспечивающая распределение нагрузки между клиентом и сервером. Обычно эти функции выполняют два разных компьютера, объединенных при помощи сети. Атрибуты (Attributes) ¨Видимая за пределами объекта информация о состоянии этого объекта. “Белая книга” (White Paper) ¨Официальное издание. Гибриды (Hybrids) ¨1. Средства связи между мирами объектных и реляционных баз данных, включая базы данных, которые хранят информацию в реляционной форме, но используют объектные буферные средства. См. также объектно-реляционные методы 2. СУБД , которые могут хранить и табличные данные, и объекты. Этого определения я старался придерживаться. Идентичность (Identity) ¨Возможность получения уникального адреса объекта независимо от его местоположения и атрибутов . Метаданные (Metadata) ¨Данные, являющиеся описанием других данных (например, схема базы данных по отношению к ее содержимому). Наследование (Inheritance) ¨Механизм, благодаря которому определения класса распространяется на классы, лежащие ниже его в иерархии обобщения классов. Это позволяет многократно изменять определения, внося по мере необходимости изменения, связанные со специализацией. Объектно-реляционные методы (Object-relational Approaches) ¨Подходы, позволяющие воспользоваться преимуществами объектных баз данных, не отказываясь полностью от реляционных БД. Отображение (Mapping) ¨Процесс установления связей между приложениями, построенными вокруг объектно-ориентированных и реляционных баз данных. Полиморфизм (Polymorphism) ¨Способность объектов различных классов и самих классов удовлетворять одним и тем же протоколам или отдельным сообщениям, выполняя при этом различные действия, предписываемые их собственными методами. Промежуточное обеспечение (Middleware) ¨ПО, служащее посредником между клиентом и сервером, например, для предоставления общих интерфейсов. Следуя традиции, и я тоже напишу, что промежуточное ПО – это слэш в термине “клиент/сервер”. Протокол (Protocol) ¨Набор сообщений, на которые может ответить класс (протокол класса) или его объекты (протокол объекта). Протокол определяется заданными методами. Все объекты одного класса отвечают одному протоколу. СУБД – Система Управления Базами Данных.¨Лежащая в основе базы данных прикладная программа, выполняющая операции над хранимой информацией. Транзакция (Transaction) – обработка запроса ¨Выполнение элементарной целостной операции над данными, в течение которой база данных находится в неустойчивом состоянии. ООСУБД (ODBMS)– Объектно-Ориентированная Система Управления Базами Данных. Термины, выделенные курсивом, как правило, приведены в словарике на стр. 21 Прежде, чем перейти к обсуждению организации некоторых объектно-ориентированных СУБД, следует коротко рассмотреть оказавшие на них влияние предшествующие архитектуры СУБД, а также архитектуры, не являющиеся в традиционном понимании объектно-ориентированными, но близкие по прагматике. Из числа архитектур с традиционной организацией наибольшее влияние на объектно-ориентированные СУБД оказали реляционные системы. Многие объектно-ориентированные системы (по крайней мере, в прототипных вариантах) строятся над некоторой существующей реляционной СУБД. Кроме такого применения реляционных систем для упрощения разработки объектно-ориентированной СУБД, развитые в реляционных СУБД методы применяются и в заново разрабатываемых объектно-ориентированных системах. Непосредственным предшественником объектно-ориентированных СУБД являются системы, поддерживающие организацию сложных объектов. Эти постреляционные системы большей частью появились по причине несоответствия возможностей реляционных СУБД потребностям нетрадиционных приложений (автоматизация проектирования, инженерия и т.д.). По сути дела, в таких системах частично поддерживается структурная часть объектно-ориентированных БД (без возможностей наследования). Многие объектно-ориентированные СУБД (в частности, ORION) разрабатывались на базе предыдущих работ со сложными объектами. Другой основой объектно-ориентированных СУБД являются так называемые расширяемые системы. Основная идея таких систем состоит в поддержании набора модулей с четко оговоренными интерфейсами, на базе которого можно быстро построить СУБД, опирающуюся на конкретную модель данных или предназначенную для конкретной области применений. В частности, как показывает опыт системы EXODUS, средства расширяемых систем хорошо пригодны и для построения объектно-ориентированной СУБД. Что касается направления третьего поколения СУБД, то, как следует из Манифеста третьего поколения, сторонники этого направления придерживаются принципа эволюционного развития возможностей СУБД без коренной ломки предыдущих подходов и с сохранением преемственности с системами предыдущего поколения. Тем не менее, несмотря на отличающуюся терминологию и смещенные акценты, системы третьего поколения не так уж далеки от объектно-ориентированных СУБД. Одной из наиболее известных СУБД третьего поколения является система POSTGRES, а создатель этой системы М. Стоунбрекер, по всей видимости, является вдохновителем всего направления. В POSTGRES реализованы многие интересные средства: поддерживается темпоральная модель хранения и доступа к данным и в связи с этим абсолютно пересмотрен механизм журнализации изменений, откатов транзакций и восстановления БД после сбоев; обеспечивается мощный механизм ограничений целостности; поддерживаются ненормализованные отношения (работа в этом направлении началась еще в среде INGRES). Но одно свойство системы POSTGRES действительно сближает ее с объектно-ориентированными СУБД. В POSTGRES допускается хранение в полях отношений данных абстрактных, определяемых пользователями типов. Это обеспечивает возможность внедрения поведенческого аспекта в БД, т.е. решает ту же задачу, что и ООБД, хотя, конечно, семантические возможности модели данных POSTGRES существенно слабее, чем у объектно-ориентированных моделей данных. Рассматривая особенности чисто объектно-ориентированных СУБД, следует выделить двух систем - ORION и O2. Основными функциональными компонентами первой системы являются подсистемы управления памятью, объектами и транзакциями. В ORION-1 все компоненты, естественно, располагаются в одной рабочей станции; в ORION-1SX - разнесены между разными рабочими станциями (в частности, управление объектами производится в рабочей станции-клиенте). Применение в ORION-1SX для взаимодействия клиент-сервер механизма удаленного вызова процедур позволило использовать в этой системе практически без переделки многие модули ORION-1. Сетевые взаимодействия основывались на стандартных средствах операционных систем. В число функций подсистемы управления памятью входит распределение внешней памяти, перемещение страниц из буферов оперативной памяти во внешнюю, а так же поиск и размещение объектов в буферах оперативной памяти. Как принято в объектно-ориентированных системах, поддерживаются два представления объектов - дисковое и в оперативной памяти; при перемещении объекта из буфера страниц в буфер объектов и обратно представление объекта изменяется. Кроме того, эта подсистема ответственна за поддержание вспомогательных индексных структур, предназначенных для ускорения выполнения запросов. Подсистема управления объектами включает подкомпоненты обработки запросов, управления схемой и версиями объектов. Версии поддерживаются только для объектов, при создании которых такая необходимость была явно указана. Для схемы БД версии не поддерживаются; при изменении схемы отслеживается влияние этого изменения на другие компоненты схемы и на существующие объекты. При обработке запросов используется техника оптимизации, аналогичная применяемой в реляционных системах (т.е. формируется набор возможных планов выполнения запроса, оценивается стоимость каждого из них и выбирается для выполнения наиболее дешевый). Подсистема управления транзакциями обеспечивает традиционную сериализуемость транзакций, а также поддерживает средства журнализации изменений и восстановления БД после сбоев. Для сериализации транзакций применяется разновидность двухфазного протокола синхронизационных захватов с различной степенью гранулированности. Конечно, при синхронизации учитывается специфика объектно-ориентированных БД, в частности, наличие иерархии классов. Журнал изменений обеспечивает откаты индивидуальных транзакций и восстановление БД после мягких сбоев (архивные копии БД для восстановления после поломки дисков не поддерживаются). Основными компонентами системы в проекте O2, не считая развитого набора интерфейсных средств, являются интерпретатор запросов и подсистемы управления схемой, объектами и дисками. Управление дисками, т.е. поддержание базовой среды постоянного хранения обеспечивает система WiSS, которую разработчики O2 перенесли в окружение ОС UNIX. Наибольшую функциональную нагрузку несет компонент управления объектами. В число функций этой подсистемы входит: · управление сложными объектами, включая создание и уничтожение объектов; · выборку объектов по именам, поддержку предопределенных методов; · поддержку объектов со внутренней структурой-множеством, списком и кортежем; · управление передачей сообщений между объектами; · управление транзакциями; · управление коммуникационной средой; · отслеживание долговременно хранимых объектов; · управление буферами оперативной памяти; · управление кластеризацией объектов во внешней памяти; · управление индексами. Объектно-ориентированные базы данных – базы данных, в которых информация представлена в виде объектов, как в объектно-ориентированных языках программирования. Применять или не применять объектно-ориентированные системы управления базами данных (ООСУБД) в реальных проектах сегодня? В каких случаях их применять, а в каких нет? Вот преимущества использования ООСУБД: Отсутствует проблема несоответствия модели данных в приложении и БД (impedance mismatch). Все данные сохраняются в БД в том же виде, что и в модели приложения. Не требуется отдельно поддерживать модель данных на стороне СУБД. Все объекты на уровне источника данных строго типизированы. Больше никаких строковых имен колонок! Рефакторинг объектно-ориентированной базы данных и работающего с ней кода теперь автоматизированный, а не однообразный и скучный процесс. Интересно? Тогда стоит попробовать! В статье описано все, что требуется для начала работы с ООСУБД db4o . Установка db4o На сегодняшний день db4o – одна из самых популярных объектно-ориентированных систем управления базами данных. Для начала скачиваем дистрибутив последней версии с сайта db4o (есть версии для Java, .NET 2.0, 3.5). На момент написания статьи последняя версия – 7.9. В дистрибутив также входит Object Manager Enterprise (OME) – полезный плагин для IDE (Eclipse, Visual Studio), который позволяет работать с базой данных автономно. В последнюю продуктивную поставку (на данный момент - 7.4) OME не входит, поэтому для ознакомления c ООСУБД рекомендуется версия 7.9. После установки db4o в соответствующем месте можно найти отличный tutorial, входящий в комплект. Именно к нему я рекомендую обратиться после прочтения данной статьи, если сама тема покажется вам интересной. Отмечаю, что все ПО для работы с db4o и сама СУБД бесплатны для некоммерческого использования. Cоединение с БД Для проведения экспериментов над db4o создаем в нашей IDE проект любого типа, например, консольное приложение и добавляем ссылки на сборки (пакеты) db4o: Db4objects.Db4o.dll и Db4objects.Db4o.Linq.dll (если требуется). Чтобы выполнять какие-либо действия над объектной базой в приложении, первым делом необходимо получить объект типа IObjectContainer . Это фасад к базе данных: через него выполняются запросы к БД на выборку, сохранение, добавление и удаление данных. Способ получения объекта зависит от типа соединения с базой данных. Самый простой способ – база данных размещается в локальном файле, к которому приложение получает доступ напрямую. Делается это так: // получаем доступ к файлу БД IObjectContainer db = Db4oFactory.OpenFile(filename); try { // работаем с ООБД } finally { // закрываем файл, освобождаем ресурсы db.Close(); } Файл базы данных в этом случае открывается в эксклюзивном режиме и, следовательно, возникают трудности при реализации многопользовательских приложений. Однако такое решение отлично подходит для однопользовательских stand-alone приложений, которые имеют сложную модель данных и которым необходимо сохранять эти данные между запусками приложения. Пример, САПР-приложения. Следующий способ. Для поддержки многопользовательского режима, то есть возможности существования нескольких IObjectContainer для одной базы данных одновременно, следует использовать клиент-серверную архитектуру. В случае, когда клиент и сервер работают в рамках одного приложения, это делается так: // создаем сервер IObjectServer server = Db4oFactory.OpenServer(filename, 0); try { // подключаем клиентов IObjectContainer client = server.OpenClient(); IObjectContainer client2 = server.OpenClient(); // работаем с ООБД через экземпляры IObjectContainer Client.Close(); client2.Close(); } finally { // закрываем файл, освобождаем ресурсы сервера server.Close(); } * This source code was highlighted with Source Code Highlighter . В данном случае при создании сервера все равно приходится указывать файл базы данных. Это необходимо делать для всех типов подключения к БД - привязка к файлу остается всегда (один файл - одна БД). Кстати, такой файл создается автоматически по первому требованию, если не был создан до этого. Второй параметр функции OpenServer – номер порта, равный 0, означает, что сервер будет доступен только локальным клиентам, создаваемым с помощью server.OpenClient() . Приведенный пример искусственный. В реальном приложении клиенты, скорее всего, будут открываться в отдельных потоках. И последний вариант – расширение предыдущего для случая удаленных клиентов. // создаем сервер IObjectServer server = Db4oFactory.OpenServer(filename, serverPort); server.GrantAccess(serverUser, serverPassword); try { IObjectContainer client = Db4oFactory.OpenClient("localhost" , serverPort, serverUser, serverPassword); // работаем с ООБД client.Close(); } finally { server.Close(); } * This source code was highlighted with Source Code Highlighter . Этот вариант отличается от предыдущего следующим. Указывается реальное значение порта, который будет прослушивать сервер (используется TCP/IP) при вызове OpenServer . Указываются авторизационные данные для доступа к БД. Клиент создается с использованием Db4oFactory.OpenClient и, таким образом, это может происходить не только в другом потоке, но и совершенно в другом приложении, запущенном на удаленной машине. Итак, мы рассмотрели все три способа подключения к базе данных и научились получать объект типа IObjectContainer . Посмотрим теперь, как работать с данными, используя этот объект. Работа с данными Пусть где-то в нашем приложении объявлен класс User с полями Login , Password и Age , а db – это объект типа IObjectContainer (тот, что мы получили в прошлом разделе). Сохранение объекта (INSERT) User user1 = new User("Vasya", "123456", 25); db.Store(user1); * This source code was highlighted with Source Code Highlighter . Это всё! Не требуется заранее или вручную задавать, какие объекты мы можем сохранять в БД, структуру этих объектов или что-либо ещё. При сохранении первого объекта ООСУБД сделает всю работу за нас. Запросы к данным (SELECT) Существует несколько способов выполнить запрос к данным, сохраненным в базе данных. Применение естественных запросов (Native Queries, NQ) – гибкий, мощный и удобный метод выполнения запросов над данными в ООБД. IList result = db.Query(usr => usr.Age >= 18 && usr.Login.StartsWith("V")); * This source code was highlighted with Source Code Highlighter . Здесь делается запрос к объектам класса User , причем всё, что только можно, в данном примере строго типизировано. Объекты фильтруются таким образом, чтобы удовлетворять условию: возраст пользователя больше или равен 18 и имя пользователя начинается с заглавной буквы «V». Вместо лямбда-выражения функции Query можно передавать делегаты или объекты типа Predicate . Predicate - интерфейс, содержащий единственную функцию Match , принимающую параметр типа T и возвращающую bool . Query вернет те объекты, для которых Match возвращает true . Концепция ООБД отлично ложиться на идею использования интегрированных в язык запросов (LINQ). Перепишем предыдущий запрос с использованием LINQ. IEnumerable result = from User usr in db where usr.Age >= 18 && usr.Login.StartsWith("V" ) select usr; * This source code was highlighted with Source Code Highlighter . Запрос опять же строго типизирован и легко поддается рефакторингу. Существуют и другие методы выполнения запросов, кроме NQ и LINQ. Запросы по образцу (query by example). Самый простой, но недостаточно мощный способ. Выборка данных осуществляется на основе сопоставления с заранее подготовленным экземпляром объекта - образцом. Результат-выборка не является строго типизированной. Сложно представить ситуации, когда этот метод может оказаться полезным. SODA. Низкоуровневый язык запросов, с которым работает db4o. Запросы, использующие синтаксис SODA, не безопасны с точки зрения типов, не строго типизированы, занимают много места, но зато максимально гибки и позволяют отточить производительность приложения там, где это требуется. Обновление объектов (UPDATE) Перед тем как обновить объект, извлечем его из БД, затем изменим его и сохраним обратно. User usr = db.Query(usr => usr.Login == "Vasya" ); usr.SetPassword("111111" ); db.Store(usr); * This source code was highlighted with Source Code Highlighter . Удаление объектов (DELETE) Удаление объектов происходит аналогично: User usr = db.Query(usr => usr.Login == "Vasya" ); db.Delete(usr); * This source code was highlighted with Source Code Highlighter . Составные объекты До этого момента мы рассматривали, как работать с достаточно простыми объектами User , которые содержали только поля элементарных типов (string и int ). Однако объекты могут быть составными и ссылаться на другие объекты. Например, в классе User может быть объявлено поле friends (друзья пользователя): public class User { // ... IList friends = new List (); } * This source code was highlighted with Source Code Highlighter . Все операции с таким классом производятся также, как и раньше – составное поле корректно сохраняется в БД, однако есть некоторые особенности. Допустим, мы пытаемся загрузить из БД объект одного конкретного пользователя (User ), как это делалось в прошлом разделе. Если загружен сам пользователь, то должны загрузиться и его друзья, дальше – друзья его друзей, и так далее. Это может закончиться тем, что придется загрузить в память все объекты User или даже, если у User есть ссылки на объекты других типов, всю базу данных целиком. Естественно, такой эффект нежелателен. Поэтому, по умолчанию загружаются только сами объекты выборки и объекты, на которые они ссылаются, до 5-го уровня вложенности включительно. Для некоторых ситуаций это много, для других – мало. Существует способ настроить этот параметр, называемый глубиной активации (activation depth ). // глубина активации глобально для всех классов db.Ext().Configure().ActivationDepth(2); // глубина активации для класса User db.Ext().Configure().ObjectClass(typeof (User)).MinimumActivationDepth(3); db.Ext().Configure().ObjectClass(typeof (User)).MaximumActivationDepth(4); // каскадная активация для объектов User (нет ограничения на глубину) db.Ext().Configure().ObjectClass(typeof (User)).CascadeOnActivate(true ); * This source code was highlighted with Source Code Highlighter . Здесь приведены примеры, устанавливающие глубину активации как для всех сразу, так и для отдельного класса. Функция Ext() возвращает расширенный объект IExtObjectContainer для доступа к продвинутым функциям вроде настроек конфигурации базы данных. Это сделано для удобства, чтобы не засорять основной интерфейс IObjectContainer . В случае, когда запрос уже отработал, но каких-либо данных не хватает, то есть не все нужные данные были активированы (загружены в память), можно использовать метод Activate , применительно к отдельному хранимому объекту: // первый параметр – активируемый объект, второй – глубина активации db.Activate(usr, 5); * This source code was highlighted with Source Code Highlighter . Во многом похожая проблема возникает при сохранении составных объектов. По умолчанию сохраняются только поля самого объекта, но не объектов, на которые он ссылается. То есть, глубина обновления (update depth ) по умолчанию равна 1. Изменить её можно следующим образом: // глубина обновления глобально для всех классов db.Ext().Configure().UpdateDepth(2); // глубина обновления для класса User db.Ext().Configure().ObjectClass(typeof (User)).UpdateDepth(3); // каскадное обновление для объектов User (нет ограничений на вложенность) db.Ext().Configure().ObjectClass(typeof (User)).CascadeOnUpdate(true ); * This source code was highlighted with Source Code Highlighter . В случае удаления объекта, по умолчанию также не происходит каскадного удаления: объекты, на которые ссылался удаленный объект, остаются. Настраивать поведение СУБД в случае удаления объектов можно следующим образом: // каскадное удаление (нет ограничений на вложенность) db.Ext().Configure().ObjectClass(typeof (User)).CascadeOnDelete(true ); * This source code was highlighted with Source Code Highlighter . Понятия «глубины удаления» не предусмотрено. Транзакции Каждый раз, когда открывается контейнер (IObjectContainer ), неявным образом создается контекст транзакции. При выполнении операции Close автоматически происходит commit текущей транзакции. Для более гибкого управления транзакциями в интерфейсе IObjectContainer присутствуют два метода: Commit() . Явное завершение транзакции (commit) с записью всех изменений в БД. Rollback() . Откат транзакции – изменения произошедшие с момента открытия транзакции (контейнера) не будут зафиксированы в БД. Уровень изоляции транзакций, принятый в db4o - read committed . Заключение Цель данной статьи - показать, что имеется очень мощная альтернатива существующим подходам к разработке с использованием реляционных СУБД. Сам по себе подход, использующий объектные базы данных, очень современен – это СУБД, которая не отстает от основных тенденций, наблюдаемых в развитии языков программирования, таких как Java и C#. ООП Java CSharp LINQ Добавить метки Beeline Интернет Tele2 Полезное IP-Телефония Йота Mts Megafon Контакты Реклама О сайте Поиск Мы можем оповещать вас о новых статьях, чтобы вы всегда были в курсе самого интересного. Продолжить Нет, спасибо