Теория реляционных БД. Часть 5

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

Домен — во многом понятийный элемент, отражающий логику столбца. На физическом уровне реализовать такие ограничения непросто, это делается программно. Сама модель данных не во всех СУБД поддерживает домен. В ERwin на логической схеме мы можем ввести домен, например, для ИНН: тип данных — целое число (integer), но домен — ровно двенадцать цифр, возможно, с условием, что первая цифра не ноль. На уровне физического создания таблиц мы обычно задаём только тип, однако некоторые СУБД (например, Oracle) позволяют программировать домен прямо на уровне модели.

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

Атрибут и степень отношения
Атрибут (attribute) — свойство, характеризующее объект. В структуре таблицы атрибуту соответствует заголовок столбца. Количество атрибутов называется степенью отношения. Отношение на физическом уровне — это таблица, поэтому оба понятия считаются эквивалентными. Степень отношения — это число столбцов.

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

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

Кортеж и отношение
Кортеж (tuple), соответствующий схеме отношения, — множество пар «имя атрибута, значение». В отличие от схемы, где пара — «атрибут–домен», здесь фиксируется конкретное значение, допустимое в рамках заданного домена. Например, для схемы (ID: целое, Имя: строка) кортежами будут (ID: 1, Имя: 'Иванов'), (ID: 2, Имя: 'Петров'). То есть кортеж — это набор именованных значений заданного типа.

Отношение (relation) — множество кортежей, соответствующих одной схеме отношения. Так замыкается цепочка: схема определяет домены, кортежи берут из них значения, а отношение объединяет все допустимые кортежи. Имя схемы отношения обычно совпадает с именем таблицы (экземпляра отношения).

Реляционная база данных — набор отношений (таблиц), имена которых совпадают с именами схем отношений в схеме БД.

Фундаментальные свойства отношений
Реляционная модель предъявляет к отношениям четыре обязательных свойства:
• Отсутствие кортежей-дубликатов (нет повторяющихся строк).
• Отсутствие упорядоченности кортежей (порядок строк неважен).
• Отсутствие упорядоченности атрибутов (порядок столбцов неважен).
• Атомарность значений атрибутов (в каждой ячейке — ровно одно неделимое значение).

Первичный ключ и уникальность строк
Отсутствие дубликатов достигается введением первичного ключа (primary key) — уникального подмножества атрибутов, однозначно определяющего весь кортеж. Важнейший критерий — минимальность длины ключа. Вместо набора из семи полей (фамилия, имя, отчество, дата, место рождения, пол, имя матери) предпочтительнее одно поле — например, номер СНИЛС. Первичный ключ стремится быть простым, то есть состоять из одного атрибута.

Упорядоченность и SQL
В SQL-запросах можно указать порядок вывода строк и столбцов, однако это исключительно визуализация для человека. Физически строки и столбцы не упорядочены. При необходимости порядок атрибутов в выдаче можно изменить, по умолчанию он соответствует схеме отношения.

Атомарность и первая нормальная форма
Значения всех атрибутов должны быть атомарными. Нельзя в одной ячейке хранить ещё одну таблицу или список. Требование атомарности всех полей отношения составляет первую нормальную форму (1НФ).

Рассмотрим пример. Таблица «Отдел» в каждой ячейке «Сотрудники» перечисляет нескольких человек. Это нарушение атомарности. Приведение к 1НФ даёт новую структуру, где для каждого сотрудника заводится отдельная строка с атрибутами «Номер сотрудника», «Имя», «Зарплата» и «Номер отдела». Теперь в каждой ячейке ровно одно значение, соответствующее домену столбца.

Практическая значимость 1НФ проявляется при операциях вставки. Чтобы добавить сотрудника в новый отдел №320, в ненормализованной таблице потребовалось бы создавать новую строку с этим отделом, что неестественно. А при зачислении сотрудника в уже существующий отдел №310 пришлось бы расширять список внутри ячейки — сложная и ненадёжная операция. В нормализованной таблице достаточно добавить одну строку с номером отдела. То есть ненормализованная структура серьёзно усложняет модификацию данных.

Существует тенденция доводить схему до третьей нормальной формы. Всего нормальных форм восемь: с первой по шестую, плюс нормальная форма Бойса–Кодда (BCNF) между третьей и четвёртой, а также доменно-ключевая нормальная форма (DKNF) между четвёртой и пятой. Пока мы рассмотрели только первую, остальные будут изучены позже.

Краткие итоги

Представленный материал формирует системное понимание реляционной модели, двигаясь от атомарных ограничений к целостной структуре данных и требованиям их корректной организации. Исходной точкой служит домен — не просто тип, а семантический фильтр, который наделяет значение смыслом и задаёт границы сравнимости. Без доменного контроля невозможно гарантировать, что в атрибут «ИНН» попадёт именно двенадцатизначное число, а в «Название государства» — осмысленная строка. Это первая линия защиты качества данных, которая на практике часто реализуется программно или средствами развитых СУБД.

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

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

Требование уникальности воплощается в первичном ключе, где борьба за минимальность — это не просто эстетика, а практическая необходимость снизить накладные расходы на хранение и ускорить соединения. Сравнение ключа из семи полей с одноатрибутным СНИЛС наглядно показывает, как правильно выбранный идентификатор упрощает всю дальнейшую работу.

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

Таким образом, последовательное освоение от домена до 1НФ даёт целостный инструментарий для проектирования устойчивых, непротиворечивых и удобных в эксплуатации реляционных структур, закладывая базу для дальнейшего изучения более высоких нормальных форм.