4.10.Как определить степень соответствия СУБД реляционной модели.
Заврешая обсуждение моделей данных подведем некоторые итоги. Преимущества реляционного
подхода достаточно очевидны:
- Предсказуемость результатов работы с данными. В основе реляционной модели лежит
математическая модель, следовательно, любой запрос к базе данных, составленный на
корректном языке влечет ответ, однозначно определяемый схемой БД и конкретными
данными. При этом пользователю не требуется информация о физической организации
данных.
- Предметная область часто достаточно естественно описывается в терминах таблиц
(к сожалению, в реляционной модели имеются проблемы с представлением иерархических
структур, подробнее см. раздел 5.5.3.
По этим причинам идея создания реляционной СУБД стала популярна среди разработчиков вскоре
после ее появления. Сейчас существует множество коммерческих и некоммерческих
систем, создатели которых заявляют об их "реляционности". Для того, чтобы более определенно
сформулировать цель, к которой разработчикам нужно стремится, Е.Кодд в конце 70-х годов
опубликовал 12 правил соответствия реляционной модели, которые опираются на
основное (подразумеваемое) правило:
Система, которая провозглашается поставщиком как реляционная СУБД,
должна управлять базами данных исключительно способами, соответствующими реляционной модели.
Конкретные требования к реляционной СУБД раскрываются в следующих правилах (цитируется по статье
В.Пржиялковский Модели, базы данных и СУБД
в информационных системах):
- Информационное правило. Вся информация, хранимая в базе данных, должна быть
представлена единственным образом: в виде значений в реляционных таблицах.
- Правило гарантированного логического доступа. К каждому имеющемуся в
реляционной базе атомарному значению должне быть гарантирован доступ с помощью
указания имени таблицы, значения первичного ключа и имени атрибута.
- Правило наличия значения (missing information). В полностью реляционной СУБД
должны иметься специальные индикаторы (отличные от пустой символьной строки или строки
из одних пробелов и отличные от нуля или какого-то другого числового значения) для
выражения (на логическом уровне, не зависимо от типа данных) того факта, что
значение отсутствует по меньшей мере по двум различным причинам: его действительно нет,
либо оно не применимо к данной позиции. СУБД должна не только отражать этот факт, но
и распространять на такие индикаторы свои функции манипулирования данными не зависимо
от типа данных.
- Правило динамического диалогового реляционного какталога. Описание базы данных
выглядит логически как обычные данные, так что авторизованные пользователи и прикладные
программы могут употреблять для работы с этим описанием тот же реляционный язык, что и
при работе с обычными данными.
- Правило полноты языка работы с данными. Сколько бы много в СУБД ни поддерживалось
языков и режимов работы с данными, должен иметься по крайней мере один язык, выразимый
в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:
- определение данных
- определение правил целостности
- манипулирование данными (в диалоге и из программы)
- определение таблиц-представлений (в том числе и возможности их модификации)
- определение правил авторизации
- границы транзакций
- Правило модификации таблиц-представлений. В СУБД должен существовать корректный
алгоритм, позволяющий автоматически для каждой таблицы-представления определять во
время ее создания, может ли она использоваться для вставки и удаления строк и какие из
столбцов допускают модификацию, и заносящий полученную таким образом информацию в
системный каталог.
- Правило множественности операций. Возможность оперирования базовыми таблицами или
таблицами-представлениями распространяется полностью не только на выдачу информации из БД,
но и на вставку, модификацию и удаление данных.
- Правило физической независимости. Диалоговые операторы и прикладные программы
на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении
данных или методах доступа СУБД
- Правило логической независимости. Диалоговые операторы и прикладные программы
на логическом уровне не должны страдать от таких изменений в базовых таблицах, которые
сохраняют информацию и теоретически допускают неизменность этих операторов и программ.
- Правило сохранения целостности. Диалоговые операторы и прикладные программы не
должны изменяться при изменении правил целостности в БД, задаваемых языком работы с
данными и хранимых в системном каталоге.
- Правило независимости от распределенности. Диалоговые операторы и прикладные
программы на логическом уровне не должны зависеть от совершаемого физического
разнесения данных (если первоначально СУБД работала с нераспределенными данными) или
перераспределения (если СУБД распределенная).
- Правило ненарушения реляционного языка. Если в реляционной СУБД имеется язык
низкого уровня (для работы с отдельными строками), он не должен позволять нарушать
или "обходить" правила, сформулированные на языке высокого уровня (множественном) и
занесенные в системный каталог.
Следующая глава: 5.Проектирование реляционных баз данных.
Введение в базы данных. (c) Зеленков
Ю.А. (yz@yars.free.net) 1997 г.
(c) Центр Интернет ЯрГУ