Автор: Пользователь скрыл имя, 17 Февраля 2013 в 11:47, курсовая работа
Автоматизована система розрахунків NETUP UTM 5.0 [1] призначена для здійснення комплексного обслуговування абонентів підприємств зв'язку. За допомогою системи UTM 5.0 здійснюються всі основні кроки взаємин з клієнтами: укладення договорів, здійснення технічної підтримки, підрахунок що надаються клієнтові послуг, виставляння рахунків, виписування рахунків-фактур, актів выполенных робіт, різних звітів і багато що інше.
Таблиця 3 – Структура таблиці Local
Поле |
Тип |
Розмір, байт |
Пояснення |
KindcallID |
text |
– |
тип дзвінка |
TariffmodelID |
text |
– |
тарифна модель |
TrunkID |
text |
– |
транк |
Numbermask |
text |
– |
шаблон для видалення транка з номера |
Keycode |
text |
– |
ключ шифрування |
DialzoneID |
text |
– |
географічна зона дзвінка |
TimezoneID |
text |
– |
часова зона дзвінка |
Currency |
text |
– |
валюта тарифікації |
TransferID |
text |
– |
трасфер (пересилання дзвінка на іншого абонента) |
Наступні таблиці
Таблиця 4 – Структура таблиці Line
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDLine |
text |
15 |
лінія (номер зовнішньої лінії) |
Name |
text |
50 |
назва лінії |
TariffmodelID |
text |
15 |
тарифна модель |
Далі, з таблиці DialDelay визначається Затримка набору і Трансфер за ключом IDLine + IDTransfer (таблиця 5).
Таблиця 5 – Структура таблиці DialDelay
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDLine |
text |
15 |
лінія (номер зовнішньої лінії) |
IDTransfer |
text |
255 |
поле для визначення трасфера (пересилання дзвінка) |
Dialdelay |
text |
50 |
затримка часу при наборі номера |
TransferID |
text |
15 |
трасфер (пересилання дзвінка на іншого абонента) |
Потім з таблиці Kindcall визначається Тип дзвінка за ключом IDNumber (таблиця 6).
Таблиця 6 – Структура таблиці Kindcall
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDNumber |
text |
255 |
номер, набраний абонентом |
KindcallID |
text |
15 |
тип дзвінка |
Наступним кроком з таблиці Trunk визначається Транк і Шаблон для видалення транка з номера за ключом IDKindcall + IDNumber (таблиця 7).
Таблиця 7 – Структура таблиці Trunk
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDKindcall |
text |
15 |
тип дзвінка |
IDNumber |
text |
15 |
номер, набраний абонентом |
TrunkID |
text |
15 |
транк |
NumberMask |
text |
15 |
шаблон для видалення транка з номера |
Далі, з таблиці Dialtown визначається Місто і Ключ шифрування за ключом IDTrunk + IDNumber (таблиця 8).
Таблиця 8 – Структура таблиці Dialtown
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDTrunk |
text |
15 |
транк |
IDNumber |
text |
15 |
номер, набраний абонентом |
Name |
text |
100 |
назва міста, куди був дзвінок |
Keycode |
text |
3 |
ключ шифрування |
Потім, з таблиці Dialdirection визначається Напрямок, Географічна зона і Ключ шифрування за ключом IDTrunk + IDNumber (таблиця 9).
Таблиця 9 – Структура таблиці Dialdirection
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDTrunk |
text |
15 |
транк |
IDNumber |
text |
15 |
номер, набраний абонентом |
Name |
text |
100 |
назва напрямка, куди був дзвінок |
DialzoneID |
text |
30 |
географічна зона дзвінка |
Keycode |
text |
3 |
ключ шифрування |
Наступним кроком з таблиці Dialzone визначається Назва географічної зони за ключом IDDialzone (таблиця 10).
Далі, з таблиці Timezone визначається Часова зона і її назва за ключом IDTimeBeg + IDTimeEnd (таблиця 11).
Потім, з таблиці Tariff визначаються Тариф, Валюта і Часові параметри за ключом IDDialzone + IDTariffmodel + IDTimezone (таблиця 12).
Таблиця 10 – Структура таблиці Dialzone
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDDialzone |
text |
15 |
географічна зона дзвінка |
Name |
text |
50 |
назва географічної зони дзвінка |
Таблиця 11 – Структура таблиці Timezone
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDTimeBeg |
text |
11 |
шаблон часу початку зони |
IDTimeEnd |
text |
11 |
шаблон часу закінчення зони |
TimezoneID |
text |
15 |
часова зона дзвінка |
Name |
text |
50 |
назва часової зони дзвінка |
Таблиця 12 – Структура таблиці Tariff
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDDialzone |
text |
15 |
географічна зона дзвінка |
IDTariffmodel |
text |
15 |
тарифна модель |
IDTimezone |
text |
15 |
часова зона дзвінка |
Timeminimum |
text |
15 |
часовий мінімум тарифікації |
Timefree |
text |
15 |
максимальний безтарифний час |
Timeround |
text |
15 |
округлення часу |
Timegrid |
text |
15 |
часова сітка |
Timeunit |
text |
15 |
одиниця часу |
Tariff |
text |
15 |
тариф за одиницю часу |
Currency |
text |
15 |
валюта тарифікації |
Name |
text |
50 |
коментар |
На завершення, з таблиці Course визначається Курс валюти за ключом IDCurrency1 + IDCurrency2 (таблиця 13).
Таблиця 13 – Структура таблиці Course
Поле |
Тип |
Розмір, байт |
Пояснення |
Pass |
text |
15 |
номер виборки (проходу) при багатопрохідній виборці |
IDCurrency1 |
text |
15 |
вхідна валюта |
IDCurrency2 |
text |
15 |
вихідна валюта |
Course |
text |
15 |
курс |
Структурна схема тарифікатора
внаслідок своєї
Якщо розглянути зв'язки між
полями таблиць, то видно, що,
окрім трьох спеціальних
3.2 Розробка структури БД білінга
Структура бази даних програми білінга значно простіша і більше нагадує стандартні структури інформаційно-пошукових систем [9]. Таблиця Tariff – це місце, куди програма тарифікації через механізм ODBC32 записує протарифіковані рядки даних про телефонні дзвінки (рис. 3.1). Тому ця таблиця не має ключа і використовується програмою білінга для виборки інформації про телефонні дзвінки по різних полях. Структура наведена в табл. 14.
Рисунок 3.1 – Структурна схема БД тарифікатора
Таблиця 14 – Структура таблиці Tariff
Поле |
Тип |
Розмір, байт |
Пояснення |
DateTime |
text |
13 |
дата і час в форматі yymmddwhhmmss |
Date |
text |
8 |
дата |
Time |
text |
8 |
час |
Number |
text |
50 |
номер, набраний абонентом |
ContinEndTime |
text |
8 |
тривалість/час завершення дзвінка |
Line |
text |
2 |
лінія (номер зовнішньої лінії) |
Abonent |
text |
3 |
абонент (номер внутрішньої лінії) |
DialTown |
text |
50 |
місто, куди був дзвінок |
DialDirection |
text |
50 |
напрямок, куди був дзвінок |
DialZone |
text |
50 |
географічна зона дзвінка |
TimeZone |
text |
50 |
часова зона дзвінка |
Duration |
float |
8 |
тривалість дзвінка |
TimeUnit |
text |
3 |
одиниця часу |
Tarif |
float |
8 |
тариф за одиницю часу |
Currency |
text |
3 |
валюта тарифікації |
Toil |
float |
8 |
сума |
В програмі білінга введено об'єкт Покій (кімната, номер в готелі), який однозначно визначає і визначається полем Абонент. Для цього об'єкта створено таблицю Room з ключом ID. Кожній кімнаті відповідає певний Абонент, а також фіксується час його прибуття і вибуття, що потрібно для подальшого аналізу. Структура наведена в таблиці 15.