Билет 10. 1.Правила Кодда: информации, гарантированного доступа, недействительных значений, каталога, исчерпывающего языка

1.Правила Кодда: информации, гарантированного доступа, недействительных значений, каталога, исчерпывающего языка, обновления представлений

Тэд Кодд в 1969 году сформулировал двенадцать правил, которым должна соответствовать настоящая реляционная база данных. (табл 11.1). Они являются полуофициальным определением понятия «реляционная база данных».

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

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

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

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

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

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

Правило 6 касается представлений, которые являются виртуальными таблицами. Виртуальные таблицы, в отличие от «настоящих» таблиц, физически не хранятся в базе данных. В то же время необходимо осознавать, что виртуальные таблицы это не копия некоторых данных, помещаемая в другую таблицу. Когда вы изменяете данные в виртуальной таблице, то тем самым изменяете данные в базовых таблицах. В идеальной реляционной системе с виртуальными таблицами можно оперировать, как и с любыми другими таблицами. Это одно из правил, которые сложнее всего реализовать на практике.

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

Правило 8 и 9 означают отделение пользователя и прикладной программы от низкоуровневой реализации базы данных. Они утверждают, что конкретные способы реализации хранения или доступа, используемые в СУБД, и даже изменения структуры таблиц базы данных не должны влиять на возможность пользователя работать с данными. Реляционная модель обеспечивает независимость данных на двух уровнях - физическом и логическом. Физическая независимость данных означает с точки зрения пользователя, что представление данных абсолютно не зависит от способа их физического хранения. Логическая независимость означает, что изменение взаимосвязей между таблицами и строками, их структура не влияют на правильное функционирование программ и текущих запросов.

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

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

Третий тип целостности, называемой ссылочной целостностью, означает непротиворечивость между частями информации, повторяющимися в разных таблицах. Например, если вы изменяете неправильно введенный номер карточки страхового полиса в одной таблице, другие таблицы, содержащие эту же информацию, продолжают ссылаться на старый номер, поэтому необходимо обновить и эти таблицы. Чрезвычайно важно, чтобы при изменении информации в одном месте, она соответственно изменялась и во всех других местах. Кроме того, по определению Кодда, ограничения на целостность должны:

- Определяться на языке высокого уровня, используемом системой для всех других целей;

- Храниться в базе данных, а не в программных приложениях.

Эти возможности в том или ином виде реализованы в большинстве СУБД.

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

И, наконец, правило 12 предотвращает использование других возможностей для работы с базой данных, помимо языка базы данных, поскольку это может нарушить ее целостность.

Двенадцать правил Кодда считаются определением реляционной СУБД. Однако можно сформулировать и более простое определение:

Реляционной называется база данных, в которой все данные, доступные пользователю, организованны в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами.