Двенадцать правил Кодда

Двенадцать правил Кодда — это набор из двенадцати основополагающих принципов (правил), которым должна удовлетворять система управления реляционными базами данных (СУБД), чтобы считаться истинно реляционной. Сформулированы британским учёным Эдгаром Франком Коддом в 1970-х и 1985 годах. Правила призваны гарантировать независимость данных, их целостность, гибкость запросов и защиту от логических искажений. Хотя ни одна коммерческая СУБД не соответствует всем правилам полностью, они остаются эталоном для проектирования и оценки реляционных систем.

История

Эдгар Кодд, работавший в исследовательской лаборатории IBM в Сан-Хосе (Калифорния), в 1970 году опубликовал статью «A Relational Model of Data for Large Shared Data Banks», в которой впервые предложил реляционную модель данных. Однако к середине 1980-х годов на рынке появилось множество продуктов, называвших себя «реляционными», но сильно отличавшихся по функциональности. Чтобы отсеять несоответствующие системы, Кодд в 1985 году в журнале Computerworld опубликовал список из 12 правил (фактически их 13, но правило 0 считается нулевым). Эти правила стали де-факто стандартом для оценки реляционности СУБД.

Правило 0: Основополагающее правило

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

Двенадцать правил

1. Правило информации (Information rule)

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

2. Правило гарантированного доступа (Guaranteed access rule)

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

3. Правило поддержки недействительных значений (Systematic treatment of null values)

СУБД должна поддерживать специальное значение NULL для обозначения отсутствия данных или неприменимости информации. NULL не должен интерпретироваться как ноль, пустая строка или пробел. При выполнении операций (сравнения, агрегации) NULL должен обрабатываться системно, а не произвольно. Например, сравнение NULL с любым значением (включая другой NULL) должно давать результат «неизвестно» (UNKNOWN), а не TRUE или FALSE.

4. Правило активного реляционного каталога (Dynamic online catalog based on the relational model)

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

5. Правило всеобъемлющего языка (Comprehensive data sublanguage rule)

Система должна поддерживать хотя бы один реляционный язык, который:

• имеет линейный синтаксис (текстовые команды, а не графические интерфейсы);
• может использоваться для определения данных (DDL), манипулирования данными (DML), управления транзакциями и ограничениями целостности;
• поддерживает операции запросов, вставки, обновления и удаления.

Стандартным таким языком является SQL.

6. Правило обновления представлений (View updating rule)

Все представления (виртуальные таблицы, формируемые из запросов) должны быть теоретически обновляемыми. То есть если представление основано на простых реляционных операциях (например, проекция, выборка), то изменения в нём должны автоматически отражаться на базовых таблицах. На практике это правило часто нарушается, особенно для сложных представлений.

7. Правило высокоуровневых операций вставки, обновления и удаления (High-level insert, update, and delete)

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

8. Правило физической независимости данных (Physical data independence)

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

9. Правило логической независимости данных (Logical data independence)

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

10. Правило независимости целостности (Integrity independence)

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

11. Правило распространения (Distribution independence)

Система должна быть независимой от распределения данных. Пользователь не должен знать, где физически хранятся данные — на одном сервере или на нескольких. Запросы должны выполняться одинаково, независимо от того, распределена база данных или нет. Это правило стало основой для современных распределённых СУБД.

12. Правило неподрывности (Nonsubversion rule)

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

Критика и практическая реализация

Ни одна из широко распространённых коммерческих СУБД (Oracle, Microsoft SQL Server, PostgreSQL, MySQL, IBM Db2) не соответствует всем 12 правилам полностью. Например:

• Правило 6 (обновление представлений) часто нарушается — многие СУБД разрешают обновлять только простые представления.
• Правило 9 (логическая независимость) трудно реализовать на практике, особенно при изменении имён столбцов или разделении таблиц.
• Правило 5 (всеобъемлющий язык) в SQL реализовано не полностью — например, SQL не является полным по Тьюрингу (хотя его расширения, такие как PL/SQL, T-SQL, добавляют процедурные возможности).

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

Значение

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

• определили критерии, по которым можно отличить истинно реляционную СУБД от псевдореляционной;
• способствовали стандартизации языка SQL (хотя SQL не полностью соответствует правилам);
• стали основой для развития теории нормализации, транзакций и целостности;
• повлияли на проектирование современных СУБД, включая объектно-реляционные и NewSQL-системы.

Хотя с момента публикации прошло почти 40 лет, правила Кодда остаются актуальными для понимания принципов работы реляционных баз данных и их отличий от NoSQL-систем.

Источники

• Кодд Э.Ф. «A Relational Model of Data for Large Shared Data Banks» (1970).
• Кодд Э.Ф. «Is Your DBMS Really Relational?» (1985, Computerworld).
• Кодд Э.Ф. «Does Your DBMS Run By the Rules?» (1985, Computerworld).
• Дейт К.Дж. «Введение в системы баз данных» (8-е издание, 2004).
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. «Системы баз данных. Полный курс» (2004).