Рисунок 9 – декомпозиция процесса A21 “ Организовать работу сотрудников ” 

      Блок  «Организовать увольнение сотрудников» процесса А2 разбиваем на 2 блока – «Вывод информации о стаже рабочего» и «Вывод информации о должности рабочего» (рисунок 10).

Рисунок 10 – декомпозиция процесса A22 “ Организовать увольнение сотрудников ”

      Блок  «Организовать работу с новыми рабочими» процесса А2 разбиваем на 3 блока – «Вывод информации о новом рабочем» и «Поиск окладарабочего» и «Вывод бригад с минимальным количеством человек» (рисунок 11).

Рисунок 11 – декомпозиция процесса A23 “ Организовать работу с новыми рабочими ” 

      Блок  «Организовать работу отдела поставок» процесса А3 разбиваем на 3 блока – «Вывод информации о количестве материала для объекта» и «Вывод информации о материале для объекта» и «Вывод стоимости всех материалов для объекта» (рисунок 12).

Рисунок 12 – декомпозиция процесса A31 “ Организовать работу отдела поставок ” 

      Блок  «Организовать новые поставки материала» процесса А3 разбиваем на 2 блока – «Вывод информации о поставщике» и «Вывод информации о поставляемом материале» (рисунок  13).

Рисунок 13 – декомпозиция процесса A32 “ Организовать новые поставки материала ” 

      Блок  «Организовать работу с услугами» процесса А4 разбиваем на 2 блока – «Вывод информации о стоимости материалов для объекта» и «Вывод информации о предоставляемых услугах» (рисунок  13).

Рисунок 14 – декомпозиция процесса A41 “ Организовать работу с услугами ” 

Блок «Организовать учет работы» процесса А4 разбиваем на 2 блока – «Вывод информации о законченных заказах» и «Поиск информации об объектах по дате здачи заказа» (рисунок  15).

Рисунок 15 – декомпозиция процесса A41 “ Организовать учет работы ”

 

2.1.2. Диаграмма дерева  узлов

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

       На диаграмме дерева узлов  нижний уровень детализации представляется в виде списка, остальные процессы в виде прямоугольников.

     Диаграмма дерева узлов проектируемой базы данных представлена на рисунке 16. На диаграмме отражены 4 уровня. Диаграмма дерева узлов с четырьмя уровнями представлена в приложении А.

Рисунок 16 – Диаграмма дерева узлов

 

      2.2. Информационная  модель

     2.2.1 Идентификация сущностей и связей. ER-диаграмма логического уровня.

     Erwin имеет два уровня представления модели – логический и физический. Логический уровень – это абстрактный взгляд на данные. Объекты модели, представляемые на нем, называются сущностями и атрибутами. Логическая модель данных является универсальной, т.к. не зависит от конкретной СУБД.

     Для отображения информационной модели рассматриваемого процесса на логической модели используются следующие сущности:

     - «Бригады» – для хранения информации о бригадах,в которые формируются сотрудники. Содержит номер бригады, номер заказа, ФИО бригадира и количество человек в бригаде;

     - «Сотрудники» – для хранения информации о сотрудниках, которые работают на фирме. Содержит табельный номер сотрудника, ФИО, стаж работы, размер оклада, занимаемую должность, номер бригады, в котором работает сотрудник, а также номер паспорта и адрес проживания;

     - «Клиенты» – для хранения информации  о клиенте, которые пользуются услугами данной фирмы. Содержит номер клиента, дату заказа, а так же информацию об ответственном лице;

     - «Услуги» – для хранения информации о услугах, предоставляемых клиентам. Содержит наименование услуги, номер услуги и её стоимость;

     - «Заказы» – для хранения информации о объектах, которые были заказаны клиентом. Содержит номер заказа, адрес заказанного объекта, а также дату предпологаемой здачи объекта клиенту;

     - «Материалы» – для хранения информации о материалах, которые необходимы для выполнения услуг на заказанных объектах. Содержит код материала, стоимость материала, наименование материала, а также общее количество заказанного материала;

     - «Поставщики» – для хранения информации о поставщиках, которые поставляют разнообразные материалы. Содержит идентификационный номер, название организации, адрес организации, телефон организации и email;

     Для однозначного определения записей  в каждом из отношений выделен первичный ключ (простой или составной).

     Внешние ключи для отношений БД:

     в отношениях «Сотрудники» и «Бригады» - это ключ «Номер_бригады»;

     в отношениях «Бригады» и «Заказы» - это ключ «Номер_заказа»;

     На  логическом уровне проектирования в  моделируемой базе данных присутствуют следующие  типы связей между описанными сущностями:

