СХЕМА ЕСТЬ - УМА НЕ НАДО?

После определения основных объектов и характеризующих их ат­рибутов надо продумать "поведен­ческие" аспекты твоей базы данных. Другими словами, определить, что будет происходить при вставке, кор­ректировке и удалении реальных за писей. Останутся ли при этом данные в твоей базе правильными? Не поя­вится ли в ней противоречивая ин­формация? Эти вопросы порождают известную в теории проблему обес­печения целостности данных. Целост­ность бывает двух видов: целост­ность сущностей и целостность по ссылкам.

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

С обеспечением требований по ссылкам на другие таблицы дело обс­тоит сложнее. Лучше показать это на примере. Допустим, ты разрабатыва­ешь базу данных для сопровождения своего форума, и тебе надо хранить информацию о зарегистрированных пользователях. Каждый пользова­тель состоит в определенной группе, в соответствии с которой ему назна­чены права (например, administrators, moderators, registered, banned и т.д.). При правильном проектировании структуры у тебя появятся две свя­занные таблицы:

USERS (id_user, user_login, user_mail, user_icq, fk_id_group), первичный ключ id_user;

GROUPS (id_group, name_group, rights) пер­вичный ключ id_group

Атрибут fk_id_group появляется в таблице USERS не потому, что номер группы является собственным свой­ством пользователя, а лишь для то­го, чтобы при необходимости восста­новить полную информацию о груп­пе. Значение атрибута fk_id_group в любой строке таблицы USERS долж­но соответствовать значению атри­бута id_group в некоторой строке таблицы GROUPS. Такой атрибут на­зывается внешним ключом (foreign key), поскольку его значения одноз начно характеризуют объекты, представленные строками некоторо­го другого, внешнего отношения (то есть задают значения их первичного ключа). Отношение, в котором опре­делен внешний ключ, ссылается на соответствующее отношение, в кото­ром такой же атрибут является пер­вичным ключом.

Требование целостности по ссыл­кам состоит в том, что для каждого значения внешнего ключа в таблице, к которой ведет ссылка, должна най­тись строка с таким же значением первичного ключа. Или значение внешнего ключа должно быть неоп ределенным, то есть ни на что не указывать. В нашем примере это оз­начает, что если для пользователя форума указан номер группы, эта группа должна обязательно сущест­вовать в таблице GROUPS.

Каким образом обеспечить ссылоч­ную целостность? Понятно, что при обновлении ссылающегося отноше­ния (например, в таблице USERS вставляешь новые строки или кор­ректируешь значения внешнего клю­ча, то есть переводишь пользовате­ля в новую группу) достаточно сле­дить за тем, чтобы не появлялись не­корректные значения внешнего клю­ча. Но как быть при удалении из таб­лицы строки, к которой ведет ссыл­ка? Предусмотрены две возможные операции: каскадирование (cascade) или ограничение (restrict). Эти опера­ции можно установить на связь меж­ду двумя таблицами.

При каскадировании удаление строк в таблице приводит к удале­нию соответствующих строк в свя­занном отношении. Например, уда­ление информации о какой-нибудь группе приведет к удалению инфор­мации о всех пользователях этой группы. Подумай, нужно ли тебе та­кое? Если установить на связь опе­рацию ограничения, то будут уда­ляться лишь те строки, для которых связанной информации в другой таблице нет. Если такая информа­ция имеется, то удаление осущест­вить нельзя. В этом случае сначала нужно или удалить ссылающиеся строки, или соответствующим обра­зом изменить значения их внешнего ключа. Например, удаление инфор­мации о какой-либо группе на фору­ме возможно выполнить в том слу­чае, если в этой группе нет ни одно­го пользователя.

Необходимо также предусмотреть технологию того, что будет происхо­дить при попытке обновления пер­вичного ключа отношения, на кото­рое ссылается некоторый внешний ключ. Здесь имеются те же возмож­ности, что и при удалении: можно каскадировать или ограничить опе­рацию. Например, ты захотел изме-ненить id_group в таблице GROUP на форуме и одновременного отразить все изменения на заинтересованных пользователях в таблице USERS. Тогда установи операцию каскадиро­вания при обновлении данных на связь между этими таблицами.

В современных реляционных СУБД, как правило, можно выбрать способ поддержания целостности по ссыл­кам для каждой отдельной ситуации определения внешнего ключа. Ко­нечно, для принятия такого решения необходимо тщательно анализиро­вать требования конкретной пред­метной области.