РМД/12 правил Кодда

Материал из Энциклопедия о программировании
Перейти к: навигация, поиск

12 правил Кодда (ориг. англ. Codd’s 12 rules) — 13 правил (исчисление начинается с 0), которым должна удовлетворять каждая реляционная СУБД.

Происхождение

"12 правил Кодда" предложены английским математиком Эдгаром Коддом (Edgar Codd) в 1985 году в статьях в журнале ComputerWorld.

В действительности правила столь строги, что все популярные т.н. «реляционные» СУБД не соответствуют многим критериям.

Правила

Правило 0: Основное правило (Foundation Rule):
Система, что позиционируется как реляционная СУБД, должна быть способна управлять БД, используя исключительно свои реляционные возможности.
Правило 1: Информационное правило (The Information Rule):
Всё инфо в реляционной БД на логическом уровне должна быть явно представлена единственным способом: значениями в отношениях (таблицах).
Правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):
В реляционной БД каждое отдельное (атомарное) значение данных должно быть логически доступно с помощью комбинации имени отношения (таблицы), значения первичного ключа и имени столбца.
Правило 3: Систематическая поддержка отсутствующих значений (Systematic Treatment of Null Values):
Неизвестные, или отсутствующие значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Напр., для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных — как пустые строки.
Правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):
Словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.
Правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):
Система управления реляционными БД должна поддерживать хотя бы один реляционный язык, который
  1. имеет линейный синтаксис,
  2. может использоваться как интерактивно, так и в прикладных программах,
  3. поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями (begin, commit и rollback).

Правило 6: Возможность изменения представлений (View Updating Rule):
Каждое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, изменения и удаления данных.
Правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):
Операции вставки, изменения и удаления данных должны поддерживаться не только по отношению к одной строке реляционной таблицы, но и по отношению к любому множеству строк.
Правило 8: Физическая независимость данных (Physical Data Independence):
Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютеров, на которых находится реляционная база данных.
Правило 9: Логическая независимость данных (Logical Data Independence):
Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.
Правило 10: Независимость контроля целостности (Integrity Independence):
Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.
Правило 11: Независимость от расположения (Distribution Independence):
База данных может быть распределённой, может находиться на нескольких компьютерах, и это не должно оказывать влияния на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.
Правило 12: Согласование языковых уровней (The Nonsubversion Rule):
Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и правила целостности, которые поддерживаются языком более высокого уровня.

Литература