Для решения поставленной задачи необходимо, чтобы компонент базы данных (КБД) обладал следующим особенностями:
1. КБД содержит только те данные, которые уникальны для связанной с ним версии.
2. Остальные данные, общие для нескольких версий, предоставляются редактирующему данный КБД пользователю из других компонентов.
3. Для этого компоненты образуют иерархическую структуру, в которой каждый нижестоящий КБД может иметь доступ к данным вышестоящего, которые могут быть изменены, удалены и расширены новыми данными.
4. При удалении данных КБД происходит проверка (и восстановление) ссылочной целостности не только для него, но и для всех нижестоящих компонентов.
Перечисленные особенности (по крайней мере, первые три) обнаруживают сильное сходство МКБД с объектно-ориентированным подходом, применяющимся, в частности, при разработке современного программного обеспечения. Анализ применимости понятий объектно-ориентированного программирования (ООП) к потребностям баз данных (см. раздел 4.2.1) позволяет ещё более расширить возможности МКБД. В частности, из ООП в МКБД можно перенести понятие абстрактных данных, которое оказывается очень полезным при создании версий БД (хотя его не имеет смысла рассматривать в задачах о хранении временной последовательности состояний БД).
Следует заметить, что объектно-ориентированные базы данных (ООБД) не имеют никакого отношения к проблемам, решаемым с помощью МКБД. В ООБД основное внимание уделяется проблеме хранения данных сложных типов (классов, абстрактных типов) вместе с привязанными к данным методами их обработки; этим расширяются возможности реляционных баз данных (РБД), которые имеют дело с данными простых (предопределённых) типов. Многокомпонентный же подход к базам данных ничего не предполагает о типах данных: если данные имеют достаточно сложную структуру, имеет смысл хранить их в соответствии с объектно-ориентированной моделью, если относительно простую – можно пользоваться преимуществами реляционной модели. Другими словами, МКБД может являться РБД, ООБД или ОРБД, лишь бы соответствующие структуры данных существовали там в нескольких экземплярах (компонентах), иерархически связанных между собой. Поскольку упорядочение данных на уровне компонентов не имеет отношения к их организации на более низком уровне, систему управления многокомпонентными базами данных имеет смысл реализовывать как надстройку над существующими СУБД.
Суть многокомпонентных баз данных, их свойства и преимущества по сравнению с однокомпонентными приведены в таблице 4.2, вместе с аналогичными утверждениями объектно-ориентированного программирования. В таблице 4.3 перечислены основные термины МКБД и аналогичные им термины ООП.
Таблица 4.2
Сравнение МКБД с объектно-ориентированным подходом.
| Содержание объектно-ориентированного подхода | Содержание многокомпонентного подхода к проектированию БД |
| Суть ООП состоит в следующем: 1. Программа представляет собой совокупность объектов, объединяющих данные и методы их обработки. 1.1. Смысл объекта (поведение) отделён от его реализации (структуры) за счёт того, что методы могут не содержать кода, а данные имеют определённую область видимости. 1.2. Данные объектов (поля) также могут быть объектами. 2. Каждый объект относится к определённому типу (классу), т.е. является его экземпляром. 3. Тип (класс) может наследовать часть данных и методов от других типов (классов), то есть быть их подтипом. Примечание к пункту 1.2: в одном и том же поле могут храниться объекты определённого типа и всех его подтипов. | Суть МКБД состоит в следующем: 1. База данных представляет собой совокупность компонентов (КБД), каждый из которых объединяет набор таблиц, а точнее – набор групп таблиц (документов). 1.1. Смысл КБД (структура, поведение здесь ни при чём) отделён от его реализации (от количественного наполнения, структура здесь ни при чём) за счёт того, что данные могут быть абстрактными (неполными и/или несамодостаточными) и могут иметь определённую область видимости. 2. Каждый КБД имеет определённую схему, состоящую из схем документов, а те, в свою очередь – из схем отдельных таблиц. 3. КБД может наследовать часть данных от других КБД, то есть быть их подкомпонентом |
| Примечание к пункту 1. Об объединении данных и методов в МКБД (в отличие от ООП) говорить не имеет смысла, поскольку методы являются данными. Активные БД, в которых методы привязаны к данным, здесь можно упоминать только в связи с частным типом данных – с данными об алгоритмах, без которых обычно не обходится создание систем, требующих МКБД, но это не относится к теме данной работы. Примечание к пункту 1.2. Данные компонентов (документы, таблицы) не могут быть компонентами (в отличие от ООП, где данные объектов могут быть объектами), поскольку у всех компонентов примерно одинаковая схема, её можно только сужать. Примечание к пункту 2. Схема не есть полный аналог класса (типа): в отличие от ООП, у разных КБД одна и та же схема может оказаться лишь чисто случайно, хотя созданию однотипных КБД существенно способствует фиксированный набор схем документов, из которых может состоять схема КБД. Примечание к пункту 3. Наследование в МКБД принципиально отличается от ООП, согласно которому наследоваться должны схемы, а не сами компоненты, причём наследование всегда должно приводить к расширению. | |
| Выделяются следующие свойства ООП: 1. Абстракция – выделение общих черт сходных объектов в абстрактную сущность – класс, а также отделение реализации методов класса от внешнего интерфейса (протокола, контрактных обязательств) этого класса. 2. Инкапсуляция – отделение внутреннего устройства объектов (структур данных и вспомогательных операций с ними) от поведения этих объектов (от методов, входящих в интерфейс). 3. Иерархичность – упорядочение объектов с помощью некоторых отношений. 3.1. Агрегация – связывание объектов на основе отношения включения («быть частью / состоять из»). 3.2. Наследование – расположение классов объектов по уровням с помощью отношения специализации («быть разновидностью / быть обобщением»). 3.2.1. Одиночное наследование – наследование, при котором класс имеет только один родительский класс (суперкласс). 3.2.2. Множественное наследование – наследование, при котором класс может иметь несколько суперклассов (строго говоря, схема отношений классов при множественном наследовании имеет уже не иерархическую, а сетевую структуру). 4. Типизация – способ защититься от использования объектов одного типа вместо другого (например, путём вызова у объекта тех методов, которых его класс не имеет). С типизацией связан полиморфизм – переопределение методов в разных классах одного типа. 5. Параллелизм – поддержка одновременного выполнения нескольких процессов, возможная благодаря чёткому разделению программы на отдельные объекты. 6. Сохраняемость – способность объекта существовать во времени (независимо от породившего его процесса) и/или в пространстве (перемещаясь с одного адреса на другой). Примечание: свойства 1-3 являются обязательными для любой объектно-ориентированной системе, в то время как свойства 4-6 поддерживаются не всеми объектно-ориентированными языками программирования. | Выделяются следующие свойства МКБД: 1. Абстракция – проявляется не в выделении общих черт сходных экземпляров КБД в абстрактную сущность – схему КБД: более или менее абстрактными являются сами экземпляры, каждый из которых в отдельности обычно имеет лишь часть данных, необходимых для работы системы. 2. Инкапсуляция (необязательное свойство) – проявляется в наличии различных областей видимости данных (документов), однако это служит не для отделения внутреннего устройства КБД от их внешнего поведения, а для удобства разделения работы над БД. 3. Иерархичность – упорядочение КБД с помощью некоторых отношений. 3.1. Агрегация – отсутствует. 3.2. Наследование – расположение КБД по уровням с помощью отношения наполнения (доработки) («быть реализацией / быть структурой»). 3.2.1. Одиночное наследование – наследование, при котором КБД имеет один родительский КБД (суперкомпонент). 3.2.2. Множественное наследование – имеет сомнительный смысл, а реализация затруднительна в связи с противоречащими данными суперкомпонентов. 4. Типизация – очень сильная, поскольку в рамках каждой схемы БД свобода выбора типа компонента ограничена числом комбинаций из документов схемы. 5. Полиморфизм – переопределение данных компонентов (а не методов, как в ООП!) в их подкомпонентах. 6. Параллелизм – говорить об этом не имеет смысла, поскольку БД сама по себе статична, (хотя использовать параллельно несколько КБД удобнее, чем несколько стандартных экземпляров БД). Параллелизм в БД может означать параллельную работу нескольких пользователей над разными КБД одной БД. 7. Сохраняемость – свойство, очевидное для любых БД. Примечание: таким образом, основными «объектно-ориентированными» свойствами МКБД являются абстракция (как неполнота и как несамодостаточность), наследование и полиморфизм компонентов. |
| ООП имеет следующие преимущества перед другими подходами: 1) компактность программ, уменьшающая их стоимость и время их разработки; 2) возможность повторного использования классов, программ и целых проектов; 3) эффективное разделение работы между дизайнерами и программистами; 4) быстрая адаптация программ к изменяющимся задачам и требованиям; 5) уменьшение риска разработки сложных программ за счёт интеграции и тестирования их компонентов на протяжении всего времени разработки, а не на последнем её этапе. 6) ориентация на человеческое восприятие мира, позволяющая программировать даже без понимания деталей работы компьютера. | Многокомпонентные БД имеют следующие преимущества перед однокомпонентными: 1) компактность БД (размер которой зависит от числа её версий менее чем линейно), это уменьшает стоимость БД и повышает скорость наполнения её данными; 2) возможность повторного использования даже полных иерархий КБД; 3) эффективное разделение работы по заполнению различных по смыслу КБД; 4) быстрая адаптация версий БД (одновременно большого их числа) к изменению данных, и даже их схемы; 5) уменьшение риска разработки сложных БД за счёт интеграции и тестирования их частей на протяжении всего времени разработки, а не на последнем её этапе. |
Таблица 4.3