Объектные СУБД

Основные данные о работе

Содержание

Введение

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

В настоящее время еще не принят единый стандарт для разработки объектных СУБД.

Цель данной курсовой работы – рассмотреть теоретические аспекты проектирования объектных баз данных.

Для достижения цели курсовой работы поставлены следующие задачи:

• Подобрать и изучить литературу по данной теме;
• Исследовать состояние и разработанность данной темы;

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

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

В третьей главе приводится обзор по объектно-реляционным СУБД. Рассматриваются объектно-реляционные методы.

Основная часть

1. Общие понятия объектных СУБД

1.1Причины возникновения объектных СУБД

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

• Автоматизированное проектирование.
• Автоматизированное производство.
• Автоматизированная разработка программного обеспечения.
• Офисные информационные системы и мультимедийные системы.
• Цифровое издательское дело.
• Геоинформационные системы.
• Интерактивные и динамические Web-узлы.

Такие проекты имеют следующие общие характеристики:

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

*    Проекты могут быть  очень большими,  вполне вероятно, включающими миллионы элементов, часто со многими взаимозависимыми проектами подсистем.

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

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

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

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

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

1.2. Недостатки реляционных СУБД

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

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

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

Семантическая перегрузка. Реляционная модель обладает только одной конструкцией для представления данных и связей между данными — отношением. Например, для представления связи "многие ко многим"  между двумя сущностями А и В необходимо создать три отношения: два для представления сущностей А и В, а третье — для представления связи. При этом не существует никакого механизма установления различий между сущностями и связями или между разными типами связей, заданными между сущностями. Например, связь "один ко многим" может иметь разный смысл: Has (имеет). Owns (владеет), Manages (управляет) и т.д. Если бы была возможность отразить подобные различия в схеме, то операциям можно было придать определенный смысл. Из-за отсутствия подобных возможностей  говорят,   что  реляционная  модель  семантически  перегружена.

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

Однородная структура данных. Реляционная модель предполагает как горизонтальную, так и вертикальную однородность данных. Горизонтальная однородность данных означает, что каждая строка отношения должна состоять из одинаковых атрибутов, А вертикальная однородность означает, что значения в некотором столбце отношения должны принадлежать к одному и тому же домену. Более того, на пересечении строки и столбца должно находиться элементарное значение. Эта фиксированная структура является слишком жесткой и недостаточной для представления многих объектов "реального мира" со слишком сложной структурой, что приводит к неестественным соединениям, которые, как уже упоминалось выше, весьма неэффективны.

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

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

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

Проблема рассогласования типов данных. Спецификация SQL-92 не обладает вычислительной полнотой. Это утверждение остается справедливым по отношению к большинству языков манипулирования данными (DML— Data Manipulation Language) для реляционных СУБД. Для преодоления этой трудности и предоставления дополнительных возможностей в стандарте SQL предусмотрено использование встроенных операторов SQL, что упрощает разработку более сложных приложений баз данных. Однако этот подход приводит к возникновению проблемы рассогласования типов данных (impedance mismatch), вызванной столкновением разных принципов программирования, которые описаны ниже.

•    Язык SQL является декларативным языком программирования, который оперирует сразу несколькими строками данных, а такой высокоуровневый язык, как С, является процедурным языком программирования, который может управлять только одной строкой данных.

•    В SQL и языках третьего поколения используются разные модели представления данных. Например, в SQL предусмотрены встроенные типы данных, которых нет в традиционных языках программировании. Таким образом, прикладной программе потребуется преобразовать данные между этими двумя представлениями, что неэффективно как в отношении затраченных на программирование усилий, так и в отношении использования вычислительных ресурсов. По некоторым оценкам, доля времени на программирование подобных преобразований и доля объема соответствующего кода в приложениях достигает 30% . Более того, из-за использования систем двух различных типов невозможно организовать в автоматическом режиме контроль типов во всем приложении в целом.

Другие проблемы реляционных СУБД

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