Результат тестирования информационной системы

 

 

Рисунок 4 – Декомпозиция процесса «Автоматизировать работу с информацией об автобусах»

 

 

Рисунок 5 – Декомпозиция процесса  «Автоматизировать работу с информацией о рейсах»

 

 

Рисунок 6 – Декомпозиция процесса «Автоматизировать процесс продажи билетов»

 

 

2.1.2 Диаграмма дерева узлов

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

На диаграмме дерево узлов нижний уровень детализации представляется в виде списка, остальные процессы в виде прямоугольников.

Диаграмма дерева узлов  проектируемой базы данных представлена на рисунке 10.

 

Рисунок 7 – Диаграмма дерева узлов

 

2.2 Информационная модель

2.2.1 Идентификация сущностей и связей. ER-диаграмма логического уровня

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

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

- «Отделы» – для фиксации информации о водителях автостанции. Содержит паспортные данные водителя, его фамилию, имя, отчество и телефон;

- «Рейсы» – для хранения информации о рейсах. Содержит номер рейса, его время отправления автобуса, дни недели по которым осуществляется перевозка, расстояние между пунктами, начальный и конечный пункт отправления;

- «Автобусы» – для хранения информации об автобусах. Содержит номер, тип, количество мест в автобусе, маршрут по которому осуществляется перевозка пассажиров и марка автобуса;

- «Продажа» – хранится информация о продажи билетов. Содержит информацию о номере продажи, дате, времени отправления, с какой платформы отправляется автобус, с какой станции, до какой, указывается номер рейса, номер автобуса, номер места, количество билетов в автобусе и расстояние между выбранными пунктами.

Для однозначного определения  записей в каждом из отношений  выделен первичный ключ (простой  или составной).

Внешние ключи для  отношений БД:

• в отношениях «Водители» и «Продажа» - это ключ «Паспортные данные»;
• в отношениях «Рейсы» и «Продажа» - это ключ «Номер рейса»;
• в отношениях «Автобусы» и «Продажа» - это ключ «Номер автобуса».

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

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

Связь между сущностями «Рейсы» и «Продажа» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждая продажа закреплена за определенным рейсом. Тип связи 1 ко многим, т.к. на один рейс продается несколько билетов.

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

ER-диаграмма логического уровня представлена на рисунке 8.

Рисунок 8 – ER-диаграмма логического уровня

 

2.2.2 ER-диаграмма физического уровня. Ограничения ссылочной целостности. Определение триггеров

Физическая модель данных зависит от конкретной СУБД. В ней  содержится информация обо всех объектах БД.  Одной и той же логической модели может соответствовать несколько разных физических. В физической модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах. 

Проверим, удовлетворяют  ли все имеющиеся отношения соответствующим наборам ограничений.

Первая нормальная форма требует, чтобы значения всех атрибутов отношения были атомарными. При рассмотрении информационной модели было отмечено, что значения атрибутов всех отношений логически разделить на элементы нельзя и, следовательно, они удовлетворяют условию первой нормальной формы. Пример, рассмотрим таблицу «Водители». Ключевой атрибут в ней – «Паспортные данные» не может быть разделен на элементы.  Неключевые атрибуты – «Фамилия», «Имя», «Телефон» также являются атомарными.

Вторая нормальная форма требует, чтобы отношение находилось в первой нормальной форме, и каждый неключевой атрибут функционально полно зависел от первичного ключа. И это требование также выполняется в рассматриваемой модели. Пример, рассмотрим таблицу «Водители». Ключевой атрибут в ней – «Паспортные данные». Неключевые атрибуты – «Фамилия», «Имя», «Телефон» зависят функционально полно только от первичного ключа.

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

Опишем используемые типы данных.

Рассмотрим таблицу «Рейсы». Ключевое поле этой таблицы «Номер рейса». Номер представляет собой набор цифр (например, 32). Следовательно, тип данных поля «Номер рейса» должен быть числовым целым. Выбираем тип int.

В таблице «Водители» имеется ключевое поле «Паспортные данные». Это поле содержит две первые буквы и 7 цифр (например, КВ1238743). Тип данных для него – varchar(30) .

В таблице «Автобусы» имеется ключевое поле «Номер автобуса». Это поле содержит набор цифр (например, 321). Тип данных для него – int .

В таблице «Продажа». Ключевое поле этой таблицы (Номер продажи) представляет собой номер, который присваивает каждой продажи номер по порядку. Он представляет собой набор цифр (например, 1). Следовательно, тип данных поля табельный номер должен быть числовым целым. Выбираем тип int.

Для приложения были разработаны следующие триггеры:

– a1_3  срабатывает при вставке новых элементов в таблицу «Водители». Он проверяет нет ли незаполненных полей таблицы;

– а2_4 срабатывает при вставке новых элементов в таблицу «Рейсы». Он проверяет, нет ли незаполненных полей таблицы;

– а3_3 срабатывает при вставке новых элементов в таблицу «Автобусы». Он проверяет нет ли незаполненных полей таблицы;

– а4_4 срабатывает при вставке новых элементов в таблицу «Продажа». Он проверяет, нет ли незаполненных полей таблицы;

– а4_5 срабатывает при вставке в поле «Номер места», таблицы «Продажа», большее значение, чем в поле «Количество мест» таблицы «Автобусы»;

ER-диаграмма физического уровня показана на рисунке 9.

Рисунок 9 – ER-диаграмма физического уровня

 

2.2.3 Определение представлений, хранимых процедур серверной компоненты

