Как определить степень соответствия СУБД реляционной модели.

Заврешая обсуждение моделей данных подведем некоторые итоги. Преимущества реляционного подхода достаточно очевидны:

1. Предсказуемость результатов работы с данными. В основе реляционной модели лежит математическая модель, следовательно, любой запрос к базе данных, составленный на корректном языке влечет ответ, однозначно определяемый схемой БД и конкретными данными. При этом пользователю не требуется информация о физической организации данных.
2. Предметная область часто достаточно естественно описывается в терминах таблиц (к сожалению, в реляционной модели имеются проблемы с представлением иерархических структур, подробнее см. раздел 5.5.3.

По этим причинам идея создания реляционной СУБД стала популярна среди разработчиков вскоре после ее появления. Сейчас существует множество коммерческих и некоммерческих систем, создатели которых заявляют об их "реляционности". Для того, чтобы более определенно сформулировать цель, к которой разработчикам нужно стремится, Е.Кодд в конце 70-х годов опубликовал 12 правил соответствия реляционной модели, которые опираются на основное (подразумеваемое) правило:

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

Конкретные требования к реляционной СУБД раскрываются в следующих правилах (цитируется по статье В.Пржиялковский Модели, базы данных и СУБД в информационных системах):

1. Информационное правило. Вся информация, хранимая в базе данных, должна быть представлена единственным образом: в виде значений в реляционных таблицах.
2. Правило гарантированного логического доступа. К каждому имеющемуся в реляционной базе атомарному значению должне быть гарантирован доступ с помощью указания имени таблицы, значения первичного ключа и имени атрибута.
3. Правило наличия значения (missing information). В полностью реляционной СУБД должны иметься специальные индикаторы (отличные от пустой символьной строки или строки из одних пробелов и отличные от нуля или какого-то другого числового значения) для выражения (на логическом уровне, не зависимо от типа данных) того факта, что значение отсутствует по меньшей мере по двум различным причинам: его действительно нет, либо оно не применимо к данной позиции. СУБД должна не только отражать этот факт, но и распространять на такие индикаторы свои функции манипулирования данными не зависимо от типа данных.
4. Правило динамического диалогового реляционного какталога. Описание базы данных выглядит логически как обычные данные, так что авторизованные пользователи и прикладные программы могут употреблять для работы с этим описанием тот же реляционный язык, что и при работе с обычными данными.
5. Правило полноты языка работы с данными. Сколько бы много в СУБД ни поддерживалось языков и режимов работы с данными, должен иметься по крайней мере один язык, выразимый в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:
• определение данных
• определение правил целостности
• манипулирование данными (в диалоге и из программы)
• определение таблиц-представлений (в том числе и возможности их модификации)
• определение правил авторизации
• границы транзакций
6. Правило модификации таблиц-представлений. В СУБД должен существовать корректный алгоритм, позволяющий автоматически для каждой таблицы-представления определять во время ее создания, может ли она использоваться для вставки и удаления строк и какие из столбцов допускают модификацию, и заносящий полученную таким образом информацию в системный каталог.
7. Правило множественности операций. Возможность оперирования базовыми таблицами или таблицами-представлениями распространяется полностью не только на выдачу информации из БД, но и на вставку, модификацию и удаление данных.
8. Правило физической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении данных или методах доступа СУБД
9. Правило логической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от таких изменений в базовых таблицах, которые сохраняют информацию и теоретически допускают неизменность этих операторов и программ.
10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД, задаваемых языком работы с данными и хранимых в системном каталоге.
11. Правило независимости от распределенности. Диалоговые операторы и прикладные программы на логическом уровне не должны зависеть от совершаемого физического разнесения данных (если первоначально СУБД работала с нераспределенными данными) или перераспределения (если СУБД распределенная).
12. Правило ненарушения реляционного языка. Если в реляционной СУБД имеется язык низкого уровня (для работы с отдельными строками), он не должен позволять нарушать или "обходить" правила, сформулированные на языке высокого уровня (множественном) и занесенные в системный каталог.

Проектирование реляционных БД

• 5.1.Этапы проектирования.
• 5.2.Инструментальные средства проектирования информационных систем.
• 5.3.Методологии функционального моделирования.
• 5.3.1.Диаграммы потоков данных. Нотация Йордона - Де Марко
• 5.3.2.Другие нотации, используемые при построении диаграмм потоков данны
• 5.3.3.Методология SADT (IDEF0).
• 5.3.4.Сравнительный анализ методологий функционального моделирования
• 5.4.Концептуальное моделирование. Пример построения диаграммы "сущность-связь"
• 5.5.Правила порождения реляционных отношений из модели "сущность-связь".
• 5.5.1.Бинарные связи.
• 5.5.2.N-арные связи.
• 5.5.2.Иерархические связи.
• 5.6.Проектирование реляционной базы данных на основе декомпозиции универсального отношения.
• 5.7.Обзор некоторых CASE-систем
• 5.7.1.Power Designer компании Sybase.
• 5.7.2.Silverrun компании Silverrun Technologies Ltd.
• 5.7.3.BPWin и ERWin компании LogicWorks.
• 5.7.4.Designer/2000 компании Oracle.

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