2.1.1 Логическое проектирование

В разрабатываемой системе можно выделить следующие сущности: Группы, Заказы, ЗаказыПоставщику, Клиенты, МатЦенности, МатЦенностиПоЗаказу, Менеджеры, Прейскурант, Работники, Реквизиты, СоставЗаказа, СоставЗаказаПоставщику, Специализации.

ER-диаграмма системы на логическом уровне представлена на рис. 2.1.

Рис. 2.1. ER-диаграмма системы на логическом уровне

Сущности Реквизиты, Клиенты, Специализации и Менеджеры хранят информацию об объектах системы, соответствующих их названиям. В качестве первичного ключа в сущностях Клиенты и Специализации введен атрибут ID, который представляет собой уникальный номер. Для сущности Менеджеры первичным ключом является уникальный табельный номер ТабN.

Сущность Работники содержит информацию о работниках компании. Первичным ключом является уникальный табельный номер ТабN.

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

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

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

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

Атрибуты сущности МатЦенностиПоЗаказу обеспечивают хранение данных обо всех аксессуарах по каждому заказу.

Атрибуты сущности СоставЗаказа обеспечивают хранение данных обо всех производимых изделиях по каждому заказу.

Атрибуты сущности СоставЗаказаПоставщику обеспечивают хранение данных обо всех аксессуарах по каждому заказу поставщику.

В сущности Работники выделен внешний ключ СпециализацияID  поле связи с сущностью Специализации.

В сущности Заказы выделены внешние ключи:

– КлиентID – поле связи с сущностью Клиенты;

– РаботникID – поле связи с сущностью Работники;

– МенеджерID – поле связи с сущностью Менеджеры.

Сущность МатЦенностиПоЗаказу содержит внешние ключи МЦ_ID (поле связи с сущностью МатЦенности) и NЗаказа (поле связи с сущностью Заказы). Эти поля вместе образуют первичный ключ.

Сущность СоставЗаказа содержит внешние ключи РаботаID (поле связи с сущностью Прейскурант) и NЗаказа (поле связи с сущностью Заказы). Эти поля вместе с полем Дата образуют первичный ключ.

В сущности СоставЗаказаПоставщику выделены внешние ключи NЗаказа (поле связи с сущностью ЗаказыПоставщику) и МЦ_ID (поле связи с сущностью МатЦенности). Эти поля вместе образуют первичный ключ.

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

Выделяют три группы правил целостности [4, 9]:

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

 Целостность по ссылкам. База данных не должна содержать несогласованных значений внешних ключей. Правило утверждает, что если В ссылается на А, тогда А должно существовать. Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом. Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в таблице, на которую ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).

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

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

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

Нормализация предусматривает определение требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами. Отношение, в котором на пересечении каждой строки и каждого столбца содержится атомарное (или единственное) значение, находится в 1-й нормальной форме. При этом необходимо, чтобы отношение имело первичный ключ [9, 12].

Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или больше атрибутов. Отношение с первичным ключом на основе единственного атрибута всегда находится во 2-й нормальной форме. Отношение, которое находится в 1-й нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, зависит только от полного значения ключа и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа, имеет вторую нормальную форму (каждый неключевой атрибут функционально полно зависит от ключа) [9, 12].

Отношение находится в 3-й нормальной форме, если оно представлено в 2-й нормальной форме и не имеет не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа [9, 12].

Разработанная модель находится в 3-й нормальной форме.