Реляционная полнота

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

История появления понятия

Понятие реляционной полноты было введено Эдгаром Коддом в его основополагающей работе «Реляционная модель данных для больших совместно используемых банков данных» (1970). Кодд предложил реляционную модель как альтернативу иерархическим и сетевым моделям, которые доминировали в 1960-х годах. Однако на практике первые коммерческие СУБД (например, IBM System R, Oracle) реализовывали реляционную модель лишь частично. Для оценки степени соответствия Кодд в 1985 году опубликовал список из двенадцати правил (известных как «12 правил Кодда»), которые определяют минимальные требования для того, чтобы СУБД могла считаться реляционной.

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

Критерии реляционной полноты (12 правил Кодда)

Правила Кодда нумеруются от 0 до 12 (правило 0 является основополагающим). Для полного соответствия реляционной модели система должна выполнять все правила. Ниже приведён список основных правил с пояснениями.

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

Система должна использовать свои реляционные возможности (а не какие-либо иные) для управления базой данных. Это означает, что все взаимодействия с данными — определение, манипулирование, управление — должны быть основаны на реляционной модели.

Правило 1: Информационное правило

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

Правило 2: Правило гарантированного доступа

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

Правило 3: Правило обработки NULL-значений

Система должна поддерживать NULL-значения (отсутствие информации) для представления неизвестных или неприменимых данных. NULL-значения должны обрабатываться систематически, независимо от типа данных.

Правило 4: Правило активного реляционного каталога

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

Правило 5: Правило подъязыка данных

Система должна поддерживать по крайней мере один реляционный язык с чётким синтаксисом, который предоставляет возможности определения данных, манипулирования данными и управления транзакциями. Примером такого языка является SQL (Structured Query Language).

Правило 6: Правило обновления представлений

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

Правило 7: Правило высокоуровневых операций

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

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

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

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

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

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

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

Правило 11: Правило распределённой независимости

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

Правило 12: Правило неподчинения

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

Реляционная полнота и стандарт SQL

SQL (Structured Query Language) является самым распространённым языком для работы с реляционными базами данных. Однако SQL не полностью соответствует всем правилам Кодда по нескольким причинам:

• Правило 6 (обновление представлений) в SQL нарушается повсеместно: представления с JOIN, агрегациями или DISTINCT обычно доступны только для чтения.
• Правило 3 (обработка NULL) в SQL имеет особенности: NULL не равен NULL, и операции сравнения требуют использования IS NULL.
• Правило 9 (логическая независимость) нарушается, например, при изменении имени столбца — приложение, обращающееся к столбцу по старому имени, перестанет работать.
• Правило 5 (подъязык данных) в SQL выполняется лишь частично: SQL включает в себя DDL, DML и DCL, но не поддерживает полноценного реляционного исчисления.

Стандарты SQL (SQL-92, SQL:1999, SQL:2003 и более новые) постоянно приближают язык к реляционной полноте, но полное соответствие до сих пор не достигнуто.

Реляционная полнота в современных СУБД

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

Некоторые СУБД, такие как Couchbase (документо-ориентированная) и MongoDB (NoSQL), вообще не являются реляционными и не претендуют на соответствие правилам Кодда.

Критика понятия реляционной полноты

Понятие реляционной полноты подвергается критике по нескольким причинам:

• Историческая обусловленность. Правила Кодда были сформулированы в 1985 году и отражают состояние технологий того времени. Некоторые положения, например, правило 8 (физическая независимость), считаются сегодня самоочевидными, в то время как другие, как правило 6 (обновление представлений), слишком строги для практической реализации.
• Неполнота. Правила не охватывают такие современные требования, как масштабируемость, replication, работа с временными рядами или поддержка XML/JSON.
• Неоднозначность. Некоторые правила (например, правило 4 — активный каталог) интерпретируются по-разному разными разработчиками.
• Прагматический подход. На практике разработчики и администраторы баз данных редко ориентируются на правила Кодда. Вместо этого они оценивают СУБД по таким критериям, как производительность, надёжность, безопасность, поддержка стандартов SQL, наличие инструментов мониторинга и удобство разработки.

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

См. также

• Реляционная модель данных
• Реляционная алгебра
• Нормализация баз данных
• SQL
• Эдгар Кодд

Источники

1. Codd E.F. A Relational Model of Data for Large Shared Data Banks. — Communications of the ACM, 1970.
2. Codd E.F. Is Your DBMS Really Relational? — Computerworld, 1985.
3. Date C.J. An Introduction to Database Systems. — 8th ed. — Addison-Wesley, 2003.
4. Elmasri R., Navathe S.B. Fundamentals of Database Systems. — 7th ed. — Pearson, 2015.
5. Standard SQL-92. — ISO/IEC 9075:1992.
6. Материалы лекций по базам данных МГУ им. М.В. Ломоносова (кафедра информатики, 2023).