Представление (View) для конечных пользователей выглядит как таблица, но при этом само не содержит данных, а лишь представляет данные, расположенные в таблице. Физически представление реализовано в виде SQL-запроса, на основе которого производится выборка данных из одной или нескольких таблиц или представлений.

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

Для приложения были разработаны  следующие представления:

– а1_1 информация о водителях, которых зовут. Содержит информацию из таблицы «Водители;

– а1_2 информация о водителях, телефоны которых имеют код 33. Содержит информацию из таблицы «Водители»;

– а2_1_1 информация о рейсах, у которых конечным пунктом является Могилёв. Содержит информацию из таблицы «Рейсы»;

– а2_2 информация о рейсах,  у которых «Время отправления» с 8:00 до 12:00 и конечный пункт - Кричев. Содержит информацию из таблицы «Рейсы»;

– а2_3 информация о рейсах, которые отправляются по всем дням недели. Содержит информацию из таблицы «Рейсы»;

– а3_1 информация об автобусах, марка которых является Икарус. Содержит информацию из таблицы «Автобусы;

– а3_2 информация об автобусах, у которых маршрут имеет начальный пункт Чериков и тип автобуса - мягкий. Содержит информацию из таблицы «Автобусы»;

– а4_1 информация о продаже билетов, дата отправления которых 02. 12.2013. Содержит информацию из таблицы «Продажа»;

– а4_2 информация о продаже билетов, которые куплены предварительно и номер автобуса - 321. Содержит информацию из таблицы «Продажа;

– а4_3 информация о количестве проданных билетов за каждый день. Содержит информацию из таблицы «Продажа».

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

Для приложения были разработаны  следующие хранимые процедуры:

• a1_5 -  поиск данных о водителях по номеру телефона в таблице «Водители» ;
• a3_6_1 – поиск данных о водителях по фамилии в таблице «Водители»;
• а3_6_2 – поиск данных о водителях по их паспортным данным в таблице «Водители»;
• а3_6_3 – поиск данных о водителях, которые участвовали в поездках, в таблицах «Водители» и «Продажа»;
• а3_5 – поиск информации об автобусах по типу в таблице «Автобусы»;
• а2_6 – поиск информации об автобусах по маршруту в таблице «Автобусы»;
• а3_7 – поиск информации об автобусах, которые имеют количество мест меньше выбранного в таблице «Автобусы»;
• а3_6 – вывод информации о количестве имеющихся типов автобусов в таблице «Автобусы»;
• a3_6_4 – поиск информации об автобусах по марке в таблице «Автобусы»;
• а2_7 – поиск информации о рейсах по дням недели и по начальному пункту отправления в таблице «Рейсы»;
• а3_8 – поиск информации о рейсе, у которого самая низкая стоимость в таблице «Рейсы»;
• а3_6_9 – поиск информации о рейсах по конечному пункту в таблице «Рейсы»;
• а4_8 – поиск информации о проданных билетах в выбранном диапазоне в таблице «Продажа»;
• а4_9 – вывод информации о стоимости проданных билетах в таблице «Продажа»;
• а1_12 – поиск информации о проданных билетах по номеру рейса в таблице «Продажа».

 

2.3 Верификация спроектированной  логической модели

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

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

 

Таблица 1 – Отчет о верификации модели

Arrow Name	Attribute Name	Entity Name
Информация о водителях	Familia	Voditeli
	Imia	Voditeli
	Pasportnie_dannie	Voditeli
	Telefon	Voditeli
Информация о проданных  билетах	Data_otpravlenia	Prodaga
	Do_stancii	Prodaga
	Kol_biletov	Prodaga
	Mesto_nomer	Prodaga
	Nomer_avtobusa	Prodaga
	Nomer_prodagi	Prodaga
	Nomer_reisa	Prodaga
	Pasportnie_dannie	Prodaga
	Platforma	Prodaga
	Rastoanie	Prodaga
	Stancia_otpravlenia	Prodaga
	Tekes\Pred_pokupka	Prodaga
	Vrimia_otpravlenia	Prodaga
Информация о рейсах	Dni_nedeli	Reisi
	Konechni_punct	Reisi
	Nachaln_punct	Reisi
	Nomer_reisa	Reisi
	Rastoyanie	Reisi
	Stoimost	Reisi
	Vrimia_otpravlenia	Reisi
Обнавленные данные о  рейсах	Dni_nedeli	Reisi
	Konechni_punct	Reisi
	Nachaln_punct	Reisi
	Nomer_reisa	Reisi
	Rastoyanie	Reisi
	Stoimost	Reisi
	Vrimia_otpravlenia	Reisi
Отчет о стоимости  билетов	Data_otpravlenia	Prodaga
	Do_stancii	Prodaga
	Kol_biletov	Prodaga
	Mesto_nomer	Prodaga
	Nomer_avtobusa	Prodaga
	Nomer_reisa	Prodaga
	Platforma	Prodaga
	Rastoanie	Prodaga
	Stancia_otpravlenia	Prodaga
	Tekes\Pred_pokupka	Prodaga
	Vrimia_otpravlenia	Prodaga
Отчет по продажам	Data_otpravlenia	Prodaga
	Do_stancii	Prodaga
	Kol_biletov	Prodaga
	Mesto_nomer	Prodaga
	Nomer_avtobusa	Prodaga
	Nomer_reisa	Prodaga
	Pasportnie_dannie	Prodaga
	Platforma	Prodaga
	Rastoanie	Prodaga
	Stancia_otpravlenia	Prodaga
	Tekes\Pred_pokupka	Prodaga
	Vrimia_otpravlenia	Prodaga