Полнота по Кодду

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

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

Понятие полноты по Кодду возникло в контексте формализации реляционной модели. Эдгар Кодд, работая в IBM Research, в 1970 году опубликовал статью «A Relational Model of Data for Large Shared Data Banks», где заложил основы теории реляционных баз данных. В последующих работах, в частности в 1985 году, Кодд сформулировал 12 правил для реляционных СУБД, которые должны были гарантировать, что система является «полностью реляционной». Эти правила включали в себя требования к целостности, манипулированию данными и управлению схемой. Полнота по Кодду, как свойство, вытекает из этих правил: система должна быть способна обрабатывать все ограничения целостности, не прибегая к процедурным расширениям.

Основные принципы

Полнота по Кодду базируется на нескольких фундаментальных принципах реляционной модели:

• Целостность сущностей: Каждый кортеж (строка) в таблице должен быть уникально идентифицирован с помощью первичного ключа. Первичный ключ не может содержать NULL-значения.
• Ссылочная целостность: Значения внешних ключей должны соответствовать значениям первичных ключей в связанных таблицах или быть NULL. Это правило гарантирует, что связи между таблицами не нарушаются.
• Целостность на уровне доменов: Все значения атрибутов (столбцов) должны принадлежать определённому домену (типу данных), и система должна проверять соответствие этим доменам.
• Декларативность: Ограничения целостности должны задаваться декларативно, то есть как часть схемы базы данных (например, с помощью операторов CREATE TABLE, ALTER TABLE в SQL), а не через процедурный код (триггеры, хранимые процедуры). Это позволяет СУБД автоматически проверять и поддерживать целостность данных.

Критерии и требования

Чтобы система считалась «полной по Кодду», она должна удовлетворять ряду требований, вытекающих из его правил:

1. Представление информации: Все данные в базе должны быть представлены только как значения в таблицах (реляционных отношениях). Никакая информация не должна храниться вне таблиц (например, в файлах или структурах, не подчиняющихся реляционной модели).
2. Гарантированный доступ: Каждый элемент данных (значение атрибута) должен быть доступен через комбинацию имени таблицы, первичного ключа и имени атрибута. Это означает, что первичные ключи обязательны для всех таблиц.
3. Обработка NULL-значений: Система должна поддерживать NULL-значения (отсутствие данных) и обрабатывать их единообразно, независимо от типа данных.
4. Поддержка ограничений целостности: Система должна позволять определять первичные ключи, внешние ключи, уникальные ограничения и проверки на уровне доменов, и автоматически их поддерживать.
5. Язык манипулирования данными: Должен существовать единый, мощный язык (например, SQL), который позволяет выполнять все операции: выборку, вставку, обновление, удаление, а также управление схемой.
6. Физическая независимость данных: Изменения в физическом хранении данных (например, индексах, файлах) не должны влиять на логическую схему и прикладные программы.
7. Логическая независимость данных: Изменения в логической схеме (например, добавление столбца) не должны влиять на существующие прикладные программы, если они не используют изменённые части схемы.

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

Большинство современных реляционных СУБД, таких как PostgreSQL, MySQL, Oracle Database, Microsoft SQL Server, в значительной степени соответствуют требованиям полноты по Кодду. Однако на практике полное соответствие достигается редко. Например:

• Поддержка декларативных ограничений: Все перечисленные СУБД поддерживают PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK и NOT NULL. Однако некоторые сложные ограничения (например, циклические ссылки или каскадные действия) могут потребовать процедурных расширений.
• NULL-значения: Обработка NULL-значений стандартизирована, но существуют различия в поведении при агрегации и сравнениях (например, в MySQL NULL может вести себя иначе, чем в PostgreSQL).
• Физическая независимость: Современные СУБД обеспечивают высокую степень физической независимости, но некоторые операции (например, реорганизация индексов) могут временно влиять на доступность данных.
• Язык SQL: SQL является стандартом, но каждая СУБД имеет свои диалекты и расширения, что может нарушать принцип единообразия.

Критика и ограничения

Концепция полноты по Кодду не лишена критики. Основные замечания включают:

• Практическая нереализуемость: Полное соответствие всем 12 правилам Кодда на практике встречается редко. Многие СУБД жертвуют некоторыми аспектами полноты в пользу производительности, удобства или поддержки нереляционных возможностей (например, JSON-типов, полнотекстового поиска).
• Устаревание модели: С развитием NoSQL-систем и гибридных подходов (NewSQL) реляционная модель перестала быть единственной парадигмой. Полнота по Кодду не учитывает требования к масштабируемости, гибкости схемы или работе с неструктурированными данными.
• Процедурные расширения: На практике ограничения целостности, которые невозможно выразить декларативно (например, сложные бизнес-правила), реализуются через триггеры или хранимые процедуры. Это не нарушает полноту по Кодду, если эти механизмы не заменяют, а дополняют декларативные средства. Однако некоторые системы могут полагаться исключительно на процедурный код, что снижает степень полноты.

Значение и влияние

Несмотря на критику, полнота по Кодду остаётся важным теоретическим критерием для оценки реляционных СУБД. Она способствовала:

• Стандартизации SQL: Требования к декларативности и единому языку манипулирования данными привели к созданию и развитию стандарта SQL.
• Улучшению целостности данных: Автоматическая поддержка ограничений целостности снижает количество ошибок в данных и упрощает разработку приложений.
• Развитию теории баз данных: Концепция стимулировала исследования в области формальных моделей данных и языков запросов.

Примеры

Пример декларативного определения ограничений в SQL, соответствующего принципам полноты по Кодду:

``sql CREATE TABLE Сотрудники ( ID_сотрудника INT PRIMARY KEY, ФИО VARCHAR(100) NOT NULL, Отдел_ID INT, Зарплата DECIMAL(10,2) CHECK (Зарплата > 0), FOREIGN KEY (Отдел_ID) REFERENCES Отделы(ID_отдела) ); ``

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

Источники

• 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?" and "Does Your DBMS Run By the Rules?". Computerworld.
• Date, C. J. (2004). An Introduction to Database Systems (8th ed.). Addison-Wesley.
• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2010). Database System Concepts (6th ed.). McGraw-Hill.