• Категорная целостность

• Целостность на уровне ссылок

• Функциональные зависимости.

Ог­раничительные условия обеспечивают логическую основу для поддержания правильных значений данных в базе данных, предупреждая ошибки при обновлении и обработке данных.

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

Категорная целостность. Строки реляционной таблицы представляют в базе данных элементы конкретных объектов реального мира или категорий (как мы будем называть их здесь, в соответствии с реляционной терминоло­гией). Например, строка таблицы WORKER представляет конкретного слу­жащего, строка таблицы BUILDING представляет конкретное здание, строка таблицы ASSIGNMENT представляет конкретное назначение работника на данное здание и т.д. Ключ реляционной таблицы однозначно определяет ка­ждую строку и, следовательно, каждый элемент категории. Таким образом, если пользователи хотят извлекать данные конкретной строки или манипу­лировать ими, они должны знать значение ключа этой строки. Отсюда сле­дует, что мы не хотим, чтобы элемент записывался в базу данных до тех пор, пока значения его ключевых атрибутов не будут полностью определены. Таким образом, мы не можем позволить ключу или любой части ключа иметь пустое значение. Это формулируется в правиле категорией целостности:

Никакой ключевой атрибут любой строки реляционной таблицы не мо­жет иметь пустого значения.

Целостность на уровне ссылок. При построении реляционных таблиц для связывания строк одной таблицы со строками другой таблицы исполь­зуются внешние ключи. Например, SKILL-TYPE используется в таблице WORKER Для того чтобы сообщить нам основную специальность каждого работника, чтобы можно было подсчитать размер премиальных. Таким обра­зом, чрезвычайно важно, чтобы значение атрибута SKILL-TYPE каждой строки, обозначающей служащего, соответствовал некоторому значению ат­рибута SKILL-TYPE таблицы SKILL. В противном случае SKILL-TYPE слу­жащего ни на что не будет указывать. База данных, в которой все непустые внешние ключи ссылаются на текущие значения ключей другой реляцион­ной таблицы, обладает целостностью на уровне ссылок. Таким образом, мы получили правило целостности на уровне ссылок:

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

Функциональные зависимости обсуждаются далее.

2. Нормализации отношений

Рассмотрим реляционную таблицу на рис. 4, в которой частично со­вмещены данные таблиц WORKER и ASSIGNMENT. В этом разделе мы бу­дем предполагать, что реляционная схема базы данных не была получена из концептуальной модели, а была создана напрямую на основе информации, полученной от потенциальных пользователей базы данных. Мы также счи­таем, что исходный проект базы данных не содержит таблиц, приведенных на рис. 3, а содержит таблицу, приведенную на рис. 4. Мы хотим по­смотреть, какие проблемы могут возникнуть из-за небрежного проектирова­ния базы данных и как избежать подобных проблем при помощи стандарт­ных принципов, называемых нормализацией.

Нормализация. Процесс приведения реляционных таблиц к стандартному виду.

После небольшого анализа легко видеть, что реляционная таблица на рис. 4 спроектирована неудачно. Например, в четырех кортежах, соответ­ствующих рабочему 1412, повторяется одно и то же имя и информация о типе специальности. Эта избыточность данных или повторение приводит не только к потере лишнего места, она может вызвать нарушение целостности данных (противоречивость) в базе данных.

Рис. 4. Другая версия реляционной таблицы WORKER

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

Избыточность данных. Повторение данных в базе данных.

Целостность данных. Согласованность данных в базе данных.

Аномалия обновления. Противоречивость данных, вызванная их избыточно­стью и частичным обновлением.

Теперь предположим, что К.Немо в течение трех месяцев был на боль­ничном, и все здания, на которых он был назначен работать, уже закончены. Если принимается решение удалить все строки о законченных зданиях из таблицы, то информация об идентификаторе К. Немо, его имени и специальности будет потеряна. Это называется аномалией удаления.

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

Аномалия удаления. Непреднамеренная потеря данных, вызванная удалением других данных.

Аномалия ввода. Невозможность ввести данные в таблицу, вызванная отсутст­вием других данных.

Аномалии обновления, удаления и ввода, очевидно, нежелательны. Как предотвратить или хотя бы свести к минимуму подобные проблемы? Оче­видно, нужно разделить реляционную таблицу WORKER рис. 4 на две ре­ляционные таблицы, WORKER и ASSIGNMENT, как показано на рис. 3, тогда аномалий не возникнет. Это интуитивное решение. Сейчас мы предста­вим более формальный метод, называемый разбиением, приводящий к тому же результату.

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

Разбиение таблиц. Разделение таблицы на несколько таблиц.

Примечание. Иногда вместо термина «разбиение» используют термин «операция проекции».