Экономическая информатика-стр.258

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

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

Прежде всего СУБД должна знать, что она работает с несколькими информационно связанными объектами, ей должны быть известны структура и смысл каждого поля (например, что Номер сотрудника в объекте СОТРУДНИКИ и Исполнитель в объекте ДОГОВОРЫ означают одно и то же), а также понимать, что в ряде случаев изменение информации в одном объекте должно вызывать модификацию второго объекта, чтобы их общее содержимое было согласованным. Например, если заключается новый договор, то необходимо добавить запись в объект ДОГОВОРЫ, а также соответствующим образом изменить объект ПОСТАВКИ.

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

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