Введение

           Целью курсового проекта по дисциплине “Банки и базы данных” является проектирование многопользовательской информационной системы.

           Система автоматизации деятельности частной строительной фирмы “Ручей” предназначена для унификации и систематизации данных о клиентах , персонале и фирмы, проведенных работах, планирования работы, прием заказов, анализа и мониторинга деятельности строительной фирмы её руководством.

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

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

           Основная задача данного курсового проекта состоит в закреплении навыков моделирования баз данных и бизнес - процессов  с применением Case-пакетов  All Fusion ERwin Data Modeler    и Process Modeler 4.1, усвоении и закреплении навыков проектирования и реализации баз данных Microsoft SQL Server 2000, с применением СУБД Microsoft ACCESS  2007 для создания многопользовательского интерфейса и языка баз данных T-SQL для запроса к базам данных SQL Server, управления и манипулирования данными, хранящимися в БД.

           Важной частью работы является разработка пользовательского интерфейса. Microsoft Visual Studio 2008 представляет множество средств его создания, а также для управления и манипулирования данными. Необходимо учесть все тонкости работы в данной предметной области, чтобы создать удобный интерфейс, который обладал эстетической привлекательностью и в то же время в полной мере – функциональностью.

 

           1.  Техническое задание

           1.1. Анализ предметной области

           1.1.1 Общие сведения

           Объект автоматизации – частная строительная фирма “Ручей ”.

           1.1.2 Документы, на основании которых создаётся система

• информация о дате заказа;
• информация о месте проведения работ;
• перечень оказываемых услуг;
• личные дела сотрудников;
• прейскурант на оказываемые услуги.

     1.1.3 Назначение и цели создания  системы

     1.1.3.1 Назначение системы

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

           1.1.3.2 Цели создания системы

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

           1.1.4 Характеристика объекта автоматизации

           Более подробно рассмотрим инфраструктуру строительной фирмы. Пользователями базы данных будут директор (основатель фирмы), сотрудники, работающий в отделе кадров,услуг и администратор.

           Теперь рассмотрим более подробно функции каждого пользователя системы.

     Функции директора:

• координация полной работы сотрудников;
• формирование рабочего распорядка фирмы;
• приём на работу новых сотрудников и увольнение персонала.

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

     Функции заказчик:

• составления заказа;

     Информация, подлежащая хранению: имя и фамилия заказчика, табельный номер, дата здачи объекта.

           Функции персонала, работающего в отделе кадров,услуг:

• регистрация новых клиентов:
• поиск об объеках работы;
• поиск сроков окончания.

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

     1.1.5 Требования к системе

      1.1.5.1 Требования к системе в целом

Система должна удовлетворять следующим  требованиям:

1. Надёжности;
2. Безопасности;
3. Требования к защите информации от несанкционированного доступа. Должна быть предусмотрена защита от несанкционированного доступа  к данным, ввода данных, их удаления.
4. Система должна быть доступна с любого компьютера в фирме.
5. Информация хранящаяся в системе должна быть защищена от аварийных ситуаций, влияния внешних воздействий (радиоэлектронная защита).
6. Квалификация персонала. Персонал должен быть обучен правилам работы с системой, при этом не обязательно наличие специального технического образования.

     1.1.5.2 Требования к функциям, выполняемым  системой

• До введения автоматизированной системы в отдел кадров и услуг вручную создавались табили и графики, которые представляли собой тоненькие тетради в клеточку. Для хранения таких тетради требовалось дополнительное место, а тетради не обладали износоустойчивостью. Применение автоматизированной системы позволит не только сэкономить пространство, время на создание и заполнение таких тетради, но и существенно повысит износоустойчивость, что позволит хранить информацию в течение длительного времени.
• Необходимо иметь информацию о заказчиках, которым были оказанны услуги или оказываются. Для того чтобы получить эту информацию без автоматизированной системы необходимо просмотреть и проверить вручную списки в тетрадях. Это займет значительный отрезок времени. Кроме того, не исключены ошибки сотрудников, которые могут привести к различным последствиям. Автоматизированная система позволяет хранить информацию о клиентах сколь угодно долго, поиск клиентов, которых необходимо выполнить услуги и здать объект осуществляется за считанные секунды, исключены ошибки персонала, не требуется дополнительная площадь для хранения бумажных тетрадей клиентов.
• Регистрация новых заказов. Автоматизированная система позволит регистрировать клиентов довольно быстро и просто, не понадобиться длительного заполнения различного рода бумаг. Заказать работы можно будет произвести за 2-3 минуты при первом же посещении фирмы, при этом клиенты должны будут всего лишь предоставить паспорт или иной документ, удостоверяющий личность и сообщить некоторую другую информацию о себе.
• Получение данных для статистики. Автоматизированная система позволяет получить данные о стоимости услуг . Статистические данные позволяют определить популярность услуги в той или иной области.

 

1.1.5.3. Требования к видам обеспечения.

     Программное обеспечение системы не должно зависеть  от аппаратных средств компьютера. Необходимое программное обеспечение:

MS ACCESS 2000, MS Word 2000, MS SQL Server 2000. 

     1.1.6. Требования к составу и содержанию  работ по подготовке объекта  автоматизации к вводу системы  в действие

• Заполнение созданной базы;
• обеспечение персонала необходимыми техническими средствами;
• обучение персонала правилам работы с системой.

 

     1.2. Постановка задачи

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

     Создание  базы данных позволит автоматизировать процесс получения:

1. информации о клиентах, которые пользуются определённым видом услуг. Отчет будет содержать фамилии клиентов и перечень услуг, которые им оказывались с указанием даты проведения услуги.
2. отчетов о сотрудниках, которые находятся в данный момент на объектах. Отчет будет содержать дату начала и дату окончания работ на объекте.
3. отчета о материалах требуемых для осуществления услуги.
4. отчета о сотрудниках.
5. отчета о клиентах, которые пользовались услугами.

 
 
 
 
 
 
 
 
 
 

     2. Технический проект  информационной системы

     2.1. Функциональная модель

     2.1.1. Контекстная диаграмма и диаграммы  детализации процессов

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

     Рисунок 1 – Контекстная диаграмма

     Контекстная диаграмма разбивается на уровни. Первый уровень диаграммы представлен на рисунке 2, с помощью которой производится детализация основного процесса,  находящегося на контекстной диаграмме. Контекстную диаграмму разбиваем на 4 блока в соответствии со спецификой осуществляемых действий.

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

     Полученные  блоки  – «Организовать работу с клиентами», «Организовать работу отдела кадров», «Организовать работу отдела снабжения», «Организовать работу отдела услуг» – также подлежат дальнейшей детализации (рисунки 3, 4, 5,6).

 

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

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

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

снабжения ”

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

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

     Рисунок 7 – декомпозиция процесса A11 “ Организовать прием

     заказов ”

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

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

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

(рисунок   9).

Рисунок 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, куда будет производиться запись;