Создание автоматизированной информационной системы (АИС) для учета деятельности авторемонтного предприятия
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
?асходных материалов, хранящий также данные об их наличии на складе. В качестве первичного ключа в этой сущности введен атрибут Шифр, который представляет собой уникальный номер МЦ.
Сущность Прейскурант представляется собой выполняемых на предприятии работ с указанием нормы времени и стоимости выполнения. В качестве первичного ключа в этой сущности введен атрибут Шифр, который представляет собой уникальный инвентарный номер МЦ.
Сущность Заказы содержит информацию о всех сформированных заказах. В качестве первичного ключа в этой сущности введен атрибут NЗаказа, который представляет собой уникальный номер.
Сущность ЗаказыПоставщику содержит информацию о всех сформированных заказах поставщику. В качестве первичного ключа в этой сущности введен атрибут NЗаказа, который представляет собой уникальный номер.
Атрибуты сущности МатЦенностиПоЗаказу обеспечивают хранение данных о всех МЦ по каждому заказу. Сущность содержит уникальный идентификатор ID.
Атрибуты сущности РаботыПоЗаказу обеспечивают хранение данных о всех работах по каждому заказу. Сущность содержит уникальный идентификатор ID.
Сущность Заявки содержит информацию о всех сформированных заявках на закупку МЦ. В качестве первичного ключа в этой сущности введен атрибут NЗаявки, который представляет собой уникальный номер.
Атрибуты сущности СоставЗаявки обеспечивают хранение данных о всех МЦ по каждой заявке. Сущность содержит уникальный идентификатор ID.
Атрибуты сущности СоставЗаказаПоставщику обеспечивают хранение данных о всех МЦ по каждому заказу поставщику. Сущность содержит уникальный идентификатор ID.
Сущность Счета содержит информацию о всех сформированных счетах. В качестве первичного ключа в этой сущности введен атрибут NСчета, который представляет собой уникальный номер.
Атрибуты сущности СоставСчета обеспечивают хранение данных о каждой позиции каждого счета. Сущность содержит уникальный идентификатор ID.
В сущности Мастера выделен внешний ключ СпециализацияID - поле связи с сущностью Специализации.
Сущность Авто содержит внешние ключи КлиентID (поле связи с сущностью Клиенты) и МаркаID (поле связи с сущностью МаркиАвто).
В сущности Заказы выделены внешние ключи:
КлиентID - поле связи с сущностью Клиенты;
МастерID - поле связи с сущностью Мастера;
ДиспетчерID - поле связи с сущностью Диспетчеры.
Сущность МатЦенностиПоЗаказу содержит внешние ключи МЦ_ID (поле связи с сущностью МатЦенности) и NЗаказа (поле связи с сущностью Заказы).
Сущность РаботыПоЗаказу содержит внешние ключи РаботаID (поле связи с сущностью Прейскурант) и NЗаказа (поле связи с сущностью Заказы).
В сущности Счета выделены внешние ключи NЗаказа (поле связи с сущностью Заказы) и ДиспетчерID (поле связи с сущностью Диспетчеры).
В сущности СоставСчета выделен внешний ключ NСчета - поле связи с сущностью Счета.
В сущности СоставЗаявки выделены внешние ключи NЗаявки (поле связи с сущностью Заявки) и МЦ_ID (поле связи с сущностью МатЦенности).
В сущности СоставЗаказаПоставщику выделены внешние ключи NЗаказа (поле связи с сущностью ЗаказыПоставщику) и МЦ_ID (поле связи с сущностью МатЦенности).
Нормализация предусматривает определение требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами. Отношение, в котором на пересечении каждой строки и каждого столбца содержится атомарное (или единственное) значение, находится в 1-й нормальной форме. При этом необходимо, чтобы отношение имело первичный ключ.
Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или больше атрибутов. Отношение с первичным ключом на основе единственного атрибута всегда находится в 2-й нормальной форме. Отношение, которое находится в 1-й нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, зависит только от полного значения ключа и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа, имеет вторую нормальную форму (каждый неключевой атрибут функционально полно зависит от ключа).
Отношение находится в 3-й нормальной форме, если оно представлено в 2-й нормальной форме и не имеет не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа [4].
Разработанная модель находится в 3-й нормальной форме, так как:
атрибуты сущностей являются атомарными;
каждый неключевой атрибут функционально полно зависит от первичного ключа;
в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.
Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей.
ER-диаграмма системы на физическом уровне представлена на рисунке 2.2 Соответствующая схема данных приведена в Приложении В.
Рисунок 2.2 - ER-диаграмма системы на физическом уровне
Физическое описание модели удобнее всего представить в виде таблиц. База данных проекта будет содержать таблицы, н