На рис. 2.6 приведена информационная модель логического уровня БД.
При формулировке требований в БД было определено: БД должна быть свободно переносимой, хранить данные о клиентах, заказах клиентов, характеристиках билетов и обеспечивать некоторые возможности для динамического формирования документа.
При проектировании БД необходимо обеспечить формирование таблиц в порядке от файлов НИИ к оперативным файлам. При заполнении данными файлов, нужно вводить данные в такой же последовательности, то есть, заполнить данными файлы НИИ, а только потом предоставить возможность пользователям наполнять данными файлы оперативной информации.
Рис. 2.6. Информационная модель логического уровня БД
Так как программа реализует учетные функции, то такой экономико-математической модели решения задачи не существует. Но можно выделить некоторые показатели, которые рассчитываются при формировании реестра заказов.
Сумма заказа клиента - складывается из суммы стоимостей билетов, учитывая их количество.
Формула 2.1.
,
где,
Sum - сумма j-го заказа клиента;
Price - цена i-того билета в j-м заказе;
Count - количество i-того билета в j-м заказе;
n - количество разновидностей билетов.
Сумма заказов за день - складывается из общей суммы всех заказов клиентов на определенную дату.
Формула 2.2.
Sum - сумма заказов за день;
m - количество заказов за день.
2.2.3 Используемые классификаторы и системы кодирования
Анализируя алгоритм решения задачи можно сказать, что он носит учетный характер. Клиент последовательно проходит этап регистрации, добавление билетов в корзину и регистрацию заказа в БД.
Таблица 2.4.
Описание системы кодировки
Наименование признака
Значительность
Система кодировки
Структура кодового обозначения
Код покупателя
5
последовательная
99999
Код билета
6
999999
Код заказа
Код вида оплаты
1
9
Код категории билета
2
99
Код характеристики
Алгоритм решения задачи необходим для формирования реестра подтвержденных заказов клиентов, поэтому в программе реализуются методы поддержки ведения справочника клиента и его заказов.
Для решения задачи требуется наличие всех данных о билетах и их характеристиках. Также от СУБД требуется сохранение всех видов целостности БД при функционировании задачи.
Таблица 2.5.
Словарь данных
№
данных
Название элемента данных
Идентификатор
Тип, длина и
точность
Назначение
1.
№ платежного поручения
Por_id
9999
Для однозначной идентификации поручений
2.
Банк получателя
Por_bnk_pol
Х(50)
Наименование банка получателя
3.
Банк плательщика
Por_bk_plt_naim
Наименование банка плательщика
4.
Вид оплаты
Ps_id
Х
5.
Дата ведомости
vdata
99.X(8).9999
Для разделения остатков| на дату
6.
Дата получения банком
Por_bk_date
7.
Дата оформления поручения
Por_date
8.
Дата прайс-листа
Pr_date
9.
Дата проведения банком
Por_bnk_prov
10.
Дата реестра
Re_date
99.99.9999
11.
Дебет счета №
Por_deb_c
Х(14)
12.
Код банка получателя
Por_bnk_pol_id
Х(6)
Для однозначной идентификации банка
13.
Код банка плательщика
Por_plat_bnk_id
14.
Код клиента
id
Для однозначной идентификации клиента
15.
Код получателя
Por_pol_id
Для однозначной идентификации получателя
16.
Код плательщика
Por_plat_id
Для однозначной идентификации плательщика
17.
pr_id
Для однозначной идентификации
18.
Кредит счета №
Por_cred_c
19.
Наименование категории билета
Cat_naim
X(50)
Для различения
20.
Наименование билета
name
X(150)
Для пользователей билетов
21.
Номер заказа
o_id
Для однозначной идентификации заказа
22.
Получатель
Por_pol_naim
Наименование получателя
23.
ФИО клиента
fio
Х(70)
24.
Плательщик
Por_plat_naim
Наименование латника
25.
Назначение платежа
Por_nazn
Х(80)
26.
Сумма платежа
Por_sum
99999,99
28.
Цена билета
price
Для оценки остатков|
29.
Наименование характеристики билета
Prop_naim
X(80)
30.
Значение характеристики билета
Value_
X(100)
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
