На следующем этапе каноническая структура преобразуется в логическую структуру баз данных, которая учитывает ограничения выбранной СУБД. Рассмотрим особенности построения логических структур для объектно-ориентированных и реляционных СУБД.
Известно, что реляционные базы данных представляют собой множество двумерных таблиц и отношений между ними, задаваемых структурой внешних ключей. Каноническая структура часто содержит сложные объекты и связи - как межобъектные, так и внутриобъектные (сложные типы данных). Поэтому процесс проектирования логических структур баз данных реляционного типа сводится к следующей последовательности операций: анализ предметной области и выделение базовых типов сущностей, нормализация типов сущностей и формирование логических записей, установление связей между записями.
Несмотря на формальную строгость методов проектирования реляционных баз данных, им присущ ряд недостатков. При построении информационных систем, использующих большое число информационных элементов, логические структуры БД для данных систем ввиду многочисленных многозначных зависимостей между данными могут состоять из десятков и даже сотен таблиц, что делает такие БД плохо обозримыми и управляемыми. Более того, за счет разбиения объектов предметной области на плоские нормализованные отношения теряется семантика исследуемой предметной области, что усложняет сопровождение и модернизацию систем. Данные методы не позволяют также адекватно моделировать отдельные свойства данных.
Для адекватного моделирования сложных структур данных проектировщик должен иметь возможность определять свои типы данных, не ограничиваясь теми данными, которые предоставляются определенной реляционной СУБД. Реляционная модель не позволяет также определить набор операций, связанных с данными определенного типа, что часто является естественным требованием при моделировании объектов предметной области. Операции приходится задавать в конкретном приложении. Поэтому использование таких методов проектирования требует высокой квалификации проектировщиков.
В основе объектно-ориентированного подхода к моделированию предметных областей лежат такие понятия, как объект и свойства инкапсуляции, наследования и полиморфизма.
· Свойство инкапсуляции означает, что объекты имеют некоторую структуру и определенный набор операций, т.е. поведение. Внутренняя структура объекта скрыта от пользователя. Манипулирование объектом, изменение его состояния возможны лишь с помощью специальных методов, определяемых заданным набором операций.
· Свойство наследования позволяет создавать из объектов новые объекты. Они наследуют структуру и поведение своих предшественников, к которым добавляются характеристики, отражающие их индивидуальность.
· Свойство полиморфизма означает, что различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному - в зависимости от того, каким образом в них реализованы методы реакции на сообщения.
Объектно-ориентированные технологии обеспечивают естественный переход от концептуальной структуры БД к логической структуре БД. В отличие от реляционных БД при проектировании объектно-ориентированных БД (ООБД) не требуется декомпозиция и нормализация объектов, выделенных на этапе концептуального проектирования. Объекты представляются в том же виде, что наделяет объектно-ориентированные структуры наглядностью и прозрачностью и позволяет значительно сократить время на их разработку и повысить степень преемственности. ООБД определяют возможность создания и использования сложных типов данных. При этом не требуется модификации ядра ООБД и для создания нового типа необходимо унаследовать характеристики любого имеющегося типа, наиболее подходящего по своему поведению и состоянию, расширить недостающие операции и атрибуты и переопределить уже имеющиеся. Полученные объектно-ориентированные структуры обладают высокой степенью модульности, что позволяет вносить в них изменения наиболее простым и безболезненным способом. При этом изменения влияют на один класс (или связанную подсистему классов) и могут эффективно управляться и проверяться. Развитые объектно-ориентированные СУБД содержат эффективные интерфейсы интеграции с известными инструментальными средствами проектирования, обеспечивающие автоматическую генерацию логической структуры и ее загрузку в ООБД. Например, СУБД Cache от компании InterSystems содержит интерфейс RoseLink, обеспечивающий тесную интеграцию с продуктом Rational Rose.
Рассмотрим этап разработки. Все множество запросов пользователей к БД можно разделить на два класса - множество запросов на модификацию данных и множество запросов на выборку данных. На этом этапе сложно сказать, какая структура - объектная или реляционная - наиболее предпочтительна. Простой, в то же время крайне эффективный и стандартизированный язык SQL обеспечивает наиболее удобные на данный момент механизмы для выборки и анализа данных и значительно превосходит по возможностям и удобству использования другие языки выборки и анализа данных. С другой стороны, объектно-ориентированные БД за счет поддержки сложных типов данных и отношений, механизмов свизлинга и двухэтапной фиксации данных предоставляют более развитые в сравнении с реляционными БД средства для работы с отдельными записями в БД. В отдельный класс запросов пользователей следует вынести задачи, связанные с массовой загрузкой, выгрузкой и обработкой данных. Данные задачи обычно выполняются в эксклюзивном режиме и часто требуют максимальной скорости выполнения. Известно, что максимальную скорость при работе с большими объемами данных обеспечивают иерархические базы данных. Таким образом, можно сделать вывод, что на этапе разработки выгодно использовать сразу три способа работы с данными. Что же делать? Создавать различные БД под управлением различных СУБД и регулярно их синхронизировать? Дорогое и очень сомнительное решение...
Последний этап - это этап развития системы. Безусловным лидером по удобству и скорости является объектный подход, который за счет реализации принципов наследования и полиморфизма обеспечивает наиболее простой и эффективный способ адаптации схемы БД в условиях изменяющихся требований пользователей.
Приведенный анализ наглядно демонстрирует неэффективность "чистых" СУБД (будь то реляционные или объектно-ориентированные СУБД) для построения БД, входящих в состав современных информационных систем. Так, на этапах проектирования (концептуального и логического), сопровождения и развития целесообразно использовать объектно-ориентированные технологии. На этапе разработки для реализации задач выборки и анализа данных - SQL, для работы с отдельными записями в БД - объекты, для массовой обработки данных - иерархические массивы.
В этой связи все большую популярность приобретают гибридные или постреляционные СУБД, которые реализуют сразу несколько моделей данных в рамках единого хранилища данных, а наиболее развитые - и в рамках единого хранилища метаданных.
На рынке представлено несколько гибридных СУБД от разных поставщиков. Условно их можно разделить на два класса. К первому относятся реляционно-объектные (объектно-реляционные) СУБД, в которых имеется объектная или реляционная надстройка над соответственно реляционной или объектной моделью данных. Эту модель активно продвигают традиционные поставщики реляционных СУБД.
Второй класс - постреляционные СУБД. Они не строятся ни на реляционной, ни на объектной модели, однако также позволяют представлять хранимые данные в виде как реляционных таблиц, так и классов объектов. К этому классу СУБД относится и СУБД Cache от компании InterSystems.
Обоим типам гибридных систем свойственны ненормализованная модель данных, инкапсулированная семантика приложений и множество внешних интерфейсов - как объектных, так и реляционных. Рассмотрим их особенности.
Объектная или реляционная надстройка над существующим ядром системы позволяет обойти часть ограничений, присущих ядру. Однако в этом случае складывается многоуровневая архитектура (рис.), что отрицательно влияет на производительность надстроек и утяжеляет само ядро системы. Кроме того, такая надстройка в большинстве случаев ограничена и не соответствует стандартам на реализацию модели (SQL92, SQL99) или рекомендациям комитетов по стандартизации (ODMG).
Сравнение Сache и реляционно-объектных архитектур
Ядро постреляционных СУБД не использует ни реляционную, ни объектную схему - обычно оно построено на базе сетевой или иерархической модели. Зачем это делается? Известно, что реализации сетевой и в особенности иерархической модели БД отличаются высокой скоростью работы с данными и простотой масштабируемости. При этом гибкость языковой среды иерархических БД позволяет весьма эффективно воплощать ту или иную модель данных. Именно поэтому многие специалисты рекомендуют использовать иерархическую СУБД в качестве основы даже для "чистых" реляционных и объектных СУБД. Для работы с данными в постреляционных СУБД применяются механизмы, которые представляют массивы данных иерархического или сетевого ядра системы в виде классов объектов и реляционных таблиц и обеспечивают необходимые механизмы (например, встроенные языки третьего поколения или интерфейсы к внешним инструментариям) для работы с ними.
Основное отличие и преимущество постреляционных СУБД в сравнении с реляционно-объектными СУБД состоит в том, что в постреляционных СУБД механизмы работы с объектами и реляционными таблицами находятся на одном логическом уровне, что обеспечивает более высокую скорость доступа и работы с данными, функциональную полноту, в т.ч. соответствие определенным стандартам и спецификациям.