Автоматизация бизнес-процессов продажи билетов ООО "Зритель" (стр. 13 из 17)
Таблица 2.8.
Список исходных документов
| №данных | Название реквизита | Фактический илирассчитанный | Назначение |
| 1. | № платежного поручения | фактический | Для однозначной идентификации поручений |
| 2. | № билета | фактический | Для однозначной идентификации билета |
| 3. | Банк получателя | фактический | Наименование банка получателя |
| 4. | Банк плательщика | фактический | Наименование банка плательщика |
| 6. | Дата получения банком | фактический | Дата получения банком |
| 7. | Дата оформления поручения | рассчитанный | Дата оформления поручения |
| 8. | Дата прайс-листа | рассчитанный | Дата прайс-листа |
| 9. | Дата проведения банком | фактический | Дата проведения банком |
| 10. | Дата реестра | рассчитанный | Дата проведения банком |
| 11. | Дебет счета № | фактический | Дата реестра |
| 12. | Значение характеристики билета | фактический | Значение характеристики билета |
| 13. | Код банка получателя | фактический | Для однозначной идентификации банка |
| 14. | Код банка плательщика | фактический | Для однозначной идентификации банка |
| 15. | Код клиента | фактический | Для однозначной идентификации клиента |
| 16. | Код получателя | фактический | Для однозначной идентификации получателя |
| 17. | Код плательщика | фактический | Для однозначной идентификации плательщика |
| 18. | Кредит счета № | фактический | Кредит счета № |
| 19. | Наименование производителя | фактический | Наименование производителя |
| 20. | Наименование категории билета | фактический | Для различения |
| 21. | Наименование билета | фактический | Наименование билета |
| 22. | Наименование характеристики билета | фактический | Наименование характеристики билета |
| 23. | Номер заказа | фактический | Для однозначной идентификации заказа |
| 24. | Получатель | фактический | Наименование получателя |
| 25. | ФИО клиента | фактический | ФИО клиента |
| 26. | Плательщик | фактический | Наименование латника |
| 27. | Ссылка на сайт производителя | фактический | Ссылка на сайт производителя |
| 28. | Назначение платежа | фактический | Назначение платежа |
| 29. | Сумма заказа | рассчитанный | Сумма заказа |
2.2.6 Формализация расчётов показателей
Таблица 2.9.
Формализация таблиц БД и расчет приблизительного объема БД
| Таблица | Наименование поля | Идентификатор поля | Тип данных | Размербайт |
| BANNER | Код баннера | B_ID | INTEGER | 4 |
| Файл баннера | BANNER_FILE | VARCHAR(256) | 256 | |
| 260*8=2080 | ||||
| CATEGORY | Код категории | CAT_ID | INTEGER | 4 |
| Наименование категории | CAT_NAIM | VARCHAR(50) | 50 | |
| 54*10=540 | ||||
| CUSTOMER | Код клиента | ID | INTEGER | 4 |
| ФИОклиента | FIO | VARCHAR(70) | 70 | |
| Адрес клиента | ADDRESS | VARCHAR(70) | 70 | |
| Телефон | TEL | VARCHAR(18) | 18 | |
| Дата регистрации | REG_DATE | DATE | 4 | |
| Адрес электронной почты | VARCHAR(50) | 50 | ||
| 216*30=6480 | ||||
| MAN | Код пользователя | ID | INTEGER | 4 |
| Логин | LOGIN | VARCHAR(20) | 20 | |
| Пароль | PASSWORD | VARCHAR(20) | 20 | |
| Признак менеджера | ADM | CHAR(1) | 1 | |
| 45*32=1140 | ||||
| O_ID | Код заказа | ID | INTEGER | 4 |
| Дата заказа | DAT_ORD | DATE | 4 | |
| Адрес заказа | ADDRESS | VARCHAR(70) | 70 | |
| Вид оплаты | PAY_ID | INTEGER | 4 | |
| Дата доставки | DAT_DOS | DATE | 4 | |
| Дата фактическойдоставки | DAT_FACT | DATE | 4 | |
| Признак подтверждённого заказа | APPLIED | CHAR(1) | 1 | |
| 91*100=9100 | ||||
| ORDER_DESC | Код заказа | O_ID | INTEGER | 4 |
| Код билета | PR_ID | INTEGER | 4 | |
| Количество | QNTY | INTEGER | 4 | |
| 12*300=3600 | ||||
| PRODUCER | Код производителя | PRDCR_ID | INTEGER | 4 |
| Наименование производителя | NAME | VARCHAR(50) | 50 | |
| 54*15=810 | ||||
| PRODUCT | Код билета | PR_ID | INTEGER | 4 |
| Код категории | CAT_ID | INTEGER | 4 | |
| Наименованиебилета | NAME | VARCHAR(50) | 50 | |
| Файл малого изображения билета | IMAGE_SRC | VARCHAR(256) | 256 | |
| Цена | PRICE | NUMERIC(6,2) | 4 | |
| Признак новинки | NEW_FLAG | CHAR(1) | 1 | |
| Файл большого изображениябилета | HIGH_IMG_SRC | VARCHAR(256) | 256 | |
| Файл описаниябилета | DESCRIPTION_URL | VARCHAR(256) | 256 | |
| Код производителя | PRDCR_ID | INTEGER | 4 | |
| 835*150=125250 | ||||
| PROD_PROP | Код билета | PR_ID | INTEGER | 4 |
| Код характеристики билета | PROP_ID | INTEGER | 4 | |
| Значениехарактеристики | VALUE_ | VARCHAR(100) | 100 | |
| 108*500=54000 | ||||
| PROPERTY | Код характеристики | PROP_ID | INTEGER | 4 |
| Код категории билета | CAT_ID | INTEGER | 4 | |
| Наименование характеристики | PROP_NAIM | VARCHAR(80) | 80 | |
| 88*150=13200 | ||||
| SITE | Код сайта производителя | SITE_ID | INTEGER | 4 |
| Код производителя | PRDCR_ID | INTEGER | 4 | |
| Ссылка на сайт | SITE_URL | VARCHAR(256) | 256 | |
| 264*15=3840 | ||||
| 220340 байт | ||||
Безусловно, этот расчет является приблизительным. Это объясняется наличием в БД метаданных. Кроме того, размер БД для СУБД Interbase достаточно тяжело определить, потому, что файл БД архивируется после закрытия соединения с СУБД.
2.3 Программное обеспечение задачи
2.3.2 Общие положения (дерево функций и сценарий диалога)
Программа создаётся для автоматизации учетных функций менеджера по продаже. Она реализована с использованием HTML-конструкций и серверного скрипт-языка PHP.
Из-за того, что конечными пользователями системы являются клиенты магазина и менеджер по продаже, созданы два соответствующих режима работы системы: для клиентов и для менеджера.
Для обеспечения защиты данных можно дополнительно использовать систему защиты канала передачи данных с помощью SSL. Кроме того также можно использовать дополнительные крипто-модули для защиты регистрационной информации клиентов магазина.
Программа реализована как совокупность HTML-страниц с PHP-вставками, с помощью которых и осуществляется доступ в БД и робота с ней.
Задача реализована как последовательность страниц, которые загружает клиент. Задача решается поэтапными процессами (регистрации клиента, заказа билетов, подтверждения заказа). Кроме того для менеджера по продаже формируется реестр подтвержденных заказов тоже через этап идентификации менеджера и процесс формирования самого реестра. Последний использует расчетные формулы (2.1., 2.2.). Алгоритм решения задачи приведен на рис. 2.7.
Рис. 2.7. Алгоритм решения задачи
2.3.3 Характеристика базы данных
Для физической реализации БД была избрана СУБД Interbase, потому что сейчас она получила широкое распространение. Кроме того, она имеет достаточную производительностью для транзакционных задач. Сейчас на рынке появилась бесплатная СУБД Firebird, которая также может использовать для проектирования БД, потому что перечисленные СУБД совместим между собой. СУБД Interbase автоматически поддерживает репозитарий БД. Еще преимуществом последней СУБД является то, что существуют дистрибутивы как для MS Windows, так и для Unix-подобных систем. СУБД с БД размещается на центральном сервере организации. Из-за этого, в БД имеет доступ практически каждый пользователь, при условии наличия у него достаточных полномочий.
При рассмотрении предметной области были определены сущности проекта: заказ, клиент, корзина, каталог, категория билета.
Для определения структуры БД необходимо построить родовидовые списки реквизитов входных и исходных документов.
На рис. 2.8. изображена физическая модель БД.
2.3.4 Структурная схема пакета (дерево вызова программных модулей)
После анализа словаря данных была определена структура внутримашинной ИБ, которую составляют файлы НИИ и оперативные файлы. К файлам НИИ можно отнести файлы «категории билетов» (CATEGORY), «билеты» (PRODUCTS), «клиенты» (CUSTOMER), «сайты производителя» (SITE), «производитель» (PRODUCER), «характеристики билета» (PROPERTY), «пользователь системы» (MAN). К файлам оперативной информации относим соответственно файлы «заказа клиентов» (ORDERS), «билеты в заказах» (ORDER_DESC), «характеристика-значение» (PROD_PROP). Для каждого из файлов НИИ разработаны триггеры для обеспечения автоматического генерирования уникальных ключей таблицы.
Рис. 2.8. Физическая модель БД, используемая при автоматизации проекта
2.3.5 Описание программных модулей
Техническое описание программных модулей проекта приведено в Приложении 1.
Техническая сложность проекта (TCF - Technical Complexity Factor) вычисляется с учетом показателей технической сложности. Все показатели приведены в табл. 2.10.