Загрузил Deadpeople Forever

Пояснительная записка Ооржак

реклама
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Сибирский государственный университет науки и технологий
имени академика М.Ф. Решетнева»
Институт информатики и телекоммуникаций
Кафедра информатики и вычислительной техники
КУРСОВАЯ РАБОТА
Управление данными
Разработка системы учета записей
в салоне красоты «BeautyAccounting»
Руководитель
А.Г. Зотин
подпись, дата
Обучающийся БИС 17–01, 171217018
номер группы, зачетной книжки
19.06.2020
подпись, дата
Красноярск 2020 г.
инициалы, фамилия
А.К. Ооржак
инициалы, фамилия
Институт информатики и телекоммуникаций
Кафедра информатики и вычислительной техники
ЗАДАНИЕ
на курсовую работу по дисциплине Управление данными
обучающемуся Ооржак Ай-Кат Катовне
Группа
БИС 17–01
Форма обучения очная
Тема работы:
Разработка системы учета записей в салоне красоты
«BeautyAccounting»
Срок сдачи курсовой работы 19.06.2020
Перечень вопросов, подлежащих разработке при написании теоретической части:
Обзор информационно-справочных систем салонов красоты; обзор информационных
потоков; концептуальное проектирование базы данных; логическое проектирование
базы данных; выбор целевой СУБД; разработка бизнес-правил.
Перечень вопросов, подлежащих разработке при написании практической части:
Физическое проектирование базы данных; разработка структуры программного продукта; реализация бизнес-правил; разработка интерфейса; программная реализация
проекта; формирование руководств программиста и пользователя; тестирование разработанного программного продукта.
Дата выдачи задания:
Руководитель
20.02.2020
Зотин А.Г., доцент кафедры ИВТ
(подпись)
Задание принял к исполнению (дата) 20.02.2020
(подпись обучающегося, И.О. Фамилия)
СОДЕРЖАНИЕ
ВВЕДЕНИЕ .................................................................................................................. 4
1 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ ................................................................ 5
1.1 Обзор сервисов для салонов красоты .............................................................. 5
1.2 Концептуальное проектирование базы данных ............................................. 8
1.3 Логическое проектирование базы данных.................................................... 10
1.4 Выбор целевой СУБД ..................................................................................... 12
1.5 Физическое проектирование базы данных ................................................... 15
Выводы по главе .................................................................................................... 18
2. РАЗРАБОТКА ПРОГРАММНОГО ПРОДУКТА .............................................. 19
2.1 Структура программного продукта ............................................................... 19
2.2 Реализация бизнес–правил ............................................................................. 19
2.3 Руководство программиста ............................................................................ 22
2.4 Руководство пользователя .............................................................................. 23
2.5 Тестирование программного продукта ......................................................... 27
Выводы по главе .................................................................................................... 28
ЗАКЛЮЧЕНИЕ ......................................................................................................... 29
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ................................................ 30
ПРИЛОЖЕНИЕ А ..................................................................................................... 31
ПРИЛОЖЕНИЕ Б ...................................................................................................... 33
ВВЕДЕНИЕ
Актуальность. На сегодняшний день запись клиентов в салон красоты
происходит трудоемко. Для того, чтобы записать только одного клиента уходит
очень много времени. Девушка администратор должна найти нужный журнал,
сообщить о свободных датах и предоставляемых мастерах. Это занимает около
10 минут. После всех манипуляций с журналом происходит запись клиента.
Поэтому данный вид записи имеет недостатки такие, как: ошибки в записях, не
читаемость информации о клиенте, потеря журнала, порча журнала. В результате, салон теряет клиентов, а, следовательно, прибыль.
Если разработать информационную систему учёта записей для салона
красоты, то запись клиентов уменьшится в 10–12 раз и ошибок, вызванных человеческим фактором, станет меньше.
Цель и задачи. Целью данной курсовой работы является разработка системы учета записей в салоне красоты «BeautyAccounting» с интуитивно понятным интерфейсом и возможностью составления отчетов и вывода графиков.
Для достижения поставленной цели необходимо решить следующие
задачи:
− выполнить обзор сведений, учитываемых в салонах красоты;
− провести анализ существующих сервисов для салонов красоты;
− провести концептуальное проектирование базы данных;
− построить логическую модель базы данных;
− выбрать целевую СУБД;
− выполнить физическое проектирование базы данных;
− реализовать структуру программного продукта;
− разработать руководство пользователя и программиста;
− осуществить программную реализацию;
− провести тестирование программного продукта.
Структура работы. Пояснительная записка к курсовой работе состоит
из введения, двух глав, заключения и списка использованных источников из 9
наименований. Изложена на 37 страницах и содержит 28 рисунков и 5 таблиц.
В первой главе курсовой работы приводится описание проектирования
базы данных для разрабатываемого приложения. Отражен обзор аналогов программных продуктов. Показаны результаты концептуального, логического и
целевого проектирования базы данных. Обоснован выбор целевой СУБД. Представлен результат физического проектирования базы данных.
Во второй главе описана разработка программного продукта и его структура. Показана реализация бизнес–правил. Отражены руководства программиста и пользователя. Описаны результаты тестирования программного продукта.
В заключении подведены итоги курсовой работы.
1 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
Проектирование базы данных неразрывно связано с понятием «предметная область». Предметная область – часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации.
Предметная область представляется множеством фрагментов, например, предприятие – цехами, дирекцией, бухгалтерией и т.д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих
объекты, а также множеством пользователей, характеризуемых различными
взглядами на предметную область. [5]
До сих пор многие предприятия сферы услуг ведут учёт на бумаге, а запись осуществляют по телефону. На всю процедуру записи клиента уходит
примерно 8–10 минут. Если поток клиентов большой, это становится очень
трудоемко. С такой системой данные клиентов легко перепутать, сложно отследить постоянных гостей и предложить им специальные условия и участие в
акциях. Решение проблемы – это автоматизация записи клиентов. В настоящее
время автоматизация салона красоты и внедрение программы, управляющей
бизнес–процессами, являются жизненной необходимостью и так же, как любой
другой бизнес, салон красоты требует своевременного точного ведения учета и
контроля. Автоматизация позволит управлять расписанием, базой клиентов.
Работа администратора станет намного легче. Из чего следует, что уровень обслуживания повысится и привлечет большее число клиентов, а, следовательно,
прибыль.
1.1 Обзор сервисов для салонов красоты
Для того чтобы понять, как разработать программный продукт, автоматизирующий запись клиентов, необходимо рассмотреть существующие программные продукты, а также их недостатки и преимущества. Наиболее распространенными являются такие сервисы, как: Yclients, Hesus, Gbooking.
Программный продукт «Yclients»
«Yclients» автоматизирует онлайн–запись и администрирование компании. Виджет записи, с помощью которого клиенты будут выбирать удобные дату и время, можно установить на сайте и в социальных сетях, его внешний вид
корректируется. Дополнительно «Yclients» предлагает разработать персональное мобильное приложение (стоимость использования – от 1 000 до 2 500 рублей в месяц) [9].
Контроль в сфере услуг становится проще после автоматизации бизнес–
процессов. «Yclients» позволяет вести учёт, начиная с момента формирования
заявки и заканчивая сопровождением клиента после покупки. Вы контролируете складские запасы, ведёте расчёты с поставщиками, работаете с несколькими
кассами и счетами, начисляете зарплату и учитываете расходные материалы. И
всё это – в режиме реального времени.
Личный кабинет позволяет управлять расписанием, базой клиентов и
программой лояльности, например, выявлять активных пользователей и выстраивать систему скидок. Также сервис предлагает отслеживать статистику –
какая из услуг более востребована или какой сотрудник самый эффективной.
Есть возможность автоматической рассылки напоминаний клиентам. Кроме того, сервис автоматизирует внутренние процессы: позволяет вести складской и
финансовый учет, управлять филиалами сетевых компаний, рассчитывать зарплаты. «Yclients» используют более 1300 компаний: салоны красоты, медицинские центры, квеструмы, автосервисы. Главное окно программы представлено
на рисунке 1.1.
Рисунок 1.1 – Главное окно программы «Yclients»
Программный продукт «Hesus»
Функционал системы онлайн–бронирования «Hesus» ограничен сервисом
предварительной записи, зато модуль универсален и его легко детализировать
под задачи бизнеса. Пользователь сможет настроить параметры бронирования:
если стандартных критериев записи недостаточно, можно использовать выбор
места, отрегулировать по собственному желанию временные интервалы, добавить схему размещения (например, ресторанного зала, автобуса или гостиницы). Онлайн–запись интегрируется с сайтом и социальными сетями [9].
Программа позволяет опционально создавать правила для присвоения
скидок клиентам, а также добавлять их в категории и удалять из категорий.
Скидки присваиваются по потраченным средствам и количеству визитов.
Если скидки начисляются и по визитам, и по потраченным средствам, то
итоговая стоимость услуги будет рассчитана c учётом большей из них. Кроме
того, вы получаете возможность удалять клиентов из программы лояльности.
Например, если заказчик не посещал заведение более установленного срока,
скидка аннулируется системой.
Большой плюс – функция предоплаты для клиентов через «Яндекс.Деньги» или с помощью карты, что встречается редко. Это позволяет снизить процент отказавшихся в последний момент. Также существует партнёр6
ская программа: ресурс, разместивший ссылку на сервис у себя на сайте, получает 11% с каждого взноса нового пользователя «Hesus», пришедшего по этой
ссылке. Компания сообщает о 29 500 созданных модулей. Главное окно программы представлено на рисунке 1.2.
Рисунок 1.2 – Главное окно программы «Hesus»
Программный продукт «Gbooking»
«Gbooking» предлагает систему онлайн–записи с «напоминалками» для
клиентов по почте. Программа умеет выявлять популярные услуги, отслеживать активных клиентов, позволяет настраивать систему скидок. Также есть
электронный журнал администратора, с его помощью можно минимизировать
свободные окна в расписании. Нюансы работы разных компаний из сферы
услуг учтены в настройках – например, повторное посещение для медцентров,
планирование смен мастеров для салонов красоты. Сервис пока не работает с
соцсетями, но запустил мобильное приложение, также есть возможность разработать брендированное приложение (стоимость определяется индивидуально)
[9].
Он позволяет создать расписание и разместить на сайте красивый виджет
для онлайн–записи клиентов, с помощью которого они могут увидеть свободные часы и зарезервировать время посещения. Кроме того, сервис отправляет
клиентам напоминания по sms, чтоб они не забыли о визите. Если клиент часто
посещает ваше заведение – можно предоставить ему мобильное приложение
для более простой записи. А администратор получает в свое распоряжение
электронный журнал, позволяющий вести учёт посещений клиентов. Более того, GBooking может размещать вашу кнопку записи на сайтах в своей партнерской сети. Стоимость сервиса начинается от 990 рублей в месяц.
Личный кабинет для клиента со всей историей посещений. Функция отмены и переноса записей в онлайн–режиме. Фотогалерея и описание вашего
бизнеса. Отзывы и информация о каждом сотруднике. Запись на промо и скрдочные акции.
7
В разных тарифах есть возможность размещаться на сайтах–партнёрах –
iTop.ru, Zoon.ru и отраслевых площадках. К системе подключено 500 компаний.
Главное окно программы представлено на рисунке 1.3.
Рисунок 1.3 – Главное окно программы «GBooking»
На основания рассмотренных данных можно сделать выводы, что большинство сервисов не удовлетворяют требованиям наличия записи расходов,
доходов, списка закупок и поиска записей. Разрабатываемый программный
продукт обеспечит наличие необходимых требований и таким образом позволит в полной мере ощутить удобство использования.
1.2 Концептуальное проектирование базы данных
Концептуальное проектирование – сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
− обследование предметной области, изучение ее информационной
структуры;
− выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между
ними, процессами над информационными объектами;
− моделирование и интеграция всех представлений. [5]
Концептуальное проектирование состоит в создании концептуальной модели данных для анализируемой фирмы. Данная модель данных возникает на
основе информации, записанной в классификациях условий пользователей.
Концептуальное проектирование базы данных совершенно не зависит от таких
деталей ее реализации, как тип подобранной целевой СУБД, набор выполняемых прикладных программ, языки программирования, тип подобранной вычислительной площадки, а также от всех иных сторон физической реализации. При
разработке концептуальная модель данных часто испытывается тестированием
и проверке на согласие требованиям пользователей. Спроектированная концеп8
туальная модель данных фирмы – источник информации для этапа логического
проектирования базы данных.
Для наиболее эффективного выполнения поставленных задач ниже приведены концептуального проектирования, таблицы 1.1 и 1.2.
Таблица 1.1 – Сведения о типах сущностей проекта
№
1
2
3
4
5
6
7
Имя сущности
Тип процедуры
Товары
Услуги
Услуги
Записи
Сотрудники
Клиенты
Описание
Содержит описание типов процедур
Содержит список товаров
Содержит перечень услуг
Содержит список работающих залов
Хранит информацию о сотрудниках
Хранит информацию о клиентках
Содержит в себе список записей
Тип
сильный
сильный
сильный
сильный
слабый
сильный
сильный
Таблица 1.2 – Сведения о типах связей проекта
№
1
2
3
4
5
6
7
Тип сущности
Сотрудники
Тип процедуры
Товар
Услуги
Записи
Сотрудники
Клиенты
Тип связи
Осуществляет
Описывает
Учитывает
Учитывает
Учитывает
Осуществляет
Учитывает
Тип сущности
Тип процедуры
Товар
Услуги
Зал
Услуги
Записи
Записи
Кардинальность
N:M
N:M
N:M
1:M
M:1
1:M
N:M
Так же приведена ER–модель проекта на рисунке 1.4. ER–модель – это
модель данных, позволяющая описывать концептуальные схемы предметной
области. Она используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
9
Рисунок 1.4 – ER–модель проекта
1.3 Логическое проектирование базы данных
Логическое проектирование базы данных – это процесс создания модели
используемой информации на основе выбранной модели организации данных,
но без учета типа целевой СУБД и других физических аспектов реализации.
Второй этап проектирования базы данных называется логическим проектированием базы данных. Его цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной
модели организации данных в целевой СУБД (например, реляционная модель).
[5]
В таблице 1.3 представлены атрибуты и домены базы данных, спроектированные на логическом уровне.
№
1.
Сущность
Сотрудники (Employee)
Атрибут сущности
Псевдоним атрибута
Домен атрибута
ID сотрудника
Фамилия
Имя
Отчество
idEmp
SerName
FirstName
MiddleName
idTypeProc
Числовой
Текстовый
Текстовый
Текстовый
Числовой
Address
DateOB
Текстовый
Числовой
ID тип процедуры
Адрес
Дата рождения
10
Продолжение таблицы 1.3
№
1.
2.
Сущность
Сотрудники (Employee)
Клиенты
(Clients)
3.
Себестоимость
(Costprice)
4.
Зал (Factory)
6.
Записи (Posts)
7.
8.
Продукты
(Product)
Услуги (Service)
9.
Услуги зала (ServiceFactory)
10.
Товары для услуг
(ServiceProd)
11.
Тип процедуры
(TypeProc)
Атрибут сущности
Псевдоним атрибута
Домен атрибута
Дата договора
Телефон
ID клиента
Фамилия
Имя
Отчество
Номер
Дата рождения
DateOrder
Phone
idClients
Sername
Firstname
Middlename
Phone
DateOfB
Числовой
Числовой
Числовой
Текстовый
Текстовый
Текстовый
Числовой
Числовой
ID себестоимость
ID продукта
Стоимость
ID зала
Название зала
ID записи
Дата записи
ID клиента
ID сотрудника
ID услуги
ID зала
ID продукта
Название
ID тип процедуры
ID услуги
Название услуги
ID тип процедуры
IDCostPrice
idProduct
Cost
idFactory
NameFactory
idPosts
DateP
idClient
isEmp
idService
idFactory
idProduct
Name
idTypeProc
idService
NameService
idTypeProc
Числовой
Числовой
Числовой
Числовой
Текстовый
Числовой
Числовой
Числовой
Числовой
Числовой
Числовой
Числовой
Текстовый
Числовой
Числовой
Текстовый
Числовой
Стоимость
ID услуги зала
ID услуги
ID зала
ID товара для услуг
ID услуги
ID продукта
ID тип процедуры
Название типа
Cost
idServiceFactory
idService
idFactory
idServiceProd
idService
idProduct
idTypeProc
TypeName
Числовой
Числовой
Числовой
Числовой
Числовой
Числовой
Числовой
Числовой
Текстовый
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Логическая модель описывает понятия предметной области, их взаимосвязь, а
также ограничения на данные, налагаемые предметной областью.
Для базы данных программы была разработана логическая модель, представленная на рисунке 1.6.
11
Рисунок 1.5 – Логическая модель базы данных приложения
1.4 Выбор целевой СУБД
Для разработки программного продукта необходимо выбрать базу данных. Наиболее распространенными являются MySQL, PostgreSQL, Oracle.
MySQL
MySQL – это самая распространенная полноценная серверная СУБД.
MySQL очень функциональная, свободно распространяемая СУБД, которая
успешно работает с различными сайтами и веб приложениями. Обучиться использованию этой СУБД довольно просто, так как на просторах интернета вы
легко найдете большее количество информации.
Несмотря на то, что в ней не реализован весь SQL функционал, MySQL
предлагает довольно много инструментов для разработки приложений. Так как
это серверная СУБД, приложения для доступа к данным, в отличии от SQLite
работают со службами MySQL.
СУБД MySQL получила широкое распространение в качестве средства
работы с базами данных в Интернете. Программа совершенно нетребовательна
к ресурсам сервера, на котором работает, очень быстрая и к тому же совершенно бесплатная: исходные коды и дистрибутивы для различных платформ доступны на сайте в Интернете. Изначально программа была ориентирована на
операционную систему Linux, но сейчас уже существуют версии программы
для операционных систем Windows, UNIX, NetBSD, FreeBSD, AIX. В последнее
время программа завоевывает популярность у пользователей Macintosh с использованием операционной системой Mac OSX.
12
Преимущества MySQL:
− простота в работе – установить MySQL довольно просто. Дополнительные приложения, например, GUI, позволяет довольно легко работать с БД;
− богатый функционал – MySQL поддерживает большинство функционала
SQL;
− безопасность – большое количество функций, обеспечивающих безопасность, которые поддерживается по умолчанию;
− масштабируемость. MySQL легко работает с большими объемами данных и легко масштабируется;
− скорость – упрощение некоторых стандартов позволяет MySQL значительно увеличить производительность.
Недостатки MySQL:
− известные ограничения – по задумке в MySQL заложены некоторые
ограничения функционала, которые иногда необходимы в особо требовательных приложениях;
− проблемы с надежностью – из–за некоторых способов обработки данных MySQL (связи, транзакции, аудиты) иногда уступает другим СУБД по
надежности;
− медленная разработка – Хотя MySQL технически открытое ПО, существуют жалобы на процесс разработки. Стоит заметить, что существуют другие
довольно успешные СУБД созданные на базе MySQL, например MariaDB. [8]
PostgreSQL
PostgreSQL является самым профессиональным из всех трех рассмотренных нами СУБД. Она свободно распространяемая и максимально соответствует
стандартам SQL. PostgreSQL или Postgres стараются полностью применять
ANSI/ISO SQL стандарты своевременно с выходом новых версий.
От других СУБД PostgreSQL отличается поддержкой востребованного
объектно–ориентированного и/или реляционного подхода к базам данных.
Например, полная поддержка надежных транзакций, т.е. атомарность, последовательность, изоляционность, прочность (Atomicity, Consistency, Isolation,
Durability (ACID).) Благодаря мощным технологиям Postgre очень производительна. Параллельность достигнута не за счет блокировки операций чтения, а
благодаря реализации управления многовариантным параллелизмом (MVCC),
что также обеспечивает соответствие ACID. PostgreSQL очень легко расширять
своими процедурами, которые называются хранимые процедуры. Эти функции
упрощают использование постоянно повторяемых операций.
Хотя PostgreSQL и не может похвастаться большой популярностью в отличии от MySQL, существует довольно большое число приложений облегчающих работу с PostgreSQL, несмотря на всю мощность функционала. Сейчас довольно легко установить эту СУБД используя стандартные менеджеры пакетов
операционных систем.
Достоинства PostgreSQL:
13
− открытое ПО соответствующее стандарту SQL – PostgreSQL – бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной системой;
− большое сообщество – существует довольно большое сообщество в котором вы запросто найдёте ответы на свои вопросы;
− большое количество дополнений – несмотря на огромное количество
встроенных функций, существует очень много дополнений, позволяющих разрабатывать данные для этой СУБД и управлять ими;
− расширения – существует возможность расширения функционала за счет
сохранения своих процедур;
− объектность – PostrgreSQL это не только реляционная СУБД, но также и
объектно–ориентированная с поддержкой наследования и много другого.
Недостатки PostgreSQL:
− производительность – при простых операциях чтения PostgreSQL может значительно замедлить сервер и быть медленнее своих конкурентов, таких
как MySQL;
− популярность – по своей природе, популярностью эта СУБД похвастаться не может, хотя и присутствует довольно большое сообщество;
− хостинг – в силу выше перечисленных факторов иногда довольно
сложно найти хостинг с поддержкой этой СУБД. [8]
Oracle
Надежность, безопасность, высокая производительность, удобство в работе. Это главное, что характеризует продукты Oracle на протяжении уже многих лет. Наиболее важным – это является для СУБД, ставшей на сегодняшний
день практически обязательной частью любой серьезной информационной системы. Но не только эти характеристики позволяют продуктам Oracle удерживать лидерство на рынке СУБД. Стремительно развивающиеся информационные технологии требуют от современных СУБД расширения классической
функциональности лишь по хранению и обработке данных. Двигаясь в ногу со
временем, корпорация Oracle по сути ломает сложившиеся взгляды на СУБД,
наделяя ее все новыми и новыми возможностями.
Современная СУБД Oracle это мощный программный комплекс, позволяющий создавать приложения любой степени сложности. Ядром этого комплекса является база данных, хранящая информацию, количество которой за
счет предоставляемых средств масштабирования практически безгранично. C
высокой эффективностью работать с этой информацией одновременно может
практически любое количество пользователей (при наличии достаточных аппаратных ресурсов), не проявляя тенденции к снижению производительности системы при резком увеличении их числа. [6]
Недостатки Oracle:
− миграция из устаревших файловых систем в ASM может быть проблемой и часто требует отключения системы;
− трудно (если не невозможно) просматривать содержимое ASM при помощи стандартных инструментов ОС. В некоторых случаях данные ASM могут
быть случайно перезаписаны администраторами ОС, которые используют тома
14
диска, которые (для них) кажутся пустыми. Однако существуют административные способы предотвратить это;
− резервное копирование не может быть выполнено с помощью традиционных методов (это называется в Oracle “user managed backup”), которые просто копируют файлы ОС, поэтому вам нужны встроенные инструменты или используйте собственные инструменты Oracle (например, RMAN). [7]
Можно сделать выводы, что большинство критериев зависят по большей
части от поставленной задачи. Моя цель – сделать простую, но очень удобную
и эргономичную систему. Поэтому, для разработки программного продукта
была выбрана СУБД MySQL.
1.5 Физическое проектирование базы данных
Этап физического проектирования базы данных требует поиска проектных
решений, обеспечивающих эффективную поддержку построенной логической
структуры базы данных в среде хранения базы данных. На этом этапе решаются
вопросы построения структуры хранимых данных, размещения хранимых
данных в пространстве памяти, выбора эффективных методов доступа к
различным компонентам физической базы данных. Описывается также
отображение логической структуры базы данных в структуру хранения.
Принятые на этом этапе проектные решения оказывают определяющее влияние
на производительность информационной системы. Они документируются в
форме схемы хранения на языке определения хранимых данных. [5]
Таблица 1.4 – Структура таблиц базы данных
Наименование
поля
Address
Размер Значение по Условие на
поля умолчанию значение
Сотрудники (Employee)
Идентификатор INT
11
сотрудника
(Автоинкремент)
Фамилия
VARCHAR
100
Имя
VARCHAR
100
Отчество
VARCHAR
100
Идентификатор INT
11
типа процедуры
Адрес
VARCHAR
255
DateOB
Дата рождения DATE
Меньше текущей даты
DateOrder
Дата договора
DATE
Phone
Телефон
INT
ВК,
индекс
Уникальное
ВК,
индекс
idEmp
SerName
FirstName
MiddleName
idTypeProc
Содержание
поля
Тип поля
12
15
Ключ /
индекс
ПК,
Индекс
Индекс
Индекс
ВК,
индекс
Продолжение таблицы 1.4
Наименование
поля
idClients
Sername
Firstname
Middlename
Phone
DateOfB
IDCostPrice
Cost
idFactory
NameFactory
idPosts
DateP
idClient
isEmp
idService
idFactory
idProduct
Name
idTypeProc
Содержание
поля
Размер
поля
Тип поля
Значение Условие
по
на
умолчанию значение
Клиенты (Clients)
Идентификатор INT
11
клиента
(Автоинкремент)
Фамилия
VARCHAR
255
Имя
VARCHAR
255
Отчество
VARCHAR
255
Номер
VARCHAR
12
Дата рождения DATE
Себестоимость (Costprice)
Идентификатор INT
11
себестоимости (Автоинкремент)
Стоимость
DOUBLE
Зал (Factory)
Идентификатор INT
11
зала
(Автоинкремент)
Название зала VARCHAR
100
Записи (Posts)
Идентификатор INT
11
издательства
(Автоинкремент)
Дата и время
DATETIME
записи
Идентификатор INT
11
издательства
Идентификатор INT
11
издательства
Идентификатор INT
11
издательства
Идентификатор INT
11
издательства
Продукты (Product)
Идентификатор INT
11
продукта
(Автоинкремент)
Название това- VARCHAR
50
ра
Идентификатор INT
11
Типа процедуры
16
Ключ /
индекс
ПК,
Индекс
Уникальное
Меньше
текущей
даты
ПК,
Индекс
ПК,
Индекс
ПК,
Индекс
Уникальное
ПК,
Индекс
Уникальное
Продолжение таблицы 1.4
Наименование
поля
Содержание
поля
Размер
поля
Тип поля
Значение Условие
по
на
умолчанию значение
Услуги зала (ServiceFactory)
idServiceFactory Идентификатор
INT
11
услуги зала (Автоинкремент)
idService
Идентификатор INT
11
услуги
idFactory
Идентификатор INT
11
зала
Товары для услуг (ServiceProd)
idServiceProd
Идентификатор INT
11
услуг товара
(Автоинкремент)
idService
Идентификатор INT
11
услуги
idProduct
Идентификатор INT
11
продукта
Тип процедуры (TypeProc)
idTypeProc
Идентификатор INT
11
типа процеду- (Автоинкремент)
ры
TypeName
50
Название типа VARCHAR
Рисунок 1.6 – Физическая модель базы данных
17
Ключ /
индекс
ПК,
Индекс
ПК,
Индекс
ПК,
Индекс
Уникальное
Выводы по главе
В первой главе курсовой работы был осуществлён Обзор сервисов для салонов красоты для того, чтобы лучше понимать на что стоит обратить внимание при разработке. После этого было осуществлено концептуальное проектирование базы данных, построены таблицы, описывающие сведения о типах
сущностей проекта, сведения о типах связей проекта, а также построена ER–
модель. Выполнено логическое проектирование базы данных и, в результате,
произведена нормализация до третьей нормальной формы.
Для защиты данных и обеспечения большей гибкости базы данных за
счет исключения избыточности и несогласованности зависимости были установлены отношения между таблицами в соответствии с установленными правилами.
В ходе сравнения трёх СУБД была выбрана оптимальная СУБД для курсового проекта. Ей стала СУБД MySQL. В процессе физического проектирования базы данных была создана база данных, состоящая из 9 таблиц. Проектирование
осуществлялось
в
dbForge
Studio
For
MySQL.
18
2. РАЗРАБОТКА ПРОГРАММНОГО ПРОДУКТА
Во второй главе курсовой работы разрабатывается структура программного продукта, выполняется реализация бизнес–правил. После реализации проекта разрабатываются руководства программиста и пользователя. Для того,
чтобы свести к минимуму возможные ошибки в работе системы производится
тестирование программного продукта и исправление ошибок.
2.1 Структура программного продукта
Программа разработана в среде «Embarcadero Rad Studio 2010» с использованием СУБД MySQL 5.5 и программой для администрирования dbForge
Studio 2019 for MySQL. Продукт состоит из 17 форм (модулей), его схема представлена на рисунке 2.1.
Рисунок 2.1 – Схема программного продукта
2.2 Реализация бизнес–правил
Бизнес-правила представляют собой специализированный вид логики,
описывающей ограничения на образ действий, которые система или люди
должны учитывать в своем поведении. Эти правила определяются целым рядом
факторов, включая директивы распорядительных органов, промышленные
стандарты, деловую хватку и простой здравый смысл. Нередко они изменяются
от страны к стране, от отрасли к отрасли, и даже от бизнеса к бизнесу.
Бизнес-правила существуют на разных уровнях. Некоторые из них оказывают влияние на всю систему, и многие системы, на самом деле, целиком создаются лишь для того, чтобы ввести в действие бизнес-правила. Бизнесправила также могут значительно различаться по размерам области влияния.
Но, несмотря на это, все бизнес-правила имеют одно общее свойство: они
управляют некоторой составляющей бизнеса. По определению, бизнес-правило
есть ограничение, применяемое по отношению к человеку, бизнесу, составля-
ющей бизнеса или действию. Далее речь пойдет о некоторых подробностях, характерных для унифицированных языков моделирования. [1].
Были разработаны следующие бизнес-правила:
− база данных должна обеспечивать ссылочную целостность, автоматическое обновление таблиц в приложении;
− база данных должна позволять осуществлять быстрый поиск и фильтрацию списка: записей, клиентов, сотрудников, материалов, услуг, помещений;
− база данных должна иметь удобный способ ввода новых данных и редактирования имеющихся;
− база данных должна позволять формировать отчеты;
− база данных должна позволять собирать статистику по доходности: сотрудников, от клиентов по дате, помещений по услугам, каждого из помещений, каждой из услуг.
Разработана диаграмма прецедентов пользователя рисунке 2.2.
Рисунок 2.2 – UML-диаграмма прецедентов
Диаграмма активности устанавливает правила обязательной последовательности действий, которым должны следовать, рисунок 2.3.
20
Рисунок 2.3 – Диаграмма активности
В листинге 2.1 представлен SQL-запрос на себестоимость каждой из
услуг.
Листинг 2.1 – SQL-запрос на себестоимость каждой из услуг
SELECT
`service`.`idService` AS `idService`,
`service`.`NameService` AS `NameService`,
SUM(`view_prod_by_type_cost`.`Cost`) AS `Cost_of_prod_for_serv`
FROM ((`serviceprod`
JOIN `service`
ON ((`serviceprod`.`idService` = `service`.`idService`)))
JOIN `view_prod_by_type_cost`
ON ((`view_prod_by_type_cost`.`idProduct` = `serviceprod`.`idProduct`)))
GROUP BY `service`.`idService`,
`service`.`NameService`;
В листинге 2.2 представлен SQL-запрос на выборку всех клиенток с
датами и стоимостью по каждой записи в салоне.
Листинг 2.2 – SQL-запрос на себестоимость каждой из услуг
SELECT
`view_clients`.`FIOc` AS `FIOc`,
`posts`.`DateP` AS `DateP`,
`service`.`Cost` AS `Cost`
FROM ((`posts`
JOIN `view_clients`
ON ((`posts`.`idClient` = `view_clients`.`idClients`)))
JOIN `service`
ON ((`posts`.`idService` = `service`.`idService`)))
GROUP BY `posts`.`DateP`,
`posts`.`idClient`,
`posts`.`idService`,
`view_clients`.`idClients`,
`view_clients`.`FIOc`,
21
`service`.`idService`,
`service`.`Cost`;
В листинге 2.3 представлен SQL-запрос на выборку всех сотрудников по
полной стоимости и чистой доходности от каждой записи.
Листинг 2.3 – SQL-запрос на формирование списка всех сотрудников по полной
стоимости и чистой доходности от каждой записи
SELECT
`employee`.`idEmp` AS `idEmp`,
`employee`.`SerName` AS `SerName`,
`employee`.`FirstName` AS `FirstName`,
`employee`.`MiddleName` AS `MiddleName`,
`posts`.`DateP` AS `DateP`,
`view_factory_income`.`Fact_income` AS `Fact_income`,
(`view_factory_income`.`Fact_income` * 0.47) AS `salary`
FROM ((`posts`
JOIN `employee`
ON ((`posts`.`isEmp` = `employee`.`idEmp`)))
JOIN `view_factory_income`
ON ((`posts`.`idFactory` = `view_factory_income`.`idFactory`)));
В листинге 2.4 представлен SQL-запрос на выборку помещений и доходу
от каждого из них.
Листинг 2.4 – SQL-запрос на формирование списка всех помещений и доходу от
каждого из них
SELECT
`view_factory_service`.`idFactory` AS `idFactory`,
`view_factory_service`.`NameFactory` AS `NameFactory`,
SUM(`view_factory_service`.`Income`) AS `Fact_income`
FROM `view_factory_service`
GROUP BY `view_factory_service`.`idFactory`,
`view_factory_service`.`NameFactory`;
В листинге 2.5 представлен SQL-запрос на выборку по каждой услуге и
чистой доходности в помещении.
Листинг 2.4 – SQL-запрос на формирование списка по каждой услуге и чистой
доходности в помещении
SELECT
`factory`.`idFactory` AS `idFactory`,
`factory`.`NameFactory` AS `NameFactory`,
`view_service_income`.`NameService` AS `NameService`,
`view_service_income`.`Income` AS `Income`
FROM ((`servicefactory`
JOIN `factory`
ON ((`servicefactory`.`idFactory` = `factory`.`idFactory`)))
JOIN `view_service_income`
ON ((`view_service_income`.`idService` = `servicefactory`.`idService`)));
2.3 Руководство программиста
При разработке программного продукта использовались следующие программно-аппаратные ресурсы:
22
− стандартная клавиатура;
− манипулятор «мышь»;
− процессор Intel® Celeron® CPU N3050 @ 1.60 GHz;
− ОЗУ (оперативное запоминающее устройство) 8 Гб;
− среда разработки приложений «Embarcadero Rad Studio 2010»;
− СУБД MySQL 5.5;
− программа для администрирования dbForge Studio 2019 for MySQL;
− генератор отчетов Fast Report 4;
− язык программирования Delphi.
Установка программы осуществляется путем переноса папки с программой с носителя на компьютер пользователя. Запуск производится exe-файлом
после запуска базы данных.
2.4 Руководство пользователя
Пользователь, попав на главную форму, может перейти в любую из доступных таблиц, отображённых на навигационной панели сверху. Пример
отображения таблицы рисунок 2.4.
Рисунок 2.4 – Главная форма
Для фильтрации записей, нужно выбрать одно из условий фильтрации:
клиент, сотрудник, услуги, зал. После ввода данных для фильтрации, информация в таблице будет отфильтрована, примеры показаны на рисунках 2.5–2.7.
23
Рисунок 2.5 – Фильтрация по клиентам
Рисунок 2.6 – Фильтрация сотрудников
24
Рисунок 2.7 – Фильтрация услуг
Пользователь может воспользоваться функцией поиска. Для этого в поисковую строку, расположенную сверху прямо под таблицей, необходимо ввести
поисковой запрос. Поиск осуществляется по всем полям, рисунок 2.8.
Рисунок 2.8 – Поиск
25
В таблицах редактирование записей расположено внизу активной таблицы. Необходимо нажать на «Добавить», «Изменить, «Удалить», и появится активная панель для редактирования данных (Рисунки 2.9–2.10)
Рисунок 2.9 – Режим добавления клиента
Рисунок 2.10 – Режим добавления записи
Для того, чтобы пользователь имел наглядное представление о доходе по
каждому сотруднику, то необходимо зайти на форму «Employee» и нажать на
кнопку «Доход сотрудников». В результате, можно увидеть график дохода по
каждому сотруднику и возможность вывода отчета, рисунок 2.11.
26
Рисунок 2.11 – Вывод графика по доходности сотрудника
2.5 Тестирование программного продукта
Для того, чтобы удостовериться в работоспособности программного продукта,
возможности выполнения всех заданных в техническом задании транзакций,
корректности реализации бизнес–правил, поведении программного продукта
при ошибочных действиях пользователя (неправильный ввод данных,
внештатное прерывание работы программного продукта, попытка обращения к
недоступным для него данным и т. п.) было проведено тестирование при
объёме данных примерно в 150 строк записей. В результате процесса
тестирования были устранены основные неточности и ошибки в логике работы,
произведено добавление проверяющих условий и информационных окон об
ошибках. Ошибки и результаты тестирования обобщены в таблице 2.1.
Таблица 2.1 – Результаты тестирования
№
1
Цель испытания
Проверка корректности работы объектов
ввода
2
Проверка корректности средств отображения табличных данных
Объект
Объекты ввода, представленные в окнах «Записи»,
«Сотрудники»,
«Клиенты», «Материалы по
услугам», «Себестоимость
товаров»,
«Материалы», «Тип процедуры»,
«Услуги зала», «Залы»,
«Услуги»
Объекты вывода табличных
данных, представленные в окнах: «Клиенты», «Материалы
по услугам», «Себестоимость
товаров»,
27
Результат
Все поля позволяют ввести корректные данные, ввод
некорректных данных
не позволяется
Табличные данные
выводятся корректно
3
4
5
6
7
Проверка корректности работы SQL запросов
Проверка корректности работы отчетов
Проверка корректности работы графиков
Поверка корректности
поиска необходимых данных
Проверка обновления графиков, в зависимости от установленного
фильтра
«Материалы», «Тип процедуры»,
«Услуги зала», «Залы»,
«Услуги»
SQL запросы, представленные на невизуальном модуле.
Отчеты, представленные в окнах
«Записи», «Материалы», «Себестоимость товаров»,
«Залы», «Клиенты»
Графики, представленные в окнах «Записи»,
«Клиенты»,
«Сотрудники»,
«Себестоимость товаров»,
«Услуги зала»,
«Залы», «Услуги»
Объекты ввода данных
для поиска в окне «Записи»
Графики, представленные в окнах «Клиенты»,
«Сотрудники»
SQL запросы правильно составлены и
отображаются
Все отчеты выводят
корректные результаты
Все графики выводят
корректные результаты
Продолжение таблицы 2.1
Поиск по данным выполняется корректно
Обновление графиков, в зависимости от
установленного
фильтра отображается корректно
В ходе тестирование большинство тестов были успешны. Ошибки, возникшие в ходе тестирования были успешно устранены.
Выводы по главе
Во второй главе курсовой работы была определена структура программного продукта. Произведён обзор спектра возможностей для приложения. Помимо этого, приведена краткая теория для бизнес–правил, а также построены
UML–диаграммы активности и прецедентов для большей наглядности возможностей программы. Для дальнейшего сопровождения программного продукта
написаны руководства программиста и пользователя.
Для того, чтобы убедиться в работоспособности и отказоустойчивости
проекта произведено тестирование программы. Ошибки, полученные в ходе тестирования
были
оперативно
исправлены.
28
ЗАКЛЮЧЕНИЕ
В результате выполнения курсовой работы была разработана автоматизированная система учета записей в салоне красоты.
Для этого сначала были рассмотрены варианты сервисов, автоматизирующий процесс записи клиентов. Затем было произведено концептуальное проектирование базы данных, построены таблицы, описывающие сведения о типах
сущностей проекта, сведения о типах связей проекта, а также построена ER–
модель. Выполнено логическое проектирование базы данных. Выбрана целевая
СУБД. Выбор производился среди трёх СУБД: PostgreSQL, MySQL и Oracle. По
итогам сравнения в качестве СУБД для курсового проекта стала СУБД MySQL.
Осуществлено физическое проектирование БД – описание структуры хранения
данных и эффективных методов доступа к данным базы. В ходе процесса физического проектирования базы данных была сформирована таблица с описанием физической реализации сущностей. База данных состоит из 9 таблиц.
При реализации проекта сначала была разработана структура приложения, затем разработаны бизнес–правила, которые были описаны при помощи
языка UML для большей наглядности возможностей программы. Написаны руководства программиста и пользователя для демонстрации работы программы и
дальнейшего её сопровождения. Произведено тестирование программы для того, чтобы убедиться в работоспособности и отказоустойчивости проекта.
По итогу курсовой работы была реализована автоматизированная система
салона красоты, позволяющая пользователю просмотреть список записей и связанную с ним информацию, добавить новые данные и вывести доходность салона в виде графиков. Со стороны пользователя были реализованы возможности для управления записями в БД, а именно их поиск, фильтрация, добавление,
удаление и редактирование.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1) Жданова К.Д., Заскалько Е.В. Системы управления бизнес-правилами в
условиях современного бизнеса // Международный студенческий научный
вестник. – 2015. – № 6.
2) Когаловский М.Р. Технология баз данных на персональных ЭВМ–
2013.
3) Тиори Т., Фрай Дж. Проектирование структур баз данных. М, –1985.
4) Хаббард Дж. Автоматизированное проектирование баз данных. М, –
1984.
5) Логическое проектирование [Электронный ресурс] Режим доступа:
URL: http://karpov–k.me/computernaya–nauka/bd/353–logicheskoe–proektirovanie–
bd (дата обращения 3.06.2020)
6) Основная информация Oracle [Электронный ресурс] Режим доступа:
URL: http://omega.ru/oracleinfo.html (дата обращения 3.06.2020)
7) Недостатки Oracle [Электронный ресурс] Режим доступа: URL:
https://kztarif.ru/kompjutery/oracle-pljusy-i-minusy (дата обращения 3.06.2020)
8) PostgreSQL и MySQL [Электронный ресурс] Режим доступа: URL:
https://devacademy.ru/article/sqlite-vs-mysql-vs-postgresql
9) 7 сервисов для онлайн–записи клиентов [Электронный ресурс] Режим
доступа: URL: https://secretmag.ru/business/methods/7–servisov–dlya–onlajn–
zapisi.htm (дата обращения: 3.06.2020).
ПРИЛОЖЕНИЕ А
ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ
Введение
На сегодняшний день запись клиентов в салон красоты происходит трудоемко. Для того, чтобы записать только одного клиента уходит очень много
времени. Девушка администратор должна найти нужный журнал, сообщить о
свободных датах и предоставляемых мастерах. Это занимает около 10 минут.
После всех манипуляций с журналом происходит запись клиента. Поэтому данный вид записи имеет недостатки такие, как: ошибки в записях, не читаемость
информации о клиенте, потеря журнала, порча журнала. В результате, салон теряет клиентов, а, следовательно, прибыль. В связи с этим разработка системы
учета записей в салоне красоты «BeautyAccounting» является актуальной задачей.
Общие положения.
Полное наименование: разработка системы учета записей в салоне красоты «BeautyAccounting».
Краткое наименование: «BeautyAccounting».
Вид разработки: информационно–справочная система.
Разработчик: Ооржак Ай-Кат Катовна.
Основание для разработки
Разработка системы учета записей в салоне красоты ведется на основании
учебного плана СибГУ им. М. Ф. Решетнева по направлению подготовки
09.03.02 «Информационные системы и технологии».
Плановые сроки начала и окончания выполнения работы
Плановый срок начала работ по разработке системы учета записей в салоне красоты «BeautyAccounting» – 20.02.2020
Плановый срок окончания работ по разработке системы учета записей в
салоне красоты «BeautyAccounting» – 13.06.2020
Назначение разработки
Разрабатываемый программный продукт предназначен для организации
работы администратора и бухгалтера салона красоты.
Требования к программе
Требования к функциональным характеристикам
В системе учета записей в салоне красоты должно быть предусмотрено
защита от некорректного ввода данных в виде скрывающейся панели.
Системы учета записей в салоне красоты должна:

