Построение логической модели

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

Например, в сущность «Oplata» добавляются атрибуты «Useri» (Id клиента – первичный ключ сущности «Useri»). Таким же образом добавляются атрибуты и в другие сущности.

Добавленные, в сущности-потомки, атрибуты являются внешними ключами для сущностей-предков, в которых данные атрибуты являются первичными ключами. Логическая модель приведена на (рис. 3.1).

Рисунок 3.1 Логическая модель

Целостность данных

Целостность объекта

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

Например, в нашей базе данных в отношение «Пользователь» при вставке информации о новом клиенте, необходимо сначала вставить значение в поле, являющееся первичным ключом («id»), а затем уже заносить информацию в остальные поля. Аналогично и с удалением, например, при удалении картежа из таблицы «Dogovor», необходимо сначала удалить информацию из вторичных атрибутов, а затем уже удалять значение первичного ключа. Целостность объекта реализуется самой СУБД, и обычно пользователю нет необходимости об этом беспокоиться.

Целостность приложения

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

В базе данных «Провайдер» это отношения «Usluga» (хотя, возможность изменения этой таблицы реализована в приложении).

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