Теоретическая часть. Модель данных, основанная на ключах – это логическая модель, включающая описание всех сущностей и ключевых атрибутов

Модель данных, основанная на ключах – это логическая модель, включающая описание всех сущностей и ключевых атрибутов, которые соответствуют предметной области.

Целью этой модели является дальнейшая детализация модели сущность-связь и идентификация сущностей путем выбора ключевых атрибутов (ключей).

Первичный ключ – это набор атрибутов, значение которых однозначно определяют каждый экземпляров сущности.

В качестве первичных ключей могут быть использовано несколько атрибутов или групп атрибутов. Атрибуты, которые могут быть выбраны первичными ключами, называются кандидатами в ключевые атрибуты (потенциальные атрибуты).

Правила выбора первичного ключа:

· Уникальным образом идентифицировать экземпляр сущности.

· Не использовать NULL значений.

· Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.

· Быть как можно более короткими для использования индексирования и получения данных.

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

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

Суррогатный ключ – это произвольный номер, который уникальным образом определяет запись в сущности. Атрибут «Номер сотрудника» является примером суррогатного ключа.

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

Альтернативный ключ – это потенциальный ключ, который не выбран первичными. С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы.

Внешний ключ – это атрибут(ы) первичного ключа родительской сущности, переданные дочерней сущности через их связь.

При генерации схемы базы данных на основе опций логической модели, задаваемых во вкладке Rolename/RI Actions, будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостности.

Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT, UPDATE или DELETE).

Например, между сущностями Агент и Филиал существует идентифициующая связь. Что будет, если удалить филиал? Экземпляр сущности Агент не может существовать без филиала (атрибут первичного ключа «В каком филиале работает/Номер филиала» не может принимать значение NULL); следовательно, нужно либо запретить удаление филиала, пока в ней числится хотя бы один агент.

Возможна установка следующих правил удаления (если таковые поддерживаются СУБД).

SET DEFAULT – при удалении записи атрибуту внешнего ключа присваивается значение по умолчанию. Например, при удалении филиала фирмы все агенты могут быть переведены в другой филиал.

NONE – при удалении записи значение атрибута внешнего ключа не меняется. Запись об агенте «повисает в воздухе», т. е. ссылается на несуществующий филиал. Такая ситуация характерна для «плоских» таблиц. Например, если информация об агентах и филиалах фирмы хранится в dbf-файлах, можно удалить запись о филиале, при этом файл агентов «ничего не будет знать» о том, что соответствующего филиала не существует. Поэтому в настольных или файл-серверных системах функциональность, обеспечивающая правила ссылочной целостности, реализуется в клиентском приложении.

RESTRICT – для удаления записи необходимо удалить все дочерние записи с внешним ключом, равным первичному ключу удаляемой записи. Например, для удаления филиала сначала нужно удалить всех агентов этого филиала.

CASCADE. – при удалении опорного экземпляра сущности (соответствующего концу связи «один») нужно удалить и все экземпляры сущности, соответствующие концу связи «многие». Например, вместе с филиалом фирмы будут удаляться все агенты данного филиала.

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