• неиденцифицирующие связи;
• иденцифицирующие связи;
• связи многие-ко-многим

     Связь между сущностями «Бригады» и «Сотрудники» неидентифицирующая, т.к. для однозначной идентификации сотрудника необязательно знать его бригаду, в которой он работает. Тип связи 1 ко многим, т.к. в одной бригаде могут работать много сотрудников, но сотрудник может работать только в одной бригаде.

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

     Связь между сущностями «Заказ» и «Материалы» многие-ко-многим, т.к. один заказ может нуждаться в нескольких типах материалов, а материал может быть нужен на  нескольких объектах.

     Связь между сущностями «Заказ» и «Услуги» многие-ко-многим, т.к. один заказ может нуждаться в нескольких услугах, а одна услуга может быть востребована на нескольких объектах.

     Связь между сущностями «Поставщики» и «Материалы» многие-ко-многим, т.к. один поставщик может поставлять несколько материалов, а один материал может поставляться несколькими поставщиками.

     Связь между сущностями «Услуги» и «Клиенты» многие-ко-многим, т.к. один клиент может нуждаться в нескольких услугах, а одна услуга может быть востребована несколькими клиентами.

     ER-диаграмма логического уровня представлена на рисунке 15 и в приложении Б.

     Рисунок 15 – ER-диаграмма логического уровня

    2.2.2. ER-диаграмма физического уровня. Ограничения доменов. Ограничения ссылочной целостности. Переопределение триггеров. Индексирование отношений

     Физическая  модель данных зависит от конкретной СУБД. В ней содержится информация обо всех объектах БД.  Одной и той же логической модели может соответствовать несколько разных физических. В физической модели необходимо описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах. 

     SQL-сервер 7.0 не поддерживает домены, поэтому в данной БД не реализованы ограничения доменов.

     Первая  нормальная форма требует, чтобы  значения всех атрибутов отношения  были атомарными. При рассмотрении информационной модели было определено, что значения атрибутов всех отношений логически разделить на элементы нельзя и, следовательно, они удовлетворяют условию первой нормальной формы. Например, в таблице «Сотрудники». Ключевой атрибут в ней – «табельный_номер» не может быть разделен на элементы.

     Вторая  нормальная форма требует, чтобы  отношение находилось в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависел от первичного ключа. И это требование также выполняется в рассматриваемой модели. Пример, рассмотрим таблицу «Сотрудники». Ключевой атрибут в ней – «табельный_номер». Не ключевые атрибуты – «ФИО», «Должность», «Телефон», «Оклад», «Стаж», «Номер_паспорта», «Номер_соц_страховки»   зависят функционально полно  только от первичного ключа.

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

     Реализация  ссылочной целостности:

• При изменении информации о какой-либо бригаде из таблицы «Бригады» в таблице «Сотрудники» информация будет автоматически меняться (каскадное обновление). Разрешается удаление информации только в том случае, когда на данную информацию нет ссылок в других связанных таблицах;
• При изменении информации о каком-либо заказе из таблицы «Заказы» в таблице «бригады» информация будет автоматически меняться (каскадное обновление). Разрешается удаление информации только в том случае, когда на данную информацию нет ссылок в других связанных таблицах;

     Типы  данных

     1. Рассмотрим таблицу «Клиенты».  Ключевое поле этой таблицы  «Номер_клиента» содержит номер клиента по списку. Номер представляет собой набор цифр. Следовательно, тип данных поля «Номер_клиента» должен быть числовым целым. Выбираем тип int.

     2. В таблице «Заказы» имеется поле «Дата_здачи». Это поле содержит число, месяц, год даты, когда была выполнена услуга. Тип данных для неё – datetime.

     3. В таблице «Сотрудники» имеется поле «Адрес». Это поле содержит адрес сотрудника, который работает на этой фирме.Адрес представляет собой набор цифр и символов. Тип данных для неё – varchar[255]. 

     Для приложения были разработаны следующие  триггеры:

     proverka_Clientov ввод значения в поле «дата_заказа», если оно превышает номер текущего года;

     proverka_Uslugi записывает при добавлении записей в таблицу «услуги» в отдельную таблицу информацию о дате добавления и пользователе. Перед созданием такого триггера необходимо создать таблицу TrUskugi, куда будет производиться запись;

     proverka_Sakazi записывает при добавлении записей в таблицу «заказы» в отдельную таблицу информацию о дате добавления и пользователе. Перед созданием такого триггера необходимо создать таблицу TrSakazi, куда будет производиться запись;

     proverka_Postav записывает при добавлении записей в таблицу «поставщики» в отдельную таблицу информацию о дате добавления и пользователе. Перед созданием такого триггера необходимо создать таблицу TrPostav, куда будет производиться запись;

     proverka_Mater записывает при добавлении записей в таблицу «услуги» в отдельную таблицу информацию о дате добавления и пользователе. Перед созданием такого триггера необходимо создать таблицу TrMater, куда будет производиться запись;

     T_uslugi_1  записывает при удалении записей из таблицы «услуги» в отдельную таблицу информацию о удаленной услуге. Перед созданием такого триггера необходимо создать таблицу uslugi_ud, куда будет производиться запись;

     T_zakazy_1 записывает при удалении записей из таблицы «заказы» в отдельную таблицу информацию о удаленном заказе. Перед созданием такого триггера необходимо создать таблицу zakaz_ud, куда будет производиться запись;

     T_postavchik_1 записывает при удалении записей из таблицы «поставщики» в отдельную таблицу информацию о удаленном поставщике. Перед созданием такого триггера необходимо создать таблицу postavchik_ud, куда будет производиться запись;