Двенадцать правил Дейта для РСУБД

 

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

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

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

3. Непрерывные операции. Это качество можно трактовать как возможность непрерывного доступа к данным вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах.

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

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

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

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

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

9. Независимость от оборудования. Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей – от мэйнфреймов до “персоналок”.

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

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

12. Независимость распределенной системы от баз данных. Это качество означает, что в распределенной системе могут “мирно сосуществовать” СУБД различных производителей и возможны операции поиска и обновления в базах данных различных моделей и форматов.

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

 

Перспективные направления

 

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

 

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

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

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

• слабое представление сущностей реального мира;

• семантическая перегрузка;

• слабая поддержка ограничений целостности и корпоративных ограничений;

• однородная структура данных;

• ограниченный набор операций;

• проблема рассогласования.

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

Семантическая перегрузка. Как известно, реляционная модель обладает только одной конструкцией для представления дан­ных и связей между данными – отношением. Например, для представления связи типа M:N между двумя сущностями А и В необходимо создать три отношения: два для представления сущностей А и В, а третье – для представления связи. При этом не су­ществует никакого механизма для установления различий между сущностями и связями или между разными типами связей, заданными между сущностями. Если бы подобные различия можно было отразить в схеме, то опера­циям можно было бы придать определенный семантический смысл. Из-за отсутствия по­добных возможностей говорят, что реляционная модель семантически перегружена.

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

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

Ограниченный набор операций. Реляционная модель обладает только фиксированным набором операций, вклю­чающим в себя операции с множествами и кортежами, определенные в спецификации SQL-92, которая не допускает определения новых операций. Это накладывает большие ограничения на моделирование поведения объектов “реального мира”.

Проблема рассогласования. Спецификация SQL-92 не обладает вычисли­тельной полнотой. Для преодоления этой трудности в стандарте SQL предусмотрено использование встроенных SQL-операторов, что упрощает разработку более сложных приложений баз. Однако этот подход приводит к возникно­вению проблемы рассогласования (impedance mismatch), вызванной смешиванием разных парадигм программирования. Во-первых, язык SQL является декларативным языком программирования, который оперирует строками данных, а такой высоко­уровневый язык, как язык С, является процедурным языком программирования, ко­торый может управлять только одной строкой данных за один раз. Во-вторых, язык SQL и языки 3-го поколения используют разные модели представления данных. На­пример, в языке SQL предусмотрены встроенные типы данных Date и Interval, кото­рых нет в традиционных языках программирования. Таким образом, прикладной программе потребуется преобразовать данные между этими двумя представлениями, что неэффективно как в отношении затраченных на программирование усилий, так и в отношении использования вычислительных ресурсов. По некоторым оценкам, доля времени на программирование подобных преобразований и доля объема соответст­вующего кода в приложениях достигают 30%. Более того, из-за использования двух различных типов систем невозможно организовать в автоматиче­ском режиме контроль типов во всем приложении в целом.

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