Целостность сущностей

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

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

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

Требования к первичному ключу

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

Примеры первичных ключей

• Суррогатный ключ: искусственно созданный идентификатор, не имеющий смысловой нагрузки (например, автоинкрементное целое число id).
• Естественный ключ: ключ, основанный на реальных атрибутах сущности (например, ИНН для налогоплательщика, номер паспорта для гражданина).
• Составной ключ: ключ, состоящий из двух или более столбцов (например, номер_заказа + номер_товара в таблице деталей заказа).

Реализация в реляционных базах данных

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

SQL-синтаксис

``sql CREATE TABLE Employees ( EmployeeID INT PRIMARY KEY, -- первичный ключ FirstName VARCHAR(50), LastName VARCHAR(50), DepartmentID INT ); ``

В этом примере столбец EmployeeID объявлен первичным ключом. СУБД автоматически проверит, что:

1. При вставке новой записи значение EmployeeID не совпадает с уже существующими.
2. При обновлении записи значение EmployeeID не изменяется (если это не разрешено явно).
3. Значение EmployeeID не равно NULL.

Ограничения и механизмы

• UNIQUE-ограничение: используется для обеспечения уникальности значений в столбцах, не являющихся первичным ключом. В отличие от PRIMARY KEY, столбец с UNIQUE может содержать NULL-значения (в большинстве СУБД — одно или несколько, в зависимости от реализации).
• NOT NULL-ограничение: запрещает хранение NULL-значений в столбце. Для первичного ключа это ограничение является обязательным.
• Индексы: СУБД автоматически создаёт уникальный индекс для первичного ключа, что ускоряет поиск записей по нему.

Значение целостности сущностей

Обеспечение целостности сущностей критически важно для надёжности и корректности работы информационных систем. Нарушение этого принципа приводит к следующим проблемам:

• Дублирование данных: появление нескольких записей, описывающих один и тот же объект, что ведёт к путанице и неоднозначности.
• Потеря данных: невозможность однозначно идентифицировать запись для её обновления или удаления.
• Ошибки в отчётах и аналитике: искажение статистики, подсчётов и агрегации из-за учёта дубликатов.
• Нарушение ссылочной целостности: если первичный ключ не уникален, внешние ключи из других таблиц не смогут корректно ссылаться на конкретную запись.

Примеры нарушения целостности сущностей

Рассмотрим таблицу Students:

В этой таблице значение StudentID = 1 встречается дважды. Это нарушение целостности сущностей, так как первичный ключ не уникален. Система не сможет однозначно определить, какой студент скрывается под идентификатором 1. В корректной базе данных такая ситуация была бы предотвращена ограничением PRIMARY KEY.

Связь с другими типами целостности

Целостность сущностей тесно связана с другими аспектами целостности данных:

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

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

Хотя концепция целостности сущностей универсальна, конкретные механизмы её реализации могут различаться в разных СУБД:

• MySQL: поддерживает PRIMARY KEY, UNIQUE, AUTO_INCREMENT для автоматической генерации суррогатных ключей.
• PostgreSQL: аналогично, с использованием SERIAL или GENERATED AS IDENTITY для генерации ключей.
• Microsoft SQL Server: поддерживает IDENTITY для автоматической генерации, а также UNIQUEIDENTIFIER (GUID) в качестве первичного ключа.
• Oracle: использует SEQUENCE и TRIGGER для генерации значений, а также IDENTITY (с версии 12c).

Критика и альтернативные подходы

В некоторых контекстах строгое соблюдение целостности сущностей может быть затруднено или нецелесообразно:

• Распределённые системы: в базах данных, работающих в режиме офлайн или с задержками синхронизации, генерация уникальных идентификаторов может быть сложной. Используются UUID (универсальные уникальные идентификаторы) или распределённые генераторы ключей (например, Snowflake от Twitter).
• NoSQL-базы данных: в документо-ориентированных (MongoDB) или ключ-значение (Redis) базах данных понятие целостности сущностей может быть реализовано иначе. Например, в MongoDB каждый документ имеет уникальное поле _id, которое автоматически генерируется, если не указано явно.
• Хранилища данных: в аналитических системах (Data Warehouse) иногда допускается наличие дублирующихся записей для повышения производительности запросов, но при этом используются специальные механизмы (например, DISTINCT или дедупликация на этапе ETL).

Источники

• Кодд, Э. Ф. «Реляционная модель данных для больших совместно используемых банков данных» (1970).
• Дейт, К. Дж. «Введение в системы баз данных» (8-е издание).
• Гарсиа-Молина, Г., Ульман, Д., Уидом, Д. «Системы баз данных. Полный курс».
• Документация MySQL, PostgreSQL, Microsoft SQL Server, Oracle по ограничениям целостности.