Основные понятия базы данных и систем управления базами данных

2.2. Постреляционные  базы данных

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

Первое направление  связано с максимальным использованием существующих технологий управления и организации реляционных СУБД с дальнейшим совершенствованием систем управления внешней памятью.

Второе направление  связано с созданием генераторов  системы управления в виде наборов  модулей со стандартизованными интерфейсами.

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

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

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

Системы управления базами данных, в которых формируются  такие сложные объекты, называют объектно-ориентированными базами данных (ООБД).

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

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

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

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

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

Такие инструментальные средства, обеспечивающие автоматизацию  построения компиляторов имеются, например, в системах DB2, Oracle, Informix.

Общие понятия объектно-ориентированного подхода:

Направление объектно-ориентированных баз данных появлялось в середине 1980-х гг. Наиболее активно это направление развивается в последние годы.

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

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

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

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

В наиболее общей постановке объектно-ориентированный подход базируется на концепциях:

− объекта и идентификатора объекта;

− атрибутов и методов;

− классов;

− иерархии и наследования классов.

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

Каждый объект имеет  состояние и поведение. Состояние  объекта – набор значений его  атрибутов. Поведение объекта –  набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта – это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействуют объекты на основе передачи сообщений и выполнения соответствующих методов.

Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.[9., стр. 230-240]

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

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

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

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

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

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

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

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

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

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

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

Второй аспект – потребность  в механизме определения разного рода семантических связей между объектами разных классов. Фактически это означает требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи с использованием ООБД в сфере автоматизированного проектирования и инженерии.[4., стр.230]

Третий аспект связан с пересмотром понятия класса. В контексте ООБД оказывается  более удобным рассматривать  класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа, и класса объектов.

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

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

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

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