Разработка информационной системы учета оплаты за обучение

 

 

2.4 Построение математической  модели

 

Разработанный программный  продукт предназначен для использования  его в архитектуре клиент / сервер. Предполагается, что сеть будет включать сервер и 3 клиентских компьютера. Рассмотрим следующую схему обработки сервером запросов от клиентских компьютеров.

 

 

80

 

Рисунок 3

 

От рабочих станций  к серверу поступают запросы. Сервер должен обслуживать запросы, приходящие от клиентов. При чем в каждый момент времени сервер может выполнять запрос только от одной рабочей станции. Если рабочая станция при обращении к серверу застает его в этот момент свободным, то ее заявка обслуживается немедленно. В противном случае, она становится в очередь и ждет пока сервер не освободится и не выполнит ее запрос.

 

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

 

работа в локальном  режиме;

 

обмен информацией с сервером, который включает:

 

обращение к серверу;

 

получение информации от сервера;

 

ожидание;

 

ожидание в очереди.

 

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

 

ожидание запросов;

 

обмен информацией с одной  из рабочих станций, включающий:

 

прием информации от клиента;

 

обработка информации для  клиента;

 

передача информации клиенту.

 

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

 

Система состоит из одного канала обслуживания (сервер) и трех источников заявок (рабочие станции). Сервер может одновременно обслуживать  только одну заявку (запрос рабочей  станции). На вход системы из ограниченного  источника поступает поток заявок, поэтому в системе может находиться не более 3 заявок. Заявки, которые поступили  в систему и застали канал  обслуживания свободным, сразу же идут на обслуживание. Если же при поступлении  заявки канал обслуживания занят, то заявка становится в очередь и  ждет до тех пор, пока канал не освободится.

 

80

 

Время появления заявок в  системе, т.е. время обращения рабочих  станций к серверу, является случайной  величиной. Примем, что поток поступающих  заявок является пуассоновским. Интенсивность  потока требований каждой рабочей станции  равна 0, а интервал времени между  обращениями к серверу имеет  показательное распределение с  плотностью:

 

.

 

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

 

.

 

Тогда для нашей системы  имеем:

 

. (1)

 

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

 

,

 

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

 

80

 

Рисунок 5

 

Изобразим процесс перехода компьютерной сети в процессе работы из одного состояния в другое в  виде графа состояний (рис. 5).

 

Возможные состояния системы:

 

все станции работают в  локальном режиме, сервер «простаивает»;

 

одна станция обслуживается  сервером, остальные работают локально;

 

одна станция обслуживается  сервером, одна станция ждет обслуживания в очереди, одна станция работает локально;

 

одна станция обслуживается  сервером, две другие станции ждут обслуживания в очереди.

 

Напишем линейные алгебраические уравнения для финальных вероятностей состояний данной системы (их существование  вытекает из того, что из каждого  состояния можно перейти в  каждое другое, и число состояний  конечно) [8]. Для состояния 0 имеем:

 

. (2)

 

Для состояния 1:

 

.

 

В силу формулы 2 это равенство  приводится к виду:

 

.

 

Аналогично можно вывести  формулы для остальных состояний. Тогда получим следующую систему  уравнений:

 

Вводя в систему нормировочное  условие

 

P0 + P1 + P2 + P3 = 1,

 

решим эту систему уравнений  и получим выражения для нахождения финальных вероятностей.

 

Величина называется интенсивностью обслуживания. Тогда получим следующие  формулы:

 

, (3)

 

, (4)

 

, (5)

 

. (6)

 

Приведем расчетные формулы  для некоторых других характеристик  системы:

 

среднее число заявок в  системе в единицу времени:

 

; (7)

 

коэффициент «простоя» сервера:

 

; (8)

 

среднее время между обращениями  рабочих станций к серверу:

 

; (9)

 

среднее время пребывания заявки в системе (время ожидания рабочей станцией данных от сервера):

 

. (10)

 

Зададим численные значения интенсивностей 0 и и найдем характеристики системы.

 

Пусть 0 = 0.2 ( = 5 сек.),

 

= 0.5 ( = 2 сек.).

 

