3.5. Практическая реализация базы данных и базы знаний
Хранимая память — основная единица данных в физических структурах. Хранимая запись представляет собой совокупность связанных элементов данных (атрибутов), которая соответствует одной или нескольким логическим записям; она содержит все необходимые указатели, длину записи и некоторые дополнительные данные.
Файл (таблица) представляет собой множество аналогично построенных хранимых записей одного типа.
Физическая БД — совокупность совместно хранимых взаимосвязанных данных, состоящих из одного или нескольких типов хранимых записей.Физическая БД, построенная в Delphi, состоит из файлов данных, областей таблиц сегментов отката, таблиц, столбцов и индексов. Между этими элементами имеются зависимости, которые определяют порядок к каждому большому элементу хранения. Общие аспекты внешней памяти и производительности учитываются при разработке и должны рассматриваться на каждом шаге. Как и в случае с логическим моделированием, разработка физической модели может представлять собой в некоторый степени итерационный процесс. Физическая модель БД определяет используемые запоминающие устройства, способы физической организации данных в среде хранения. Эта модель также строится с учетом возможностей, предоставляемых средой программирования.
В рассматриваемом случае была выбрана среда программирования Borland Delphi, формат Paradox. Здесь свои типы полей и размерности типов. Связи реализуются с помощью компонент Data Source и Query со страницы «Data Access».
При присваивании имен таблицам БД и полям таблиц использован латинский шрифт. В результате было получено 11 таблиц: Users, To Debet, Calculation, Saldo, Podraz, Sv_Service, Dolg, Operators, Debetors, User List, AbUser List.
Для определения местоположения таблиц БД и БЗ необходимо соответствующим образом настроить драйвер. При этом удобно использовать BDE Administrator. Настраивается драйвер Paradox, его языковой драйвер, устанавливая соответствующие значения.
В качестве языкового драйвера выбран «ascii» ANSI.
Драйвер языка определяет порядок сортировки значений в таблицах и использование конкретного набора символов. В итоге образуется полная физическая модель БД, представленная в файлах формата Paradox, и полностью настроенная для эффективной работы из среды Delphi.Следующий обязательный этап в проектировании БД — этап, связанный с назначением атрибутов столбцам таблиц. Атрибут столбца определяет, как он будет физически сохранен в БД, выбирая тип данных и максимальную длину. Тип данных и длина столбца должны быть тщательно подобраны во время разработки, так как иногда трудно изменять эти атрибуты после того, как данные уже загружены.
Рассмотрим назначение каждого из типа данных Delphi:
A (Alpha) — строка с фиксированным набором символов от 1 до 255;
N (Number) — положительные или отрицательные вещественные числа из диапазона
307 308
от -10 до 10 с точностью до 15 знаков с плавающей точкой;
D (Date) — значения даты (дата от 1 января 1900 года до 31 декабря 9999 года);
$ (Money) — денежный формат поля, который похож на формат N (Number), но при выводе данных ограничивает число десятичных знаков и отображает символ валюты;
S (Shot) — положительное целое число.
Размер полей в СУБД Paradox 7.0 задается только для символьных полей, иные поля подразумевают размер, определяемый типом поля. Атрибуты соответствующих объектов формируют поля таблицы БД и БЗ необходимых типов. Определим типы полей и их размеры исходя из предметной области и возможных полей СУБД Paradox, после чего производится выбор ключевых полей. Идентификаторы и структуру таблиц и полей иллюстрируют данные табл. 3.13-3.23.
Заметим, что для гарантированного выполнения системой БД и БЗ в составе ЭС требований пользователей и ее нормального функционирования необходимы серьезные тестовые процедуры. При разработке новых приложений время, затрачиваемое на тес-тирование, уступает только времени, затраченному на само программирование. Поэтому проблема тестирования как элементов ЭС, так и системы в целом представляет само-стоятельное значение и должна рассматриваться отдельно.
Таблица 3.13.
Задание полей таблицы «Пользователи» (Users) Название поля Имя поля Тип данных Размер поля Ключ Идентификатор пользователя UsersID N + Идентификатор отделения банка BankDeptID N Идентификатор отделения, которому платит данный пользователь за услуги связи DEFTID N Идентификатор типа пользователя UserTypelD N Идентификатор улицы StreetID N + Идентификатор пункта приема оплаты POSID N + Номер лицевого счета Account SТаблица 3.13 (окончание) Название поля Имя поля Тип данных Размер поля Ключ Наименование пользователя Name A 50 ИНН INN S Дата открытия лицевого счета DateBegin D Дата закрытия лицевого счета Date End D Почтовый индекс Postlndex S Дом Home S Корпус Corpus s Квартира Flat s Предприятие (физическое или юридическое лицо) isCorp s Дата заключения договора ContractDate D Номер договора на предоставление услуг связи ContractNmb s Расчетный счет банка BankAccount s Код предприятия по общероссийскому классификатору предприятий и организаций (ОКПО) OKPO s Телефон юридического местоположения JPhone s Телефон физического местоположения FPhone s
Таблица 3.14. Задание полей таблицы «Отбор дебиторов» (To_Debet) Название поля Имя поля Тип данных Размер поля Ключ Идентификатор выполненной процедуры отбора дебиторов DbtLgndID N + Идентификатор отделения, которому платит данный пользователь за услуги связи DEPTJD N + Идентификатор списка пользователей User ListJD N + Идентификатор периода расчета, на основании которого отыскиваются дебиторы CalcID N + Идентификатор оператора, выполнявшего поиск OperJD N + Предприятие (юридическое или физическое лицо) isCorp S Величина долга для населения Limit N
Таблица 3.14 (окончание) Название поля Имя поля Тип данных Размер поля Ключ Абсолютная величина или процент к начислениям isPercent $ Количество месяцев долга для населения nDolg N Дата проведения процедуры поиска xDate D Дата печати предупреждений PnntDate D Ключ завершения поиска дебиторов SucceessKey S Посылать на отключение дебитора sendotkl N Отключить телефон getotkl N Список дебиторов на отключение Otkllist N Посылать на снятие (удаление) телефона sendremove N Снять (удалить) телефон getremove N Список телефонов на снятие removelist N Обзвон дебиторов ObzvonD N Предварительное снятие телефона дебитора DpreRemove N Список снятых телефонов DspRemove N
Таблица 3.15.
Задание полей таблицы «Расчеты» (Calculation) Название поля Имя поля Тип данных Размер поля Ключ Идентификатор расчетного периода Calc ID N + Дата закрытия месяца CalcDate D Наименование периода расчета PenodName A 50 Месяц закрытия CalcMonth D Год Calc Year D Ключ завершения расчета SucceessKey SТаблица 3.16. Задание полей таблицы «Сальдо» (Saldo) Название поля Имя поля Тип данных Размер поля Ключ Идентификатор пользователя User_ID N + Идентификатор периода расчета CalcID N + Сальдо Saldo N В том числе налог Tax N Количество месяцев долга nDolg S Таблица 3.17. Задание полей таблицы «Подразделения» (Podraz) Название поля Имя поля Тип данных Размер поля Ключ Идентификатор отделения, которому платит данный пользователь за услуги связи DEFT ID 5 + Идентификатор улица Street ID 5 + Идентификатор пункта приема оплаты POSJD 5 + Код подразделения оператора связи Code 5 Наименование подразделения оператора связи Name A 60 Расчетный счет в банке BankAccount S Дом Home S Код предприятия по общероссийскому классификатору предприятий и организаций (ОКПО) OKPO S Телефон юридического местоположения J Phone S Телефон физического местоположения F_Phone S Телефон для справок Ref Phone S ИНН INN S Номер АТС ATS_Number N
Таблица 3.18. Задание полей таблицы «Услуга» (Sv_Service) Название поля Имя поля Тип данных Размер ноля Ключ Идентификатор услуги Service ID 5 + Идентификатор дебитора Dbt ID 5 + Состояние услуги Status 5 Дата начала действия установки DateBegin D
Таблица 3.19. Задание полей таблицы «Долг» (Dolg) Название поля Имя поля Тнп данных Размер поля Ключ Идентификатор дебитора Dbt ID 5 + Идентификатор отделения, которому платит данный пользователь за услуги связи DEFT ID 5 + Идентификатор периода расчета Calc ID 5 + Идентификатор пользователя Users ID 5 + Величина задолженности пользователя Debet N Количество месяцев долга nDolg S 6 - 10492
Таблица 3.20. Задание полей таблицы «Операторы» (Operators) Название поля Имя поля Тип данных Размер поля Ключ Идентификатор оператора OperlD + Наименование подразделения оператора связи Name A 20 Ввод имени оператора Login Name A 10 Номер оператора OperNmb S
Таблица 3.21.
Задание полей таблицы «Дебиторы» (Debetors) Название поля Имя поля Тнп данных Размер поля Ключ Идентификатор дебитора DbtID + Идентификатор пользователя UsersID + Идентификатор подразделения оператора связи, чьи услуги будут отключены DEPTID + Тип услуг, об отключении которых предупреждается дебитор SvcType A 10 Количество высланных предупреждений об отключении OtklCounter S Дата посылки предупреждения об отключении OtklWDate D Дата подтверждения получения предупреждения об отключении GetOtklWDate D Дата включения в список на отключение OtklListDate D Количество высланных предупреждений о снятии RemCounter S Дата посылки предупреждения о снятии RemWDate D Дата подтверждения получения предупреждения о снятии GetRemWD D Дата включения в список на снятие RemListDate D Дата погашения задолженности PayDate D Текущая задолженность Debet N Текущий долг nDolg N Предприятие isCorp S Тип пользователя UserType_ID SТаблица 3.22. Задание полей таблицы «Список абонентов» (UserJJst) Название поля Имя поля Тип данных Размер поля Ключ Идентификатор пользователя UsersID + Идентификатор списка абонентов UserListID 5і + Таблица 3.23. Задание полей таблицы «Описание абонентов» (AbllserJJst) Название поля Имя поля Тип данных Размер поля Ключ Идентификатор списка абонентов User List ID + Идентификатор оператора OperJD 5і + Наименование списка абонентов Name А 50 Предприятие isCorp S Описание списка абонентов Info А 250 Дата составления списка абонентов ListJDate D Наименование списка абонентов Name А 50
Тестирование разработанной системы БД в составе ЭС имело ввиду проверку следующих критериев:
загрузка БД выполнена без нарушения целостности данных;
приложения правильно взаимодействуют с БД;
рабочие характеристики системы удовлетворяют потребностям, ради выполнения которых приобреталась СУБД.
Процесс тестирования проводился на каждом этапе в течение всего времени разработки БД. Тестирование написанного программного обеспечения выполнялось на ЭВМ Pentium 4 CPU 1,80 GHz.
Во время тестирования были устранены ошибки программного кода и доступа к БД. Также была проведена работа по возможной оптимизации кода и общего функционирования системы, уменьшению избыточности и повышению функциональности системы. Большое внимание в рамках тестирования было уделено совершенствованию пользовательского интерфейса в направлении его упрощения и наглядности. Тестирование функциональности показало, что основные части ЭС вполне работоспособны, что дает право говорить об успешности проведенных процессов тестирования и отладки.Основные формы интерфейса программного комплекса рассматриваемой ЭС пред-ставлены в приложении 2.
Оценка ресурсов, необходимых для разработки и внедрения, а также показателей экономической эффективности ЭС, показывает, что такая система способна во многом оптимизировать процессы по работе с дебиторами в компании связи. Это приносит конкретный экономический результат, поскольку применение ЭС способствует повышению эффективности принимаемых управленческих решений. Разработанный прототип ЭС позволяет своевременно и систематически отслеживать появляющихся дебиторов и принимать меры для устранения дебиторской задолженности: ЭС обеспечивает нахождение в БД абонентов-должников по заданным признакам, выбирая из полученного списка дебиторов, соответствующих заданным однотипным критериям.
В зависимости от величины долга и количества периодов задолженности составляется выходная информация: сводные ведомости на снятие телефонов, на временное отключение, автодозвон. Дальнейшее развитие ЭС является альтернативой существующим информационным системам, используемым при управлении компаниями электросвязи.
При развитии ЭС целесообразно сформировать базу правил, на основе которой будет функционировать БЗ (табл. 3.24). Исходя из разработанного прототипа вполне возможна реализация коммерческой ЭС по работе с дебиторской задолженностью. В настоящее время это является весьма актуальной задачей для отрасли. Отечественные компании электросвязи обладают всеми необходимыми ресурсами и предпосылками для эффективного совершенствования методов и средств управления своей деятельностью в свете последних достижений науки, с помощью новейших информационных и телекоммуникационных технологий.
Таблица 3.24. Структура базы правил экспертной системы Правило Условие Результат Сравнение сальдо на конец месяца и критической величины Если сальдо на конец месяца больше критической величины Абонент включается в список дебиторов Если сальдо на конец месяца меньше критической величины Абонент выбывает из списка дебиторов Выслано количество предупреждений о временном отключении телефона Если предупреждения высланы, а абонент не погашает сумму задолженности Оформляется повторное предупреждение, после чего дебитор включается в список на временное отключение Если абонент выполняет оплату услуг Абонент выбывает из списка дебиторов Период задолженности не должен превышать один месяц Если период задолженности не превышает один месяц Абонент включается в список дебиторов Если период задолженности превышает один месяц Абонент выбывает из списка дебиторов Автодозвон Если осуществлен автодозвон, но дебитор не оплачивает дебиторскую задолженность Дебитору высылается предупреждение о временном отключении телефона и формируется предварительный список на отключение Выслано количество предупреждений о снятии телефона Если количество предупреждений выслано, а абонент не погашает сумму задолженности Оформляется повторное предупреждение, после чего дебитор включается в список на временное отключение Если дебитор не реагирует на пре-дупреждения Дебитору высылается извещение об отключении телефона за неуплату