Расширенная реляционная модель данных и объектно-реляционные СУБД
До недавнего времени выбор типа СУБД ограничивался только реляционными и объектно-реляционными СУБД. Но в настоящее время многие системы не подходят для создания сложных специализированных приложений. Чтобы обеспечить возможность применения реляционных СУБД в этих приложениях, необходимо расширить функциональные возможности существующих систем. Если внимательно рассмотреть новые сложные специализированные приложения баз данных, то можно заметить, что в них широко используются такие объектно-ориентированные компоненты, как расширяемая пользователем система типов, инкапсуляция, наследование, полиморфизм, динамическое связывание методов, использование составных объектов, а также поддержка идентичных объектов. Наиболее очевидный способ преодоления ограничений реляционной модели заключается в ее расширении упомянутыми функциями. Именно этот подход был предпринят во многих прототипах расширенных реляционных систем, хотя в каждой из них реализован свой собственный и отличный от других набор функциональных возможностей. Но не существует какой-то общепринятой расширенной реляционной модели, а скорее имеется несколько таких моделей, характеристики которых зависят от способа и степени реализации внесенных расширений. Однако во всех моделях используются одинаковые базовые реляционные таблицы и язык запросов, включено понятие объекта, а в некоторых дополнительно реализована возможность сохранения методов (или процедур, или триггеров) таким же способом, что и базе данных.
Для систем с расширенной реляционной моделью данных используются самые разные термины. Сначала применялся термин расширенная реляционная СУБД (Extended Relational DBMS - ERDBMS). Однако в последние годы используется более информативный термин объектно-реляционная СУБД, или ОРСУБД (Object-Relational DBMS - ORDBMS), в котором содержится указание на использование понятия объект. Чаще всего используется термин Объектно-реляционная СУБД или ОРСУБД. Три ведущих фирмы в области разработки ОРСУБД, а именно Oracle, Informix, IBM, расширили свои системы до уровня ОРСУБД, хотя их функциональные возможности немного отличаются. Концепция ОРСУБД, как комбинации ООСУБД и РСУБД, очень притягательна за счет применения знаний и опыта, которые были накоплены за время работы с РСУБД. Разработка стандартов в этой сфере построена на расширении стандарта языка SQL.
Основными преимуществами расширенной реляционной модели данных являются повторное и совместное использование компонентов. Например, в приложении может понадобиться использование данных пространственного типа, представляющие собой точки, линии, и многоугольники, со связанными с ними функциями, которые вычисляют расстояние между точками, расстояние между точкой и линией, проверяют наличие точки в многоугольнике и т.д. При правильном проектировании с учетом новых возможностей подобный подход позволяет организациям воспользоваться преимуществами новых расширений эволюционным путем без утраты преимуществ, получаемых от использования компонентов и функций уже существующей базы данных.
Другое очевидное преимущество заключается в том, что расширенный реляционный подход позволяет воспользоваться обширным объемом накопленных знаний и опыта, связанных с разработкой реляционных приложений. Э'ГО очень важное досто инство, поскольку многие организации не хотели бы тратить средства на достаточно дорогой переход к системе нового типа. При правильном проектировании с учетом новых функциональных возможностей подобный подход позволяет организациям воспользоваться преимуществами новых расширений эволюционным путем без утраты преимуществ, получаемых от использования компонентов и функций уже существующей базы данных. Таким образом, переход к ОРСУБД можно организовать в интегрирующем, эволюционном стиле посредством выполнения некоторых пробных и экспериментальных проектов. Будущий стандарт SQL3 проектируется с учетом совместимости снизу вверх с текущим стандартом SQL, а потому любые ОРСУБД, совместимые с SQL3, должны удовлетворять этому условию.
Очевидным недостатком подхода с использованием ОРСУБД являются сложность и связанные с ней повышенные расходы. Простора и ясность, присущая реляционной модели, утрачивается при использовании подобных типов расширения. Некоторые считают, что расширения РСУБД предназначены для незначительного количества приложений, причем в последних не может быть достигнута оптимальная производительность при использовании имеющейся реляционной технологии. И многие другие, вплоть до терминологии.
Сравнение ООСУБД и ОРСУБД
Таблица 1 – Сравнение моделей данных в ОРСУБД и ООСУБД
Функция | ОРСУБД | ООСУБД |
Идентичность объекта | Поддерживается на основе типа REF | Поддерживается |
Инкапсуляция | Поддерживается на основе UDF-типов | Поддерживается, но нарушается для запросов |
Наследование | Поддерживается (отдельные иерархии для UDТ-типов и таблиц) | Поддерживается |
Полиморфизм | Поддерживается (вызов UDF-Функции основе универсальной функциональной модели) | Поддерживается, как в объектно-ориентированном языке программирования |
Составные объекты | Поддерживается на основе UDТ-типов | Поддерживается |
Связи | Строгая поддержка на основе пользовательских ограничений целостности | Поддерживается (например, с помощью библиотек классов) |
Таблица 2 – Сравнение методов доступа к данным в ОРСУБД и ООСУБД
Функция | ОРСУБД | ООСУБД |
Создание перманентных данных и доступ к ним | Поддерживается, но не прозрачно | Поддерживается, но степень прозрачности варьируется для разных продуктов |
Произвольные запросы | Строгая поддержка | Поддерживается на основе стандарта ODMG 2.0 |
Навигация | Поддерживается на основе типа REF | Строгая поддержка |
Ограничения целостности | Строгая поддержка | Не предусмотрены |
Сервер объектов/сервер страниц | Сервер объектов | Оба |
Эволюция схемы | Ограниченная поддержка | Поддерживается, но степень поддержки варьируется для разных продуктов |
Таблица 3 – Сравнение способов совместного использования данных