Тогда .

 

Вычислим финальные вероятности  системы (по формулам 3-6):

 

,

 

;

 

;

 

Найдем значения других характеристик  системы:

 

интенсивность обращения  рабочих станций к серверу (по формуле 1):

 

.

 

среднее число заявок в  системе в единицу времени (по формуле 7):

 

;

 

коэффициент «простоя» сервера (по формуле 8):

 

среднее время между обращениями  рабочих станций к серверу (по формуле 9):

 

время ожидания рабочей станцией данных от сервера (по формуле 10):

 

.

 

Таким образом, по полученным значениям характеристик системы  можно сделать вывод, что при  заданных значениях 0 и наиболее вероятным  будет состояние, при котором  сервер обслуживает одну станцию, а  две другие работают локально. Среднее  время ожидания рабочими станциями  данных 3,33 секунды, т.е. рабочие станции ждут относительно недолго. Все это говорит о том, что сервер справляется с нагрузкой.

 

3. Специальный раздел

 

 

3.1 Описание информационной  модели

 

 

Логическая модель базы данных:

 

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

 

факультеты;

 

группы;

 

студенты;

 

лицевые счета студентов;

 

выписки банка;

 

архивы.

 

Данные объекты можно  представить в виде таблиц, связанных  между собой и образующих реляционную  базу данных.

 

В спроектированной БД используются следующие таблицы:

 

справочник факультетов;

 

справочник групп;

 

справочник студентов;

 

книга лицевых счетов;

 

книга выписок банка;

 

книга оплат;

 

файл параметров.

 

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

 

архив справочника студентов;

 

архив книги лицевых счетов;

 

архив книги выписок банка;

 

архив книги оплат.

 

При проведении архивации (закрытие периода) в архив из текущих таблиц удаляются:

 

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

 

лицевые счета, относящиеся  к указанным студентам;

 

выписки банка, дата которых  меньше даты архивации;

 

все оплаты, относящиеся  к удаляемым выпискам.

 

Так как в удаляемых  выписках банка могут быть оплаты студентов, которые еще находятся  в текущих таблицах, то для того, чтобы не обращаться постоянно к  архивам, необходимо сохранять для  каждого студента в дополнительном поле сумму оплат, которые содержатся в архиве.

 

Физическая модель базы данных:

 

Для реализации физической модели БД использовано СУБД была выбрана  СУБД InterBase.

 

Таблица 1. Структура таблиц БД

 

Поле 

Тип 

Описание 

Ограничения 

 

1 

2 

3 

4 

 

Справочник факультетов  S_Facul 

 

KodFacul 

VarChar(5) 

Краткое наименование факультета (Primary Key) 

Not Null 

 

NameFacul 

VarChar(60) 

Полное наименование факультета 

Not Null 

 

Справочник групп S_Group 

 

NoGroup 

VarChar(5) 

Номер группы (Primary Key) 

Not Null 

 

KodFacul 

VarChar(5) 

Краткое наименование факультета 

Not Null 

 

Список студентов S_Student 

 

KodStudent 

Integer 

Код студента (Primary Key) 

Not Null 

 

NameStudent 

VarChar(80) 

Ф.И.О. студента 

Not Null 

 

NoGroup 

VarChar(5) 

Номер группы студента  

 

NoDogovor 

VarChar(10) 

Номер заключенного договора  

 

DateDogovor 

Date 

Дата заключения договора  

 

DateEnd 

Date 

Дата окончания учебы 

>DateDogovor 

 

Saldo 

Float 

Сальдо

 

Значение по умолчанию = 0 

Not Null 

 

ArhOplat 

Float 

Сумма оплат, находящихся  в архиве

 

Значение по умолчанию = 0 

Not Null 

 

Книга лицевых счетов Book_Schet 

 

IdSchet 

Integer 

Идентификатор счета (Primary Key) 

Not Null 

 

KodStudent 

Integer 

Код студента 

Not Null 

 

DateOpen 

Date 

Начальная дата периода оплаты 

Not Null

 

DateDogovor 

 

DateClose 

Date 

Конечная дата периода  оплаты 

