Разработка программного продукта для автоматизации учета оплаты договоров за обучение (стр. 6 из 10)
; 
; 
Найдем значения других характеристик системы:
-интенсивность обращения рабочих станций к серверу (по формуле 1):
.-среднее число заявок в системе в единицу времени (по формуле 7):
;-коэффициент «простоя» сервера (по формуле 8):
-среднее время между обращениями рабочих станций к серверу (по формуле 9):
-время ожидания рабочей станцией данных от сервера (по формуле 10):
.Таким образом, по полученным значениям характеристик системы можно сделать вывод, что при заданных значениях l0 и m наиболее вероятным будет состояние, при котором сервер обслуживает одну станцию, а две другие работают локально. Среднее время ожидания рабочими станциями данных 3,33 секунды, т.е. рабочие станции ждут относительно недолго. Все это говорит о том, что сервер справляется с нагрузкой.
3.1 Описание информационной модели
Логическая модель базы данных:
Информационная модель объекта автоматизации включает следующие объекты:
-факультеты;
-группы;
-студенты;
-лицевые счета студентов;
-выписки банка;
-архивы.
Данные объекты можно представить в виде таблиц, связанных между собой и образующих реляционную базу данных.
В спроектированной БД используются следующие таблицы:
-справочник факультетов;
-справочник групп;
-справочник студентов;
-книга лицевых счетов;
-книга выписок банка;
-книга оплат;
-файл параметров.
С учетом требований эффективности программной реализации необходимо учитывать, что, несмотря на схожесть структуры текущих таблиц и архивов, размещать все данные о студентах, их лицевых счетах, о выписках и оплатах и архивы в одних таблицах нецелесообразно, так как со временем разросшиеся данные существенно замедлят скорость работы с таблицами. Поэтому кроме текущих таблиц, которые хранят часто используемые данные, необходимо использовать архивные таблицы, где будет содержаться устаревшая и редко используемая информация. Такими таблицами в БД являются:
-архив справочника студентов;
-архив книги лицевых счетов;
-архив книги выписок банка;
-архив книги оплат.
При проведении архивации (закрытие периода) в архив из текущих таблиц удаляются:
-студенты, для которых дата окончания учебы относится к архивируемому периоду и сальдо которых имеет нулевое значение;
-лицевые счета, относящиеся к указанным студентам;
-выписки банка, дата которых меньше даты архивации;
-все оплаты, относящиеся к удаляемым выпискам.
Так как в удаляемых выписках банка могут быть оплаты студентов, которые еще находятся в текущих таблицах, то для того, чтобы не обращаться постоянно к архивам, необходимо сохранять для каждого студента в дополнительном поле сумму оплат, которые содержатся в архиве.
Физическая модель базы данных:
Для реализации физической модели БД использовано СУБД была выбрана СУБД InterBase.
Таблица 1. Структура таблиц БД
| Поле | Тип | Описание | Ограничения |
| 1 | 2 | 3 | 4 |
| Справочник факультетов S_Facul | |||
| KodFacul | VarChar(5) | Краткое наименование факультета (PrimaryKey) | 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).