Курсовые работы / ПРИС К_2

3.Определить первичный ключ отношения.

4.Для каждой функциональной зависимости fi создать проекцию исходного отношения Ri = R[Xi], где Xi – объединение атрибутов из левой и правой частей fi.

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

Проверим сущности «Запчасти», «Отделы», «Профилактика», «Работы», «ПО» и «Заявка» на соответствие 3НФ.

Рассмотрим сущность Запчасти, представленную в таблице 2.2.

Таблица 2.2 – Сущность «Запчасти»

Zapchact

Ключом данной сущности будет атрибут – Id. Для более краткой записи процесса нормализации введем следующие обозначения: I – код запчасти, Z –

наименование запчасти, E – единица измерения материала, K – количество на складе, P – изображение запчасти. Выпишем функциональные зависимости:

I -> Z, E, K, P; I -> Z; I -> E; I -> K; I -> P.

Рассмотрим отношение R(I, Z, E, K, P) с ключом I. Здесь есть функциональные зависимости I -> Z, I -> E, I -> K, I -> P. Так как каждый не ключевой атрибут зависит от первичного ключа, то отношение R(I, Z, E, K, P)

находится в 3НФ по определению, что и требовалось доказать.

Теперь рассмотрим сущность Отделы, представленную в таблице 2.3.

Таблица 2.3 – Сущность «Отделы»

Otd

23

Ключом данной сущности будет атрибут – Id. Для более краткой записи процесса нормализации введем следующие обозначения: I – код отдела, O –

наименование отдела, R – руководитель отдела, K – кабинет, T – телефон.

Выпишем функциональные зависимости: I -> O, R, K, T; I -> O; I -> R; I -> K; I -> T

Рассмотрим отношение R(I, O, R, K, T) с ключом I. Здесь есть функциональные зависимости I -> O; I -> R; I -> K; I -> T. Так как каждый не ключевой атрибут зависит от первичного ключа, то отношение R(I, O, R, K, T)

находится в 3НФ по определению, что и требовалось доказать.

Далее рассмотрим сущность Профилактика, представленную в таблице 2.4.

Таблица 2.4 – Сущность «Профилактика»

Profilact

Ключом данной сущности будет атрибут – Id. Для более краткой записи процесса нормализации введем следующие обозначения: Id – код профилактики, D – дата проведения профилактики, IO – код отдела, O – объект профилактики, OV – отметка выполнения. Выпишем функциональные зависимости: Id -> D, IO, O, OV; Id -> D; Id -> IO; Id -> O; Id -> OV

Рассмотрим отношение R(Id, D, IO, O, OV) с ключом Id. Здесь есть функциональные зависимости Id -> D; Id -> IO; Id -> O; Id -> OV. Так как каждый не ключевой атрибут зависит от первичного ключа, то отношение R(Id, D, IO, O, OV) находится в третьей нормальной форме (3НФ) по определению,

что и требовалось доказать.

Рассмотрим сущность Работы, представленную в таблице 2.5.

Таблица 2.5 – Сущность «Работы»

Rabota

24

Ключом данной сущности будет атрибут – Id. Для более краткой записи процесса нормализации введем следующие обозначения: I – код работы, R –

наименование работы, EI – единица измерения, IZ – код запчасти, KZ –

количество требуемых запчастей. Выпишем функциональные зависимости: I -> R, EI, IZ, KZ; I -> R; I -> EI; I -> IZ; I -> KZ

Рассмотрим отношение R(I, R, EI, IZ, KZ) с ключом I. Здесь есть функциональные зависимости I -> R; I -> EI; I -> IZ; I -> KZ. Так как каждый не ключевой атрибут зависит от первичного ключа, то отношение R((I, R, EI, IZ, KZ) находится в 3НФ по определению, что и требовалось доказать.

Рассмотрим предпоследнюю сущность ПО, представленную в таблице 2.6.

Таблица 2.6 – Сущность «ПО»

Prog

Ключом данной сущности будет атрибут – Id. Для более краткой записи процесса нормализации введем следующие обозначения: I – код ПО, Pn –

наименование ПО, D – дата установки, IO – код отдела, L – наличие лицензии, Do – дата окончания действия лицензии. Выпишем функциональные зависимости: I -> Pn, D, IO, L, Do; I -> Pn; I -> D; I -> IO; I -> L; I -> Do

Рассмотрим отношение R(I, Pn, D, IO, L, Do) с ключом I. Здесь есть функциональные зависимости I -> Pn; I -> D; I -> IO; I -> L; I -> Do. Так как каждый не ключевой атрибут зависит от первичного ключа, то отношение R(I, Pn, D, IO, L, Do) находится в 3НФ по определению, что и требовалось доказать.

Рассмотрим последнюю сущность Заявка, представленную в таблице 2.7.

Таблица 2.71 – Сущность «Заявка»

Zaavka

25

Таблица 3.3 – Таблица «Профилактика»

Таблица 3.4 – Таблица «Запчасти»

Таблица 3.5 – Таблица «Установленное ПО»

Таблица 3.6 – Таблица «Заявки»

28

Для создания платформы (scaffold) Otd, которая состоит из модели,

представления и контроллера, записывается в консоли следующая команда: rails

generate scaffold Otd O_name:string Rucovod:string Telef:string Kab:integer status:boolean

s_delete:boolean

При генерации платформы был создан файл-миграция, в нем находятся сведения о структуре таблицы, которые необходимо внести в БД. Для этого

пропишем в консоли следующую команду: rake db:migrate

Создадим остальные платформы. Запишем последовательно в консоли (не

забывая затем выполнять команду добавления миграций в БД (rake db:migrate)):

s_delete:boolean

для создания платформы Profilact: rails generate scaffold Profilact Data:date otd:belongs_to object:string status:boolean Otm_v:boolean s_delete:boolean

для создания платформы Zaphact: rails generate scaffold Zaphact z_name:string Ed_izm:string Kolvo:integer Foto:string status:boolean s_delete:boolean

для создания платформы Prog: rails generate scaffold Prog p_name:string data:date otd:belongs_to licens:boolean data_ok:date Photo:string status:boolean

s_delete:boolean

для создания платформы Zakaz: rails generate scaffold Zakaz data:date otd:belongs_to rabotum:belongs_to otm_v:boolean status:boolean s_delete:boolean

Таким образом, было создано шесть платформ (справочников), которые после выполнения команды rake db:migrate были созданы в БД. Проверить факт наличия таблиц можно, открыв pgAdmin и зайдя в БД «Otdel». Найти их можно в ветке таблицы.

3.2 Описание программных модулей

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

29

программных модулей.

ПМ авторизации

ПМ главного меню

30

Схема взаимосвязи программных модулей должна содержать базу данных и составные части (модули) и отражать связь между ними. На рисунке 3.2

изображена схема взаимосвязи модулей и массивов данных.

Рисунок 3.2 – Схема взаимосвязи модулей и массивов данных

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

3.3 Реализация программных модулей

Отчет – представление требуемых данных в виде удобном для просмотра

ипечати.

Вданном web-приложении реализовано четыре отчета. Рассмотрим отчет

«Заявки за период времени». Данный отчет выводит код, наименование отдела,

название работы, дату создания и отметку выполнения в зависимости от того,

какой период был задан пользователем. Алгоритм работы этого отчета представлен на рисунке 3.3.

31