3 Проектирование бд
-
UML-моделирование
Для более полного представления о программе и расширенного понимания задачи, были построены наглядные UML диаграммы, которые дают более полное описание программного продукта, который будет создан в графическом виде.
UML – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью.
На рисунке 3.1 приведена диаграмма прецедентов, которая более наглядно показывает функционал создаваемого программного продукта.
Пользователь
Создание произвольного запроса к БД
Добавление: клиента, места, экскурсии
Удаление: клиента, места, экскурсии
Поиск: клиента, места, экскурсии
Редактирование: клиента, места, экскурсии
Формирование отчетов
Оформление заказа
Рисунок 3.1 – Диаграмма прецедентов
В программе выполняется большое количество действия, поэтому для того чтобы дать более полую картинку о том как они происходят и что они собой представляют, была построена диаграмма деятельности, которая разбита на несколько частей из-за своей объёмности. Первая из них, на рисунке 3.2, где отображены реализации таких функций как редактирование, добавление и удаление из таблиц. Следующая диаграмма иллюстрирует действия, которые будут происходить в программе при поиске, диаграмма приведена на рисунке 3.3.
На рисунке 3.4 приведена диаграмма, которая показывает, каким образом будет формироваться отчёт в программе.
Одной из наиболее важных диаграмм, является диаграмма, которая описывает графическим образом задачу автоматизации, которая будет реализована в программе. Она представлена на рисунке 3.5.
Выход
Добавление
Удаление
Выход
Заполнение
Заполнено корректно
Да
Внесение в базу
Нет
Выбор элемента
Подтверждение
Да
Удаление из базы
Нет
Редактирование
Выбор элемента
Внесение изменений
Заполнено корректно
Да
Нет
Внесение в базу
Рисунок 3.2 – Диаграмма действий для добавления, удаления, редактирования
Выбор таблицы
Не выбрана
Выбрана
Выбор типа поиска
Выдача результатов
Заполнение полей
Поиск в базе
Конец
Рисунок 3.3 – Диаграмма действия для поиска
Выбор типа отчета
Не выбран
Выбран
Формирование
Печатать?
Нет
Да
Печать
Конец
Рисунок 3.4 – Диаграмма действия для формирования отчётов
Получение страницы с информацией о месте с сайта
Ввод названия места
Длинна текста >0
Да
Нет
Парсинг полученной страницы встроенным парсером.
Соединение с сайтом в интернете и передача ему названия места
Место есть на сайте
Да
Распределение полученных данных в полях на форме для заполнения информации о месте
Нет
Сообщение о том что информацию о месте получить не удалось
Конец
Рисунок 3.5 – Диаграмма действия для задачи автоматизации
-
ER-диаграмма
ER-модель удобна при прототипировании (проектировании) информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями.
Главные сущности: «Клиенты», со свойствами: ID, Статус, ФИО, Контактные данные, которые являются оптимальным и минимальным набором данных при использовании в базе данных. «Экскурсии», со свойствами: ID, Стоимость, Длительность, Услуги, Название. «Места», со свойствами: ID, Климат, Условия, Местоположение.
Также введены две промежуточные сущности, такие как «Заказы», с полями ID клиента, ID экскурсии и Дата заказа, что является удобным при необходимости просмотра всех заказов на определённую дату или же получения информации по клиентам которые заказали ту или иную экскурсию. Другая дополнительная сущность – «Порядок», которая содержит поля: ID экскурсии, ID места и № маршрута. С помощью этой сущности можно легко получать список мест по заданному туру, список туров по указанному месту.
Сущность «Клиенты», связана с сущностью «Заказы» как один ко многим, аналогично сущность «Экскурсии» связана с сущностью «Заказы».
Также сущность «Экскурсии» связана с сущностью «Порядок», связью один ко многим соответственно. Сущность «Места» связана с сущностью «Порядок» связью один ко многим соответственно. На рисунке 3.6 представлена ER-диаграмма.
Клиенты
ID*
ФИО
Конт. Данные
Статус
Экскурсии
ID экскурсии *
Длительность
Стоимость
Услуги
Название
1
Заказы
ID клиента *
ID экскурсии
Дата*
1
1
∞
∞
Порядок
ID экскурсии *
ID места
№ маршрута *
∞
∞
Место
ID места *
Климат
1
Местополо-жение
Условия
Рисунок 3.6 – ER-диаграмма
-
Схема базы данных в третьей нормальной форме
В ходе составления базы данных для программы, построении ER диаграммы, мы получили 4 таблицы: «Клиенты», «Заказы», «Экскурсии», «Место», каждая из которых имеет свои ключи, свои уникальные названия полей. Рассмотрим первую таблицу «Клиенты» (см. таблица 3.1), чтобы доказать что она находится в третьей нормальной форме.
У таблицы «Клиенты», существует свою уникальный ключ – ID клиента, который ни разу не повторяется, то есть исключает возможность возникновения одинаковых кортежей. Также в таблице нет упорядочивания по строкам или столбцам. Каждый из атрибутов таблицы имеет не повторяющееся значение и разные по названию (ID клиента, ФИО, Контактные данные, Статус), а также в таблице строки не имеют идентификаторов кроме обычных значений потенциальных ключей. В таблице все атрибуты зависят от одного ключа таблицы (ID клиента), и нет транзитивной зависимости, то есть таблица Клиенты, находится в 3 нормальной форме.
Таблице клиенты аналогичны такие таблицы, как «Экскурсии», таблица 3.3 и «Места», таблица 3.5.
Таблицы же 3.2 и 3.4 «Заказы» и «Порядок» соответственно, имеют небольшие отличия от вышеописанных, имеют по 2 ключевых атрибута, а всего их 3, в каждой из таблиц, атрибуты являются атомарными, поскольку содержат лишь простые числовые атрибуты, такие как дата, ID и номер. В таблице «Заказы», однозначно можно определить заказ по ID клиента и по Дате, можно однозначно определить клиента и экскурсию, которую он заказал, так как у каждого клиента есть на одну дату возможен лишь один заказ. Поэтому, исходя из вышесказанного таблица «Заказы» находится в 3 нормальной форме.
Рассматривая «Порядок», прослеживается аналогия с таблицей «Заказы». Имея ID экскурсии, ID места и номер места в маршруте экскурсии, мы исключаем возможность дублирования, какого либо из полей, у каждой экскурсии, есть несколько неповторяющихся номеров, которым соответствуют определённые места в колонке с ID места. Ключами в таблице служат ID экскурсии и номер маршрута.
Нет противоречий тому, что таблица находится в третьей нормальной форме, поэтому таблица «Порядок» находится в третьей нормальной форме.
Схема данных, которая будет использована в программе, приведена на рисунке 3.7.
Таблица 3.1 – Клиенты
|
ID клиента* |
ФИО |
Контактные данные |
Статус (рассчитываемая сумма) |
|
2 |
Иванов Павел Григорьевич |
г. Киев, ул. Шевченка, 12 |
25000 |
Таблица 3.2 – Заказы
|
ID клиента* |
ID экскурсии |
Дата* |
|
2 |
6 |
12.03.2011 |
Таблица 3.3 – Экскурсии
|
ID экскурсии * |
Длительность |
Стоимость |
Услуги |
Название |
|
6 |
25 |
20000 |
Все включено |
Чешский отдых |
Таблица 3.4 – Порядок
|
ID экскурсии* |
ID места* |
№ маршрута |
|
6 |
2 |
1 |
|
6 |
1 |
3 |
Таблица 3.5 – Места
|
ID места* |
Климат |
Условия |
Местоположение |
|
2 |
Умеренно-континентальный |
Повышенная влажность воздуха, малая загрязненность атмосферы, отсутствие промышленности. |
Градец-кралове
|
|
1 |
Умеренно-континентальный |
Столица умеренная шумноть, повышенная влажность воздуха, мягкая зима. |
Прага |
|
5 |
Умеренно-континентальный |
Маленький городок, спокойствие, тишина, развитая инфраструктура. |
Пльзень |
|
3 |
Экваториальный |
Жара, 365 дней в году солнце, буйная растительность, |
Африка |
Рисунок 3.7 – Схема данных