Правила Кодда

Размещено на http://allbest.ru

Правила Кодда

В 1985 году в двух статьях в журнале Computer World Э.Ф. Кодд сформулировал правила, которым должны соответствовать настоящие реляционные базы данных. Всего правил было двенадцать. Несколько позже Кодд сформулировал 13-е правило и присвоил ему номер 0. Начнем рассмотрение правил с этого последнего или нулевого.

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

Замечание

Реляционное СУБД FoxPro изначально обладало рядом не реляционных свойств. Так в частности язык управления реляционными базами данных (точнее сказать табличными) оперировал таким понятием как текущая строка. В первых версиях FoxPro(в начале он назывался просто Fox) отсутствовало понятие базы данных и, соответственно, схемы базы данных. В последствии разработчики попытались исправить ситуацию, сделав язык SQL подмножеством языка FoxPro и введя понятие база данных.

Правило 1 (правило информации). Вся информация в реляционной базе данных (включая имена таблиц и столбцов) представляется в явном виде только на логическом уровне и только в виде значений, хранящихся в таблицах. Отсюда кстати вытекает и условие отсутствия порядка строк и столбцов в таблицах, поскольку упорядоченная последовательность добавляет дополнительную возможность хранения информации. Заметим также, что схема базы данных также должна храниться в табличном виде. Упоминание же в правиле 1 логического уровня означает, что информация об объектах более низкого уровня, например, индексах, должна быть исключена из модели данных.

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

Правило 2 (правило гарантированного доступа). Логический доступ ко всем и каждому элементу данных в реляционной базе данных обеспечивается комбинацией имени таблицы, имени столбца и значением первичного ключа. Это требование предполагает:

o Уникальность имени таблицы в базе данных.

o Уникальность имени столбца в таблице.

o Уникальность первичного ключа, по крайней мере, в пределах одной таблицы.

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

Правило 3 (правило обработки неизвестных значений). В реляционной базе должна быть реализована возможность представлять неизвестные значения. Предполагается, что неизвестные значения отличаются от каких-либо определенных значений (числовых, строковых и т.п.) и должны быть реализованы для всех типов данных, хранящихся в базе. Данное правило провозглашает существование в реляционных базах данных значения NULL.

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

Замечание

Многие разработчики СУБД стараются следовать этому правилу. Так, при создании базы данных в СУБД FoxPro создается файл с расширением .dbc. На поверку, однако, этот файл оказывается таблицей (dbf-формат), которая содержит информацию, описывающую структуру базы данных. В такой СУБД как MS SQL Server описание базы данных хранится в специальных системных таблицах.

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

o Определение структуры данных.

o Определение представлений.

o Модификацию данных (содержимого таблиц).

o Определения условий целостности.

o Определение правил авторизации (идентификация прав доступа).

o Определение границ транзакций.

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

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

Правило 7 (правило множественности обновлений). Операции вставки, удаления и обновления должны быть применимы к базовым таблицам, как и чтение данных из таблицы. Данное правило предполагает, что все операции модификации должны иметь и множественный вариант - операция может производиться не только над одной строкой таблицы, но и над группой строк. В дальнейшем мы увидим, что операции модификации языка SQL действительно соответствуют данному правилу.

Правило 8 (правило независимости на физическом уровне). Какие бы изменения на физическом уровне не происходили с данными или аппаратной частью, это не должно сказаться на функционировании прикладных программ или утилит управления данными. Из данного правила фактически и вытекает основное требование к СУБД, о котором мы уже говорили ранее. СУБД так должна взаимодействовать с операционной системой и, посредством нее с файловой системой, что изменения на файловом и аппаратном уровне не должны сказаться на функционировании ИС, которая построена на базе данной СУБД. Разумеется, это не означает, что для данной ИС не может быть специальных требований к ресурсам и аппаратуре. Но эти требования обусловлены особенностями функционирования данной ИС, а не зависимостью СУБД от среды исполнения.

Правило 9 (правило независимости на логическом уровне). Прикладное программное обеспечение не должно зависеть от изменений, вносимых в структуру базы данных, которые теоретически не должны изменять хранящиеся в базе данные. Данное требование связано с содержательной стороной структуры базы данных. Например, добавление в таблицу нового столбца не может сказаться на функционировании прикладных программ, так как доступ к данным осуществляется по именам столбцов. Порядок столбцов, который может при этом измениться не может влиять на доступ к данным.

Замечание

При добавлении столбца следует также учитывать команду вставки строки. Для того, чтобы не повлиять на эту команду для вставляемого столбца должно быть указано значение по умолчанию.

Напротив, удаление столбца из таблицы, скорее всего, приведет к неправильному функционированию системы, поскольку с большой вероятностью данный столбец явно (по имени) использовался в той или иной операции. Правило 10 (правило независимости условий целостности). Должна существовать возможность формулировки правил целостности специфических для данной базы данных на языке реляционных баз данных. Правила целостности, таким образом, должны храниться в каталоге базы данных. Данное требование очень сильное и требует для полноты его исполнения наличие в частности в базе данных таких объектов как триггеры.

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

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

кодд реляционный база данных

Размещено на Allbest.ru