12 правил реляционной базы данных

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

История возникновения

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

Правило 0: Фундаментальное правило

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

Правило 1: Правило информации (Information Rule)

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

Правило 2: Правило гарантированного доступа (Guaranteed Access Rule)

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

Правило 3: Правило систематической обработки отсутствующих значений (Systematic Treatment of Null Values)

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

Правило 4: Правило активного реляционного каталога (Dynamic Online Catalog Based on the Relational Model)

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

Правило 5: Правило всеобъемлющего языка данных (Comprehensive Data Sublanguage Rule)

Реляционная СУБД должна поддерживать хотя бы один язык, который обладает полным набором средств для определения данных (DDL), манипулирования данными (DML), управления транзакциями, определения ограничений целостности и авторизации. Этим языком является SQL (Structured Query Language). Язык должен быть единым и мощным, позволяя выполнять все операции без необходимости прибегать к другим языкам программирования для обхода ограничений системы.

Правило 6: Правило обновления представлений (View Updating Rule)

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

Правило 7: Правило высокоуровневых операций вставки, обновления и удаления (High-Level Insert, Update, and Delete)

СУБД должна поддерживать операции вставки, обновления и удаления не только над одной строкой, но и над множеством строк одновременно, как единое целое. Это означает, что команды UPDATE, INSERT и DELETE должны работать с наборами кортежей, а не требовать построчного перебора. Например, запрос «Удалить всех заказчиков из Москвы» должен выполняться одной командой, а не циклом.

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

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

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

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

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

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

Правило 11: Правило независимости от распределения (Distribution Independence)

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

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

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

Критика и практическое применение

12 правил Кодда сыграли огромную роль в становлении теории реляционных баз данных, но на практике они оказались идеализированными. Ни одна коммерческая СУБД (Oracle, PostgreSQL, MySQL, Microsoft SQL Server) не соблюдает их полностью. Например, правило 6 (обновляемость представлений) реализовано лишь частично, а правило 12 (неподрывность) часто нарушается из-за необходимости оптимизации производительности. Тем не менее, эти правила остаются важным ориентиром для проектирования и оценки реляционных систем. Они помогают разработчикам понимать, какие возможности должна предоставлять СУБД, чтобы считаться «настоящей» реляционной, и служат основой для академического изучения баз данных.

Источники

• Codd, E. F. (1970). «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM.
• Codd, E. F. (1985). «Is Your DBMS Really Relational?» Computerworld.
• Date, C. J. (2003). «An Introduction to Database Systems» (8th ed.). Addison-Wesley.
• Connolly, T., Begg, C. (2015). «Database Systems: A Practical Approach to Design, Implementation, and Management» (6th ed.). Pearson.