Ограничения ссылочной целостности являются лишь подмножеством "ограничений базы данных в целом".
Нормализация и ограничения базы данных - это разные, но взаимосвязанные понятия.
Допустим, у вас есть таблица CUSTOMERORDER (custID, custName, orderID), в которой говорится, что «клиент, идентифицированный с помощью # custID # и имеющий имя # custName #, разместил заказ, идентифицированный с помощью #orderID #».
Эта таблица вряд ли будет в 3NF из-за вероятности применения FD custID-> custName. Но, скажем, мы сохраняем этот дизайн за одним столом. Что мы тогда должны сделать, чтобы обеспечить согласованность данных? Мы должны обеспечить соблюдение упомянутого FD. Мы должны убедиться, что если один и тот же клиент разместит второй заказ, то custName в двух строках будет одинаковым. Мы должны запретить такие строки, как (1, Смит, 2) и (1, Джонс, 7), чтобы они появлялись в таблице. Это своего рода ограничение базы данных, которое необходимо применить, чтобы наш дизайн соответствовал всем заявленным бизнес-правилам.
Но учтите, что у нас нет никаких «ссылочных» ограничений здесь. Очевидно, потому что нет второй таблицы для ссылки.
Также попутно заметьте, что этот дизайн с одной таблицей «автоматически» накладывает некоторые другие ограничения, которые могут быть неочевидными. Например, наша конструкция с одной таблицей делает невозможным существование orderID без соответствующего custID и custName. (Если вы думаете о пустых значениях, прекратите это делать. В реляционной теории не существует таких вещей, как «нулевые».) «Правило», согласно которому, если зарегистрирован идентификатор_порядка, также должен существовать соответствующий custID PLUS custName. , принудительно "неявно" поддерживается нашей конструкцией, основанной на одной таблице.
Но теперь мы разлагаем наш дизайн на два стола, как предписывает традиционная теория нормализации:
CUSTOMER (custID, custName) КЛЮЧ custID;
ORDER (custID, orderID) КЛЮЧ custID, orderID;
Бизнес-правила, которые мы должны применять, остаются такими же, а именно: (а) не может быть двух клиентов с одинаковым custID, но с другим именем (это наш FD), и (б) не может быть никакого заказа без соответствующий custID PLUS custName для этого заказа.
Давайте посмотрим, как наш дизайн двух таблиц обрабатывает эти бизнес-правила. (a) очевидно обеспечивается применением custID как ключа для CUSTOMER. Что касается (b), очевидно, что невозможно записать orderID в ORDER без записи custID. Но достаточно ли этого для гарантии того, что для всех строк ORDER будет также custName ? Очевидно нет. Вот почему нам нужно ввести очевидное правило ссылочной целостности между ORDER и CUSTOMER.
Таким образом, ограничения RI действительно «помогают решать проблемы избыточности данных», в том смысле, что путем декомпозиции таблицы и введения ограничения RI в общий дизайн они позволяют устранить определенный вид избыточность при сохранении определенных гарантий целостности данных. Без возможности введения ограничений RI в дизайн мы бы исключали избыточность только за счет согласованности данных.