Целостность реляционных данных

1. Общие и специфические(доменные) правила целостности.

В любой момент времени любая БД содержит некоторые определенные значения, которые выражают определенное состояние объекта реального мира, следовательно БД нуждается в определении неких правил целостности, необходимых для того, чтобы данные не вступили в противоречие с реальным миром. Такие правила целостности являются специфическими для каждой БД. Это по сути информирование СУБД об ограничениях реального мира. Например, фамилия, имя и отчество – это только текстовые значения, рост и вес – положительные числа. Но таких правил целостности недостаточно, нужно еще, чтобы данные внутри самой БД не противоречили друг другу. Например, в БД «Факультет» случайно указали, что Иванов учится в группе ИНФ-51, но такой группы на данном факультете нет. Или например для того же Петрова указали, что он является старостой группы ИНФ-41 и также указали, что он учится в группе ИНФ-31, получается противоречие. Для предотвращения подобных ситуаций существую общие правила целостности реляционных данных . Эти правила связаны с первичными и внешними ключами.

2. Потенциальные первичные и альтернативные ключи.

Пусть R некоторое отношение, тогда потенциальный ключ K для R – это подмножество множества атрибутов R для которого выполняются следующие свойства:

• Уникальность, т.е. нет 2х различных кортежей в текущем значении переменной отношения R с одинаковыми значениями К.

• Не избыточность , т.е никакой подмножество К не обладает свойством уникальности. Например в отношении Студенты потенциальными ключами могут быть: номер зачетки, номер личного дела, номер паспорта и тд, т.к каждый из них удовлетворяет определению. Но не верно будет называть потенциальным ключом этого отношения множество нескольких из этих атрибутов , т.к не выполняется свойство не избыточности. Потенциальные ключи предназначены для обеспечения основного механизма адресации на уровне картежей, т.е по значению потенциального ключа можно однозначно найти запись в отношении. В СУБД Acсess потенциальные ключи называются индексивными полями и обозначаются следующим образом: в свойстве атрибута указывается значение «да». Базовое отношение может иметь несколько потенциальных ключей, но один из них должен быть обязательно выбран в качестве первичного ключа, остальные будут называться альтернативными. СУБД access для первичного ключа для свойства индексированного поля указывается значение «да» (совпадения не допускаются), а для альтернативного ключа может быть такое значение «да»(совпадение допускаются). В любом отношении обязательно должен быть первичный ключ, значит должен содержаться хотя бы один потенциальный ключ, альтернативных ключей может быть не быть в отношении. Если в базовом отношении нет естественных потенциальных ключей или они неудобны в рамках создаваемой БД, в этом случае вводят искусственные ключи, например, в отношении преподаватель введен искусственный ключ «код преподавателя», чтобы не использовать естественные ключи номер паспорта, номер личного дела.

Правила целостности объектов

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

Для решения данной проблемы отсутствия значений британский ученый Эдгар Франк Кодд предложил ввести специальные метки, которые назвал Null-значениями, он определил их следующим образом: если данный кортеж имеет Null значение данного атрибута, то это означает, что в нем значение атрибута отсутствует. Это не тоже что числовой ноль или пробел, это вообще не значение, а только метка обозначающая отсутствие любого значения. Некоторые специальсты по реляционным БД, например, К.Дейт считают что Null-значения не нужны и даже вредны, т.к это нарушает целостность данных но тем не менее большинство современных реляционных БД поддерживают Null-значения.

С использованием Null-значений связанно правило целостности объектов:

Не один элемент первичного ключа базового отношения не может быть Null-значением, это правило объясняется следующим:

1. Картежы отношений соответствуют объектам реального мира, а по определению эти объекты различимы, т.е некоторым образом опознаваемы.

2. Первичные ключи выполняют функцию уникальной идентификации объектов.

3. Если невозможно идентифицировать объект, то нельзя сказать существует ли он вообще.

Уточнение этого правила:

• Данное правило касается только базовых отношений, т.е не затрагивает вычисляемые и производные отношения.

• Данное правило применимо только для первичных ключей, для альтернативных ключей Null-значения могут быть или запрещены или разрешены.

Как используются Null-значений для внешних ключей.

1. Когда нет данных, т.е нет соответствующего картежы в ссылочном отношении, например нет данных о родителях ученика.

2. При каскадном удалении, например, на факультете расформировали одну из групп, а студентов этой группы распределяют в другие группы, но пока точно неизвестно в какие, тогда при каскадном удалении этой группы из таблицы Группа удалятся и все студенты этой группы из таблицы студенты, но нам этого не нужно, поэтому нужно временно заменить значение групп в отношении Студенты на Null-значение. Для избежания Null-значений можно использовать значение по умолчанию, например в БД Факультет для атрибута адрес используется значение по умолчанию «не известно».