Своя структура

Лавров Владислав (l-vv@r66.ru)

Спецвыпуск: Хакер, номер #052, стр. 052-024-5

Вторая нормальная форма требует соблюдения условий первой НФ, а также дополнительно каждый неключевой атрибут должен однозначно зависеть только от первичного ключа. Имеются ввиду функциональные зависимости из реальной предметной области. Здесь возникают проблемы с выявлением зависимостей, если первичный ключ является составным, то есть состоит из нескольких атрибутов.

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

Схема есть - ума не надо?

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

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

С обеспечением требований по ссылкам на другие таблицы дело обстоит сложнее. Лучше показать это на примере. Допустим, ты разрабатываешь базу данных для сопровождения своего форума, и тебе надо хранить информацию о зарегистрированных пользователях. Каждый пользователь состоит в определенной группе, в соответствии с которой ему назначены права (например, 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), поскольку его значения однозначно характеризуют объекты, представленные строками некоторого другого, внешнего отношения (то есть задают значения их первичного ключа). Отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.