3.2. Целостность реляционных данных
В любой момент времени любая БД содержит некоторые определенные значения, которые выражают определенное состояние объекта реального мира. Следовательно, БД нуждается в определении неких правил целостности, необходимых для того, чтобы данные не вступили в противоречие с реальным миром. Такие правила целостности являются специфическими для каждой БД. Это, по сути, информирование СУБД об ограничениях реального мира, НАПРИМЕР, имя – только текстовое значение, значения веса, роста могут быть только положительные и т.д.
Но таких правил целостности недостаточно – не менее важно, чтобы данные внутри самой БД не противоречили друг другу.
НАПРИМЕР, чтобы предотвратить такие ситуации: в базе данных Факультет случайно указали, что Иванов Петр учится в группе ИНФ-15, но такой группы на данном факультете нет. Или для того же Петра группу указали правильно – ИНФ-13, но в качестве ФИО ее старосты написали Сидорова Н.М., а на самом деле старостой ИНФ-13 является Андреева С.В.
Для предотвращения подобных ситуаций существуют общие правила целостности реляционных данных. Эти правила связаны с первичными и внешними ключами.
3.2.1. Потенциальные, первичные и альтернативные ключи
Пусть R – некоторое отношение, тогда потенциальный ключ K для R это подмножество множества атрибутов R, для которого выполняются следующие свойства:
1) уникальность, т.е. нет двух различных кортежей в текущем значении переменной отношения R с одинаковыми значениями K;
2) неизбыточность, т.е. никакое подмножество K не обладает свойством уникальности.
НАПРИМЕР, в отношении Студенты потенциальным ключом могут являться атрибуты НомерЗачетки, НомерЛичногоДела или НомерПаспорта, т.к. каждый из них удовлетворяет определению. Но неверно будет назвать потенциальным ключом этого отношения множество нескольких из этих атрибутов, т.к. хотя для такого множества выполняется свойство уникальности, но не выполняется свойство неизбыточности.
Потенциальные ключи предназначены для обеспечения основного механизма адресации на уровне кортежей, т.е. по значению потенциального ключа можно однозначно найти кортеж. В СУБД Access потенциальные ключи называются также индексированными полями и обозначаются так: в свойстве поля Индексированное поле указывается значение «Да».
Базовое отношение может иметь несколько потенциальных ключей, но один их них должен быть выбран в качестве первичного ключа. Остальные же будут называться альтернативными. НАПРИМЕР, в таблице Специальности существует два потенциальных ключа: ШифрСпециальности и НазваниеСпециальности. Первичным ключом мы назначили ШифрСпециальности, тогда альтернативный ключ – НазваниеСпециальности.
В СУБД Access для первичного ключа значением свойства Индексированное поле указывается значение «Да (совпадения не допускаются)», а для альтернативного может быть такое же или «Да (совпадения допускаются)».
В любом отношении должен быть первичный ключ, значит должен содержаться хотя бы один потенциальный ключ (это может быть одно поле, а может быть множество нескольких или даже всех атрибутов отношений).
Если же в базовом отношении нет естественных потенциальных ключей или они неудобны в рамках создаваемой БД, то вводят искусственные ключи (НАПРИМЕР, КодПреподавателя, чтобы не использовать номер паспорта, номер личного дела или табельный номер).
Нашел сайт, где можно быстро сказать отличные увлекательные сюжетно-ролевые игры и развлекаться весь день
Читайте интересный блог про огород, где можно узнать, как лучше всего ухаживать за растениями, как поливать и пропалывать, избавляться от вредителей и многое другое. Ваш огород будет процветать.
Почитайте форум рыбаков и вы узнаете немало интересного