Not Null

 

>DateOpen

 

DateEnd 

 

Summa 

Float 

Сумма для оплаты 

Not Null

 

>0 

 

Таблица 1(продолжение) 

 

1 

2 

3 

4 

 

Книга выписок банка Book_Vypis 

 

IdVypis 

Integre 

Идентификатор выписки (Primary Key) 

Not Null 

 

NoVypis 

Integre 

Номер выписки банка 

Not Null

 

>0 

 

DateVypis 

Date 

Дата выписки 

Not Null

 

>DateArh 

 

Книга оплат Book_Oplat 

 

IdOplat 

Integer 

Идентификатор оплаты (Primary Key) 

Not Null 

 

IdVypis 

Integer 

Идентификатор выписки 

Not Null 

 

KodStudent 

Integer 

Код студента 

Not Null 

 

SummaOplat 

Float 

Сумма оплаты 

Not Null

 

>0 

 

Primech 

VarChar(100) 

Примечание

 

Значение по умолчанию  = Null  

 

Файл параметров Params 

 

Id 

Integer 

Идентификатор (Primary Key) 

Not Null 

 

ShortName 

VarChar(30) 

Краткое наименование организации 

Not Null 

 

FullName 

VarChar(100) 

Полное наименование организации 

Not Null 

 

Adres 

VarChar(100) 

Адрес организации 

Not Null 

 

Rukovod 

VarChar(80) 

Руководитель 

Not Null 

 

Buhgalter 

VarChar(80) 

Главный бухгалтер 

Not Null 

 

INN 

Char(10) 

ИНН организации 

Not Null 

 

Schet 

Char(20) 

Расчетный счет организации 

Not Null 

 

BankName 

VarChar(80) 

Наименование банка 

Not Null 

 

BankKorSchet 

Char(10) 

Корреспондентский счет банка 

Not Null 

 

BankRasSchet 

Char(20) 

Расчетный счет банка 

Not Null 

 

BankBIK 

Char(20) 

БИК банка 

Not Null 

 

DateArh 

Date 

Дата последней архивации 

Not Null 

 

Архив списка студентов Arh_Student 

 

KodStudent 

Integer 

Код студента (Primary Key) 

Not Null 

 

Таблица 1(продолжение) 

 

1 

2 

3 

4 

 

NameStudent 

VarChar(80) 

Ф.И.О. студента 

Not Null 

 

NoGroup 

VarChar(5) 

Номер группы  

 

NoDogovor 

VarChar(10) 

Номер заключенного договора  

 

DateDogovor 

Date 

Дата заключение договора  

 

DateEnd 

Date 

Дата окончания учебы 

>DateDogovor 

 

Архив книги лицевых счетов Arh_Schet

 

Архив книги выписок банка  Arh_Vypis

 

Архив книги оплат Arh_Oplat 

 

Имеют структуру аналогичную  структуре текущих таблиц. 

 

 

 

Ограничения для столбцов, которые невозможно реализовать  при создании таблиц были реализованы  с помощью триггеров.

 

Формирование первичных  ключей. Генераторы:

 

В InterBase отсутствует аппарат автоинкрементных полей. Вместо этого для установки уникальных значений столбцов используется аппарат генераторов.

 

Генератором называется хранимый на сервере БД механизм, возвращающий уникальные значения, никогда не совпадающие  со значениями, выданными тем же самым генератором в прошлом.

 

В БД созданы генераторы для ключевых полей следующих  таблиц:

 

книга лицевых счетов: Gen_Schet;

 

книга выписок банка: Gen_Vypis;

 

книга оплат: Gen_Oplat.

 

При добавлении записи с  помощью оператора INSERT для присваивания значения ключевому полю необходимо непосредственно обращаться к генератору с помощью функции GEN_ID [3]. Присваивание ключевому полю уникального значения в приложении клиента реализовано  с помощью хранимых процедур Proc_Gen_Book_Schet, Proc_Gen_Book_Vypis, Proc_Gen_Book_Oplat соответственно для таблиц счетов, выписок, оплат.

 

Поддержка ссылочной целостности:

 

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

 

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