Файл: Проектирование реализации операций бизнес-процесса «Учет предоставленных услуг салоном красоты» (Характеристика документооборота, возникающего при решении задачи).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 15.06.2023

Просмотров: 311

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

2.5 Характеристика базы данных

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

  1. «Заказ» - таблица предназначена для хранения информации о заказах;

Рисунок 6. Таблица “Заказы”

  1. «Категории услуг» - таблица предназначена для хранения информации о услугах, рисунок 7;

Рисунок 7. Таблица “Категории услуг”

  1. «Оказание услуг» - таблица предназначена для хранения информации о ходе выполнения услуг, рисунок 8;

Рисунок 8. Таблица “Оказание услуг”

  1. «План» - таблица предназначена для хранения информации о выполненном плане, рисунок 9;

Рисунок 9. Таблица “План”

  1. «Сотрудники» - таблица предназначена для хранения информации о сотрудниках салона, рисунок 10;

Рисунок 10. Таблица “Сотрудники”

2.6. Структурная схема пакета (дерево вызова программных модулей)

Рассмотрим первичные и внешние ключи отношений.

По ограничению целостности данных ключи бывают:

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

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

Рассмотреть ключи данной БД мы можем на схеме данных (рисунок 11) и таблицы 2.

Рисунок 11. Схема данных

Таблица 2.

Схема данных


Сущность

Первичный ключ

Внешний ключ

Сотрудники

КодСотрудника

КодСотрудника

ФизическиеЛица

КодФЛ

КодОбратившегосяЛица

Заказы

КодЗаказа

КодЗаказа

ОказаниеУслуг

-

КодУслуги, КодСотрудника, КодООбратившегосяЛица

Услуги

КодУслуги

КодУслуги

План

Номер плана

Номер плана

Категории услуг

КодКатегории

КодКатегории

Теперь рассмотрим нормализацию отношений базы данных.

Процесс нормализации отношений состоит из следующих этапов:

- преобразование отношений в первую нормальную форму (1НФ);

- преобразование отношений во вторую нормальную форму (2НФ),

- преобразование отношений в третью нормальную форму (3НФ).

Таблица в первой нормальной форме удовлетворят следующим требованиям:

1. Таблица не содержит повторяющихся записей.

2. В таблице отсутствуют повторяющиеся группы полей.

3. Строки не упорядочены.

4. Столбцы не упорядочены.

Для исключения повторяющихся записей я воспользовалась следующим способом. Исключение повторяющихся записей состоит в использовании уникального составного индекса, состоящего из соответствующих полей. После того, как я разделила повторяющиеся объекты и определила поля, которые образуют уникальный индекс в каждой таблице, считается, что таблица находится в первой нормальной форме. Таким образом, первый шаг при нормализации заключался в образовании двумерных таблиц, содержащих элементы данных в качестве атрибутов. Повторяющиеся группы элементов данных выделяются в отдельный вид отношения. Это и является 1НФ данного отношения.

Таблица в второй нормальной форме удовлетворят следующим требованиям:

1. Она удовлетворяет условиям первой нормальной формы.

2. Любое не ключевое поле однозначно идентифицируется полным набором ключевых полей.

Из приведенного выше определения следует, что понятие второй нормальной формы применимо только к таблицам, имеющим составной индекс. Таким образом, второй шаг нормализации состоял в том, чтобы выделить ключи и зависящие от них атрибуты. Для отношения, находящегося в первой нормальной форме для приведения ко второй нормальной форме необходимо было выделить группы не ключевых атрибутов, зависящие от части составного ключа. Эти группы могут образовать отдельные отношения, в которых не ключевые атрибуты будут зависеть только от определенной части составного ключа. Рассмотрим пример второй нормальной формы на рисунке 12 и 13.


Рисунок 12. Таблица во второй нормальной форме

Рисунок 13. Связь во второй нормальной форме

Таблица в третьей нормальной форме удовлетворят следующим требованиям:

1 Она удовлетворяет условиям второй нормальной формы.

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

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

