Файл: Кафедра прикладной информатики Выпускная квалификационная работа разработка мобильного приложения "салон красоты "beautyshop"" на платформе apache cordova.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 109
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
14
В данной работе преимущественно применяется связь "1:М". Это объясняется характеристикой самой базы данных, в которой присутствуют пять связей "один-ко-многим" и одна связь "один-к-одному".
2.2.4. ER - диаграмма
На основании таблицы 3 можно построить ER - диаграмму (рис.7).
Рис. 7 "ER - диаграмма"
ER - диаграмма является стратегической моделью при разработке приложения и служит основой для логического проектирования.
2.3. Логическое проектирование
Приложение разрабатывается по технологии «клиент-сервер». Для реализации серверной части выбрана реляционная модель данных и используется СУБД MySQL.
Цель второй фазы проектирования состоит в создании логической модели данных для исследуемой части предприятия. Таким образом, данная фаза логического проектирования предполагает, что мы определим функциональные зависимости, проведем нормализацию данных и проверим целостность данных.
15
2.3.1. Таблицы и атрибуты
Объекты и атрибуты переходят в таблицы и атрибуты (табл.4).
Таблица 4. Таблицы и атрибуты
Объект
Таблица
Атрибут
Первичный ключ
Салон
Салон
Код_салона
Адрес_салона
Телефон_салона
Название_салона
Код_салона
Сотрудники
Сотрудники
Код_сотрудника
ФИО_сотрудника
Должность
Телефон_сотрудника
Код_сотрудника
Клиенты
Клиенты
Код_клиента
Имя_клиента
Телефон_клиента e-mail
Логин
Пароль
Код_клиента
Услуги
Услуги
Код_услуги
Название_услуги
Цена_услуги
Код_услуги
Запись
Запись
Код_записи
Код_клиента
Код_сотрудника
Время_записи
Отмена_записи
Код_записи
Гостевая книга
Гостевая книга Код_отзыва
Имя_клиента
Отзыв
Дата
Код_отзыва
16
2.3.2. Функциональные зависимости между атрибутами
Функциональная зависимость определяется для атрибутов, находящихся в одном и том же отношении в 1НФ. На основе функциональных зависимостей формулируется определение всех прочих видов зависимостей.
ФЗ1 Код_салона Адрес_салона, Телефон_салона,
Название_салона;
ФЗ 2 Код_сотрудника ФИО_сотрудника, Должность,
Телефон_сотрудника;
ФЗ 3 Код_клиента Имя_клиента, Телефон_клиента, e-mail, Логин, Пароль;
ФЗ 4 Код_услуги Название_услуги, Цена_услуги;
ФЗ 5 Код_записи, Время_записи, Отмена_записи,
Код_клиента, Код_сотрудника;
ФЗ 6 Код_ отзыва Имя_клиента, Отзыв, Дата.
2.3.3. Нормализация данных
Для приложения необходимо, чтобы все отношения обязательно находились в 1НФ. Грамотный специалист стремится к тому, чтобы довести уровень нормализации хотя бы до 3НФ, тем самым исключив избыточность данных. В процессе нормализации на каждом этапе производится анализ первоначальных отношений, в результате которого выявляются зависимости между данными.
Таблицы: САЛОН, СОТРУДНИКИ, КЛИЕНТЫ, УСЛУГИ, ЗАПИСЬ,
ГОСТЕВАЯ КНИГА находятся в 1НФ, так как не имеют сложных атрибутов
(табл.4).
17
Таблицы: САЛОН, СОТРУДНИКИ, КЛИЕНТЫ, УСЛУГИ находятся в
1НФ и имеют простые первичные ключи (табл.4), поэтому они автоматически приведены к 2НФ.
Таблица САЛОН находится в 2НФ и отсутствуют функциональные зависимости между неключевыми атрибутами
Адрес_салона,
Телефон_салона, Название_салона (ФЗ 1) , поэтому она приведена к 3НФ.
Таблица СОТРУДНИКИ находится в 2НФ и отсутствуют зависимости между неключевыми атрибутами
ФИО_сотрудника,
Должность,
Телефон_сотрудника (ФЗ 2), поэтому она приведена к 3НФ.
Таблица КЛИЕНТЫ находится в 2НФ и отсутствуют зависимости между неключевыми атрибутами Имя_клиента, Телефон_клиента, e-mail,
Логин, Пароль (ФЗ 3), поэтому она приведена к 3НФ.
Таблица УСЛУГИ находится в 2НФ и отсутствуют связи между неключевыми атрибутами Название_услуги, Цена_услуги (ФЗ 4), поэтому она приведена к 3НФ.
Таблица ЗАПИСЬ находится в 1НФ (табл.4), неключевой атрибут
Время_записи и Отмена_записи функционально полно зависит от ключа
Код_записи (табл.4), поэтому она приведена к 2НФ.
Таблица ЗАПИСЬ находится в 2НФ и отсутствуют связи между неключевыми атрибутами Код_записи, Код_клиента, Код_сотрудника,
Время_записи, Отмена_записи (ФЗ 5), поэтому она приведена к 3НФ.
Таблица ГОСТЕВАЯ КНИГА находится в 2НФ и отсутствуют зависимости между неключевыми атрибутами, Имя_клиента, Отзыв, Дата
(ФЗ 6), поэтому она приведена к 3НФ.
18
2.3.4. Реляционные отношения
В реляционной ИС связи позволяют избежать избыточности данных. Связи с обеспечением целостности данных позволяют следить за тем, чтобы данные в одной таблице соответствовали данным в другой. Чтобы сохранить синхронизацию, следует обеспечить целостность данных между таблицами. Для связи таблиц используется механизм первичных и внешних ключей (табл.5).
Таблица 5. Связи между таблицами
Связь
Таблицы
Статус таблицы Ключи
Работает
Салон
Сотрудник
Родительская
Дочерняя
Код_салона(ПК)
Код_сотрудника(ПК)
Код_салона(ВК)
Предоставляет
Услуги
Салон
Дочерняя
Родительская
Код_услуги(ПК)
Код_салона(ВК)
Код_салона(ПК)
Выбирает
Услуги
Клиент
Дочерняя
Родительская
Код_услуги (ПК)
Код_клиента(ВК)
Код_клиента(ПК)
Записывается
Сотрудник
Клиент
Дочерняя
Родительская
Код_записи(ПК)
Код_
сотрудника(ВК)
Код_клиента(ПК)
Отменяет
Запись
Клиент
Дочерняя
Родительская
Код_записи(ПК)
Код_клиента(ВК)
Код_клиента(ПК)
Пишет
Гостевая книга
Клиент
Дочерняя
Родительская
Код_отзыва(ПК)
Код_клнента(ВК)
Код_клиента(ПК)
19
2.3.5. Обеспечение целостности данных
Целостность базы данных гарантирует корректность данных.
Поддержка целостности БД реализуется посредством ряда ограничений, накладываемых на данные. Данные ограничения мы разделили на три типа целостности: категорная, ссылочная и доменная.
1. Категорная – такая целостность ограничивает набор значений первичных ключей базовых отношений.
Значения первичных ключевых атрибутов Код_салона (САЛОН),
Код_сотрудника (СОТРУДНИКИ), Код_клиента (КЛИЕНТЫ), Код_услуги
(УСЛЫГИ), Код_записи (ЗАПИСЬ), Код_отзыва (ГОСТЕВАЯ КНИГА) должны быть индексированными и не могут быть отсутствующими. Кортеж не может записываться, пока значение его ключевого атрибута не будет полностью определено.
2. Ссылочная – при построении отношений для связывания строк одной таблицы со строками другой таблицы используются внешние ключи. База данных, в которой все непустые внешние ключи ссылаются на текущие значения ключей другого отношения, обладает целостностью на уровне ссылок.
Значения внешних ключевых атрибутов Код_салона (СОТРУДНИК),
Код_сотрудника
(ЗАПИСЬ),
Код_клиента
(УСЛУГИ),
Код_услуги,
Код_отзыва (ГОСТЕВАЯ КНИГА) не могут быть отсутствующими и должны быть индексированными, т.к. ссылка на отсутствующее значение запрещена.
3. Доменная – ограничения на значения неключевых атрибутов.
Ограничения на значения неключевых атрибутов. Данные ограничения записаны в таблице 6.
20
Таблица 6. Доменная целостность
Атрибут
Ограничение
Название_салона
Обязательное: да
Адрес_салона
Обязательное: да
Телефон_салона
Обязательное: да
Имя_клиента
Обязательное: да
Название_услуги
Обязательное: да
Цена_услуги
Обязательное: да
Цена > 0
Время_записи
Дата и время не могут быть меньше текущей даты на момент записи клиента
2.3.6. Реляционная схема данных
Реляционная схема данных – это конечный набор отношений.
Рис.8. " Реляционная схема данных"
Отношения используются для представления объектов, а так же для представления связей между объектами.
21
2.4. Проектирование пользовательского интерфейса
Пользовательский интерфейс мобильного приложения является одним из важнейших компонентов системы. Проектирование пользовательского интерфейса является неотъемлемой частью разработки базы данных.
Интерфейс пользователя является точкой взаимодействия человека и программы. От того насколько удобным будет разработанный интерфейс пользователя будет зависеть и успех продукта.
В основу создания данного приложения положен принцип экономии времени и усилий пользователя, предполагая, что смартфон берет на себя все функции.
2.4.1. Диаграмма прецедентов
Для описания функциональных возможностей системы используется
UML-средство Rational Rose. Возможности определяются прецедентами, каждый из которых представляет определенный способ использования системы.
Функциональные возможности сотрудников предприятия можно представить, используя диаграмму прецедентов (рис.9,10)
Рис.9 "Главная диаграмма прецедентов"
22
Рис.10 "Вспомогательная диаграмма прецедентов"
Актеры:
Сотрудники (работа с клиентами, просмотр и редактирование информации о салоне, о сотрудниках, редактирование услуг);
Клиенты (используют приложение для просмотра информации о салоне, услугах, мастеров и для записи/отмены записи).
На основании вышеизложенного выделяем следующие прецеденты:
Работа с клиентами;
Просмотр и редактирование информации о салоне;
Просмотр и редактирование информации о сотрудниках;
Просмотр и редактирование услуг;
Просмотри редактирование новостей и акций салона;
Просмотр расписания;
Запись к мастеру.
2.4.2. Диаграммы взаимодействия
Для того чтобы рассмотреть упорядоченность сообщений при выполнении бизнес – процессов, требуемых для функционирования системы, создадим диаграммы взаимодействия для каждого из них.
23
На диаграммах взаимодействий показывают связи, включающие множество объектов и отношений между ними, в том числе сообщения, которыми объекты обмениваются.
Бизнес-процесс "Регистрация клиента"
Бизнес – процесс "Регистрация клиента" состоит из следующей последовательности сообщений:
Проверка, есть ли клиент в базе
Если да, то регистрация не нужна
Если нет, то зарегистрировать
На рисунке 11 представлена диаграмма взаимодействия данного бизнес
– процесса.
На рисунке 12 представлена диаграмма последовательности действий бизнес - процесса"Регистрация клиента".
Рис.11. "Диаграмма взаимодействия бизнес-процесса регистрация клиентов"
24
Рис.12 Диаграмма последовательности действий бизнес - процесса "Регистрация клиента"
Бизнес-процесс "Предоставление услуг"
Бизнес – процесс "Предоставление услуг" состоит из следующей последовательности сообщений:
Выбор даты
Выбор мастера
Запись клиента
На рисунке 13 представлена диаграмма взаимодействия данного бизнес
– процесса.
На рисунке 14 представлена диаграмма последовательности действий бизнес - процесса"Предоставление услуг".
25
Рис.13 Диаграмма взаимодействия бизнес-процесса предоставление услуг"
Рис.14 Диаграмма последовательности действий бизнес - процесса "Предоставление услуг"
26
2.4.3. Эскиз пользовательского меню
Исходя из диаграмм
(рис.9-14) можно разработать эскиз пользовательского меню приложения (рис.15-16).
Рис.15 Эскиз меню неавторизованного пользователя
Рис16. Эскиз меню авторизованного пользователя
Главное меню неавторизованного пользователя
Авторизация/Регистрация
О нас
Услуги
Отзывы
Позвонить
Главное меню авторизованного пользователя
Новости и акции (домашняя страница)
О нас
Запись
Мои записи
Отзывы
Позвонить
Услуги
Перечень услуг
Подуслуги
Запись по телефону.
Запись
Перечень услуг
Подуслуги
Выбор мастера
Выбор даты
Выбор времени
Запись.
27
2.4.4. Команды и назначения
Таблица 7. Главное меню неавторизованного пользователя
Команда
Назначение
Авторизация/Регистрация Авторизация/регистрация пользователя и переход в меню
О нас
Просмотр информации о салоне "BeautyShop"
Услуги
Просмотр информации об услугах (Цена, название)
Отзывы
Просмотр, написание отзыва
Позвонить
Звонок в салон
Таблица 8. Меню "Услуги" неавторизованного пользователя
Перечень услуг
Просмотр услуг
Подуслуги
Просмотр информации о подуслуге (Название, цена)
Запись по телефону
Кнопка. Звонок в салон
Таблица 9. Главное меню авторизованного пользователя
Команда
Назначение
Новости и акции
Просмотр новостей и акций салона
О нас
Просмотр информации о салоне "BeautyShop"
Запись
Просмотр информации об услугах, сотрудниках и запись с выбором даты и времени
Мои записи
Просмотр информации о записях
Отзывы
Просмотр, написание отзыва
Позвонить
Звонок в салон
Таблица 10. Меню "Запись" авторизованного пользователя
Перечень услуг
Просмотр услуг
Подуслуги
Просмотр информации о подуслуге (Название, цена)
Выбор мастера
Просмотр информации о мастерах
Выбор даты
Просмотр и выбор доступной даты
Выбор времени
Просмотр и выбор доступного времени
Запись
Кнопка записаться