Что такое домен атрибута

Чтобы понять смысл термина, важно разделять атрибут и его домен. Атрибут описывает характеристику объекта. В таблице «Сотрудники» это могут быть «Табельный номер», «Фамилия», «Дата приема» и «Отдел». Каждый атрибут отвечает на свой вопрос о сотруднике и хранится в отдельном столбце.

Домен определяет, какие именно значения разрешено записывать в этот столбец. Так, домен атрибута «Дата приема» включает корректные календарные даты, а домен «Табельный номер» может включать положительные целые числа установленной длины. Один и тот же тип данных сам по себе еще не является полноценным доменом. Например, тип «целое число» допускает множество чисел, но правило «номер отдела от 1 до 50» существенно сужает допустимую область.

В классической реляционной теории значения одного атрибута должны относиться к одному домену. Это делает данные однородными и понятными: в поле с датой не окажется текстового комментария, а в поле со статусом — случайного числа.

Домен обычно формируется из нескольких ограничений. Первое — базовый тип: строка, целое или дробное число, дата, время, логическое значение и другой поддерживаемый формат. Второе — набор допустимых значений. Он может быть непрерывным, например числа от 1 до 100, или перечислимым, когда разрешены только заранее установленные варианты.

Третья часть — дополнительные правила. Для строк это максимальная длина, шаблон записи, допустимые символы или обязательность заполнения. Для чисел устанавливают минимальное и максимальное значение, точность и количество знаков после запятой. Для дат могут ограничивать период: например, дата окончания договора не должна быть раньше даты его начала.

Отдельно определяется отношение к пустым значениям. Значение NULL означает не ноль и не пустую строку, а отсутствие либо неизвестность сведений. Если атрибут обязателен, в его домен или в ограничение столбца включают запрет на NULL. Например, идентификатор клиента, как правило, не может быть пустым, а второе имя — может.

Рассмотрим таблицу интернет-магазина «Заказы». У атрибута «Номер заказа» доменом может быть уникальное положительное целое число. Для «Суммы заказа» подойдет неотрицательное денежное значение с двумя знаками после запятой. Атрибут «Дата создания» принимает дату и время, а «Статус» — только состояния, предусмотренные бизнес-процессом.

Другой пример — таблица «Товары». Поле «Артикул» может иметь домен строк длиной до 30 символов с буквами, цифрами и дефисом. Для «Остатка на складе» допустимы целые числа не меньше нуля. Поле «Активен» имеет логический домен: да или нет. Если система хранит код валюты, доменом будет ограниченный перечень кодов, используемых компанией.

Важно, что внешняя связь тоже опирается на домены. Если «Код отдела» в таблице сотрудников ссылается на таблицу отделов, значения в связанных полях должны быть совместимы. Обычно совпадают тип, длина и правила представления. Иначе база данных не сможет надежно сопоставлять записи.

Главная задача домена — поддерживать качество данных. Проверка на уровне базы предотвращает очевидные ошибки независимо от того, из какого приложения, формы или интеграции поступает запись. Пользователь не сможет указать отрицательное количество товара, если это запрещено, а программа не сохранит текст в числовом поле.

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

Однако домен не заменяет все правила предметной области. Например, ограничение «скидка от 0 до 100» не гарантирует, что скидка согласована с договором. Для сложных проверок применяют дополнительные механизмы: ограничения целостности, уникальные ключи, внешние ключи, проверки на уровне приложения и бизнес-логику.

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

Не стоит делать домен слишком широким. Поле со свободным текстом для статуса заказа формально примет любое слово, но приведет к вариантам вроде «оплачен», «Оплачен» и «оплата прошла». Лучше использовать ограниченный набор состояний. В то же время чрезмерно жесткие правила мешают развитию системы, поэтому допустимые значения должны соответствовать реальным процессам и пересматриваться при их изменении.

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