Интенсивное расширение компьютерной инфотехнологии ставит перед дальнейшим развитием СУБД целый ряд новых требований, во многом связанных с вопросами стандартизации. Это относится не только к СУБД, но и к ПС других типов. В отношении же СУБД это прежде всего относится к стандартизации эталонной модели управления данными, предусматривающей четкую классификацию основных вопросов стандартизации СУБД в зависимости от функциональных особенностей и уровня описания данных на разных стадиях проектирования. Можно предполагать, что последующее развитие СУБД будет ориентироваться на рекомендации международных стандартов относительно языков БД и средств доступа к удаленным БД, а также интерфейсов с системами программирования. Новые интересные аспекты БД-технологии появляются на основе объектно-ориентированной технологии программирования и обработки информации.
В настоящем параграфе рассматриваются основные концепции, понятия, черты и характеристики объектно-ориентированных систем управления БД (ООСУБД) в контексте рассмотренных объектно-ориентированных программирования и технологии. В последние годы в результате проникновения идеологии ООП в СУБД интенсивные разработки теоретического и прикладного характера ведутся по созданию различного назначения ООСУБД. Ввиду не совсем устоявшейся в этом направлении терминологии отметим основные черты и характеристики, определяющие СУБД как объектно-ориентированную. При этом по мере необходимости проводятся сопоставления с рассмотренной выше концепцией ООП.
Характеристики ООСУБД подразделяются на три определяющие группы:
— базовые, определяющие принадлежность СУБД к объектно-ориентированному классу;
— по выбору, позволяющие улучшать ООСУБД, но не являющиеся базовыми;
— открытости, позволяющие пользователю делать осознанный выбор из ряда одинаково приемлемых реализаций ООСУБД.
В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД в ее классическом понимании и быть объектно-ориентированной системой (ООС), т.е. в определенной степени она должна быть совместимой с современными объектно-ориентированными ЯВУ. Первый критерий включает следующие пять характеристик, присущих классической СУБД: сохранность данных, развитое управление внешней памятью, возможность совмещения обработки и поиска данных, поддержка средств восстановления и возможность быстрого доступа к БД по запросу пользователя. Отмеченные характеристики в той или иной мере обсуждались выше. Второй критерий предполагает наличие следующих характеристик, присущих собственно объектно - ориентированной технологии: понятие сложных объектов, идентичность объектов, инкапсуляция, типы или классы, наследование, настройка (сочетающаяся с отложенным присвоением), расширяемость и вычислительная полнота. Характеристики первого критерия хорошо известны пользователям традиционных СУБД (dBase, R-Base, др.)
Сложные объекты строятся из более простых путем применения к ним конструкторов. В качестве простых используются такие объекты. как: целые и действительные числа, символы, символьные строки любой длины, булевы величины и, возможно, другие первичные типы. В качестве конструкторов сложных объектов (объектных конструкторов) могут выступать: кортежи, множества, списки, массивы, таблицы и др. В качестве минимального набора объектных конструкторов от ОООСУБД определяются: множество, кортеж, список или массив. Множество дает естественную возможность представления определенного набора объектов из имеющейся обширной совокупности; тогда как кортеж позволяет представлять определенные свойства объекта. При этом кортежи и множества имеют особое значение, получив широкое применение в качестве объектных конструкторов в реляционных БД (РБД) Список или массив играют важную роль при установлении порядка среди элементов множества. Более того, указанные типы объектных конструкторов играют важную роль во многих приложениях (векторно-матричные задачи, задачи анализа временных рядов и др.).
Объектные конструкторы должны удовлетворять принципу ортогональности: любой конструктор может применяться к любому объекту. Например, конструкторы РБД не обладают данным свойством (так конструктор множества может применяться только к кортежам, а конструктор кортежей — только к первичным типам).
Дерево представляет собой иерархию элементов, называемую узлами. На самом верхнем уровне иерархии имеется только один узел - корень. Каждый узел, кроме корня, связан с одним узлом на более высоком уровне, называемым исходным узлом для данного узла. Ни один элемент не имеет более одного исходного. Каждый элемент может быть связан с одним или нескольким элементами на более низком уровне. Они называются порожденными. Иерархические структуры относительно просто создаются и поддерживаются. Это важно для ряда приложений, однако множество данных по своей природе не связаны в древовидные структуры. Во многих структурах данных одна запись требует более одного представления (поэтому приходится разрабатывать способы объединения данных, которые по разному представляются различным пользователям, в одну общую схему БД. В результате получаются обычно более сложные структуры по сравнению с древовидными. Поэтому программное обеспечение, сконструированное только для работы с древовидными структурами, имеет ограниченное применение и не редко сильно влияет на возможности увеличения объема и развития БД.
Принципиальным для иерархического представления данных является то, что каждый экземпляр записи приобретает свой смысл только тогда, когда он рассматривается в своем контексте; подчиненный экземпляр записи не может существовать без своего предшественника по иерархии (несимметричность или асимметрия). Асимметрия - основной недостаток иерархического подхода, поскольку она затрудняет работу пользователя. В частности, пользователь вынужден тратить время и усилия на решение проблем, связанных со спецификой модели и никак не следующих из характера задаваемых вопросов. Очевидно, что такие проблемы усугубляются по мере увеличения числа типов записей, представленных в структуре, и по мере роста сложности иерархии. Кроме того, иерархическая модель обладает еще некоторыми нежелательными свойствами аномалии, которые ярко проявляются в связи с выполнением каждой из основных операций запоминания (добавление, удаление, модификация).
Длительный опыт использования иерархических систем показал, что они весьма эффективны лишь для достаточно простых задач, но они практически не пригодны для использования в сложных системах с оперативной обработкой транзакций и распределенной архитектурой. Иерархическая организация не может обеспечить быстродействие, необходимое для работы в условиях одновременного модифицирования файлов несколькими прикладными подсистемами.
Окружающий мир переполнен иерархическими данными. В это широкое понятие входят компании, состоящие из дочерних компаний, филиалов, отделов и рабочих групп; детали из которых собираются узлы, входящие затем в механизмы; специальности, специализации и рабочие навыки; начальники и подчинённые и т. д. Любая группа объектов, в которой один объект может быть «родителем» для произвольного числа других объектов, организована в виде иерархического дерева. Очевидным примером может послужить иерархия объектов VCL- класс TEdit представляет частный случай TСontrol, потому что TСontrol является его предком. С другой стороны, TEdit можно рассматривать и как потомка TWinControl или TCustomControl, потому что эти классы являются промежуточными уровнями иерархии VCL.
Подобные связи не имеют интуитивного представления в рамках модели реляционных баз данных. Нередко иерархические связи являются рекурсивными (поскольку любая запись может принадлежать любой записи) и произвольными (любая запись может принадлежать другой записи независимо от того, кому принадлежит последняя). В двумерной таблице даже отображение иерархического дерева становится непростым делом, не говоря уже о запросах. Иногда в критерий запроса входит родословная объекта (то есть его родители, родители его родителей и т д.) или его потомство (сюда входят дочерние объекты и всё их потомство).
Термин «рекурсивные иерархические данные» означает, что базовые и подчинённые данные находятся в одной таблице: одно не ключевое поле записи содержит ключевое значение другой записи, и это означает, что вторая запись принадлежит первой. Не ключевое поле называется внешним ключом, даже если по нему устанавливается связь с другим полем этой же таблицы. Дочерние, подчинённые записи не знают, является ли их базовая запись подчинённой для какой-то другой записи - для них это несущественно. Каждый уровень обладает своим набором базовых и подчинённых записей, и при «раскрытии» конкретной подчинённой записи изменяются только конкретные отображаемые данные.