просмотр информации о записях;
 поиск и фильтрация записей;
 добавление данных (новый клиент, сотрудник, материал по услугам,
товар, услуга, зал, форматы;
 представление статистической информации в виде графиков.
Ввод данных должен выполняться в таблицах программы через exe–файл.
Вывод информации должен выполняться в виде таблиц приложения.
Создаваемые отчеты в системе учета записей в салоне красоты должны
предоставлять следующую информацию:
 список товаров по типам услуг;
 список записей по услугам;
 список записей по залам;
 список клиентов;
 список товаров с себестоимостью.
Требования к надежности
В системе учета записей в салоне красоты должен быть обеспечен контроль за корректностью введённых данных. Возникновение каких–либо внутренних ошибок не должно приводить к утере данных. Система учета записей в
салоне красоты должна быть отказоустойчива.
Для защиты от несанкционированного использования должно быть
предусмотрено ограничение на вход в систему.
Условия эксплуатации
Приложение рассчитано на эксплуатацию пользователями салона
красоты.
Требования к составу и параметрам технических средств
 процессор: Intel Pentium 4 и более поздней версии 1 ГГц и выше;
 ОЗУ (оперативное запоминающее устройство): 1 Гб.
Требования к информационной и программной совместимости
 Операционная система: Windows 10.
 ODBC-драйвер для MySQL версии не менее 5.2.6.
Состав и содержание работ по выполнению курсовой работы
Таблица А.1 – Календарный план–график выполнения стадий и этапов разработки
Наименование работ
Анализ информационных потоков в сфере салонов красоты
Обзор сервисов для салонов красоты
Концептуальное проектирование базы данных
Разработка бизнес–правил
Логическое проектирование базы данных
Выбор целевой СУБД
Физическое проектирование базы данных
Разработка структуры программного продукта
Разработка пользовательского интерфейса
Программная реализация системы учета записей в салоне красоты
Разработка отчетов и графиков
Тестирование и отладка системы учета записей в салоне красоты
Оформление пояснительной записки
Предоставление преподавателю всех необходимых для защиты материалов
32
Сроки
выполнения
23.02.2020
27.02.2020
05.02.2020
01.03.2020
16.03.2020
18.03.2020
01.04.2020
10.04.2020
15.04.2020
15.05.2020
20.05.2020
24.05.2020
06.06.2020
13.06.2020
ПРИЛОЖЕНИЕ Б
ПРИМЕРЫ ОТЧЕТОВ И ГРАФИКОВ
Рисунок B.1 – Список записей
Рисунок B.2 – Себестоимость услуг
Рисунок B.3 – Список клиентов
34
Рисунок B.4 – Список материалов
35
Рисунок B.5 – Доход сотрудников
Рисунок B.6 – График по доходам всех записей
36
Рисунок B.7 – График по доходам сотрудников
Рисунок B.8 – График по доходам от клиентов
37
Рисунок B.9 – График по себестоимости материалов
Рисунок B.10 – График дохода услуг в залах
Рисунок B.11 – График дохода услуг
38
Рисунок B.12 – График дохода в залах
39
Скачать