Целостность данных - это механизм поддержания соответствия базы данных предметной области. Требование целостности сущностей заключается в следующем: каждый кортеж любого отношения должен отличатся от любого другого кортежа этого отношения. Если данное требование не соблюдается, то в базе данных может хранится противоречивая информация об одном и том же объекте. Поддержание целостности сущностей обеспечивается средствами системы управления базой данных (СУБД), рисунок 14.

Рисунок 14. Ограничения целостности данных в базе данных

Это осуществляется с помощью двух ограничений:

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

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

На рисунке 15 представлена вертикальная диаграмма связей между внешними и первичными ключами.

Рисунок 15. Вертикальная диаграмма связей между внешними и первичными ключами

Рассмотрим процедуры реализованной в БД.

  1. «Оказание услуг по статусам» - данный запрос позволяет вывести все услуги с определенным статусом, рисунок 16

Рисунок 16. Запрос на оказание услуг по статусу

Запросы БД.

  1. «Услуги по категориям» - данный запрос предназначен для получения информации о названии категории, названии услуги и стоимость услуги, рисунок 17.

Рисунок 17. Услуги по категориям

  1. «Добавление нового сотрудника» - данный запрос предназначен для добавления сотрудника и содержит в себе такие поля как код сотрудника, фамилия, имя, отчество, опыт работы, должность и др., рисунок 18.

Рисунок 18. Добавление нового сотрудника

  1. «Удалить выполненный заказ» - данный запрос предназначен для удаление заказа со статусом “выполнено”, рисунок 19.

Рисунок 19. Удалить выполненный заказ

2.4 Описание разработанного программного обеспечения

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

В приложении Access были реализованы таблицы, запросы, отчеты, модули и макросы. Рассмотрим запросы, формы и отчеты:

Формы БД

  1. «Главная форма» - в данной форме находятся кнопки для перехода на другие формы, рисунок 20.

Рисунок 20. Главная форма

  1. «Заказы» - в данной форме мы можем увидеть информацию о заказах, рисунок 21.

Рисунок 21. Заказы

  1. «Запросы» - в данной форме мы можем переходить по различным запросам, рисунок 22.

Рисунок 22. Запросы

  1. «Категории услуг» - в данной форме мы можем увидеть информацию об услугах, рисунок 23.

Рисунок 23. Категории услуг

  1. «Оказание услуг» - в данной форме мы можем увидеть информацию об услугах, рисунок 24.

Рисунок 24. Оказание услуг

  1. «Отчёты» - в данной форме мы можем переходить по отчётам, рисунок 25.

Рисунок 25 Отчёты

  1. «Таблицы» - данная форма предназначена для перехода по таблицам, рисунок 26.

Рисунок 26. Таблицы

Отчёт БД

  1. «Категории услуг» - предназначен для вывода и печати информации о категории услуг, рисунок 27.

Рисунок 27. Категории услуг

  1. «Оказание услуг по статусам» - предназначен для вывода и печати информации об оказании услуг по статусам, рисунок 28.

Рисунок 28. Оказание услуг по статусам

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

К созданной БД было разработано приложение в объектной ориентированной среде программирования Delphi. Здесь были разработаны следующие формы:

Form1.Caption «Loading» - данная форма представляет собой окно загрузки, рисунок 29.

Рисунок 29. Loading

Form10.Caption.План – на данной форме присутствуют данные о сотрудниках и их планах, рисунок 30.

Рисунок 30. План

Form11.Caption.Сотрудники – на данной форме предоставлена информация о сотрудниках, рисунок 31.

Рисунок 31. Сотрудники

Form12.Caption.Услуги – на данной форме предоставлена информация об услугах, рисунок 32.

Рисунок 32. Услуги

Form13.Caption.Заказы – на данной форме предоставлена информация о заказах, рисунок 33.

Рисунок 33. Заказы

Form14.Caption.Клиенты – на данной форме предоставлена информация о клиентах, рисунок 34.

Рисунок 34.Клиенты

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

Рисунок 35. Ограниченный доступ

Form16.Caption.Отчёты – на данной форме предоставлены все возможные отчёты, рисунок 36.

Рисунок 36. Отчёты

Form2.Caption.Авторизация – данная форма предназначена для авторизации, рисунок 37.

Рисунок 37. Авторизация

Form5.Caption.Выбор таблиц – данная форма предназначена для выбора таблиц, рисунок 38.