Двенадцать правил дейта для рсубд

      Комментарии к записи Двенадцать правил дейта для рсубд отключены

К. Дж. Дейтом было сформулировано 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%. Более того, из-за использования двух различных типов систем невозможно организовать в автоматическом режиме контроль типов во всем приложении в целом.

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

Статьи к прочтению:

Twelve


Похожие статьи:

  • Правила поведения на сцене для вокалистов

    1. Не направляйте микрофон в сторону мониторных акустических систем. 2. Не зажимайте руками предохранительную сетку и акустические отверстия микрофона….

  • Для студентов заочного отделения

    ЗАДАНИЕ по подготовке реферата и презентации 1. По указанной теме (по номеру в списке группы) найти материал (12-15 страниц) в интернет-источниках. 2….