Заключение по главе
Среди обширного количества существующих СУБД была выбрана Firebird 2.1. так как одним из ее преимуществом является поддержка множество способов доступа, включая: собственные наборы компонент для
C/C++ и Delphi. Так же Firebird поддерживает большие базы данных, которые могут быть расположены в нескольких файлах. В качестве еще одного преимущества Firebird можно отметить многоверсионную архитектуру, обеспечивающую параллельную обработку оперативных и аналитических запросов (это возможно потому, что читающие пользователи не блокируют пишущих), компактность (дистрибутив 5Mb), высокую эффективность и мощную языковую поддержку для хранимых процедур и триггеров.
В качестве среды разработки базы данных была выбрана оболочка IBExpert 2009 так как она обладает рядом достоинств, таких как:
Ш поддержка InterBase версий 4.х, 5.х, 6.х, 7.х; Firebird 1.х, 2.x; Yaffil 1.х;
Ш работа одновременно с несколькими базами данных;
Ш отдельные редакторы для всех объектов БД с синтаксической подсветкой;
Ш мощный SQL редактор с историей запросов и возможностью фонового выполнения запросов;
Ш отладчик хранимых процедур и триггеров;
Ш поиск в метаданных;
Ш полное и частичное извлечение данных и метаданных;
Ш анализатор зависимостей объектов баз данных;
Ш отчеты по метаданным;
Ш менеджеры пользователей и пользовательских привилегий;
Ш экспорт данных в различные форматы.
IBExpert обладает множеством облегчающих работу компонентов: визуальный редактор для всех объектов базы данных, редактор SQL и исполнитель скриптов, отладчик для хранимых процедур и триггеров, построитель области, собственный скриптовый язык, а также дизайнер баз данных и т. д.
В качестве среды разработки ПО использовалась Delphi 2010 так как в она обладает следующими преимуществами:
Ш Быстрота разработки приложения.
Ш Высокая производительность разработанного приложения.
Ш Hизкие требования разработанного приложения к ресурсам компьютера.
Ш Hаращиваемость за счет встраивания новых компонент и инструментов в среду Delphi.
Ш Возможность разработки новых компонент и инструментов собственными средствами Delphi (существующие компоненты и инструменты доступны в исходниках)
Ш Удачная проработка иерархии объектов
Ш Де-факто уже доступно огромное количество визуальных компонентов третьих фирм, часть из которых freeware, часть shareware, часть - коммерческие.
3. Проектирование реляционной базы данных
Данная база данных проектируется на основе ролевой модели.
Управление доступом на основе ролей представляет собой развитие политики избирательного управления доступом, при этом права доступа субъектов системы на объекты группируются с учетом специфики их применения, образуя роли.
Ролевое разграничение доступа позволяет реализовать гибкие, изменяющиеся динамически в процессе функционирования компьютерной системы правила разграничения доступа.
Данный подход применяется в системах защиты СУБД, а отдельные элементы реализуются в сетевых операционных системах. Ролевой подход часто используется в системах, для пользователей которых четко определен круг их должностных полномочий и обязанностей как в данной базе данных.
Несмотря на то, что Роль является совокупностью прав доступа на объекты компьютерной системы, ролевое управление доступом отнюдь не является частным случаем избирательного управления доступом, так как его правила определяют порядок предоставления доступа субъектам компьютерной системы в зависимости от имеющихся (или отсутствующих) у него ролей в каждый момент времени, что является характерным для систем мандатного управления доступом. С другой стороны, правила ролевого разграничения доступа являются более гибкими, чем при мандатном подходе к разграничению.
Так как привилегии не назначаются пользователям непосредственно, и приобретаются ими только через свою роль (или роли), управление индивидуальными правами пользователя по сути сводится к назначению ему ролей. Это упрощает такие операции, как добавление пользователя или смена подразделения пользователем.
3.1 Разработка структуры таблиц
Структура базы данных для АИС "Оператор", представлена на рисунке 4.
База данных состоит из 6 сущностей, таких как:
Ш Abonenti - Данная сущность хранит в себе информацию об абонентах и включает в себя следующие атрибуты: код абонента, фамилия, имя, отчество, дата рождения, паспортные данные, адрес проживания.
Ш Uslugi - данная сущность включает в себя следующие атрибуты: код услуги, описание, примечание, стоимость.
Ш Tarifi - данная сущность включает в себя следующие атрибуты: название тарифа, стоимость входящих вызовов внутри сети, стоимость исходящих вызовов внутри сети, стоимость входящих вызовов с другого оператора, стоимость исходящих вызовов на другой оператор, стоимость входящих с городского телефона, стоимость исходящих на городской телефон стоимость смс и стоимость интернет трафика.
Ш Abonentskie_uslugi - данная сущность включает в себя следующие атрибуты: код услуги, номер договора, дата подключения, дата окончания действия данной услуги.
Ш Licevoi_schet - данная сущность включает в себя следующие атрибуты: id, номер лицевого счета, дата, время, сумма, номер договора
Ш Zakluchenie_dogovora - данная сущность включает в себя следующие атрибуты: код абонента, номер договора, дата заключения, абонентский номер, тариф, номер лицевого счета.
3.2 Нормализация таблиц
Нормализация - это процесс проверки структуры таблиц на наличие аномалии, если они имеются, то таблицы разбиваются на более мелкие таблицы. Структура нормализации представлена на рисунке 5.
Аномалии - это ситуации при работе с базой данных, которые могут привести к неоднозначной трактовке данных или противоречивым данным. Аномалии возникают в таблицах, содержащих избыточные данные
Рис. 5. "Структура нормализации таблиц"
На начальном этапе проектирования базы данных строится первая нормальная форма (1НФ): Таблица находится в 1 НФ, если на пересечении каждой строки и столбца стоит атомарное значение.
Отношение находится во 2НФ тогда и только тогда, когда отношение находится в 1НФ, и нет, не ключевых атрибутов, зависящих от части сложного ключа. Для того, чтобы устранить зависимость атрибутов от части сложного ключа, нужно произвести декомпозицию отношения на несколько отношений. При этом те атрибуты, которые зависят от части сложного ключа, выносятся в отдельное отношение.
Отношение находится в 3НФ тогда и только тогда, когда отношение находится во 2НФ и все не ключевые атрибуты взаимно независимы.
Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.
Таблица находится в НФБК (Нормальная форма Байса-Кода), если детерминанты всех функциональных зависимостей являются потенциальными ключевыми таблицами
Отношение находится в 4НФ, если отношение содержит 2 многозначные зависимости.
Многозначная зависимость - это такая логическая связь между значениями столбцов А и В при которой для значения А мы можем определить множество значений столбца В.
5НФ применяется к таблицам, имеющим несколько многозначных зависимостей, причем атрибуты, входящие в эти зависимости связаны между собой по смыслу, то есть являются зависимыми друг от друга.
Отношения находятся в ДКНФ (Доменно-ключевая нормальная форма) если каждое ограничение целостности, накладываемое на это отношение является логическим следствием определения доменов и ключей.
Проведем нормализацию таблиц базы данных "Оператор".
Для этого выделим для каждой таблицы функциональные зависимости и проверим на нормальные формы как это показано на рисунке 1. Функциональная зависимость (ФЗ) между столбцами означает логическую связь "Многие к одному" между значениями этих столбцов.
Таблица Abonenti:
Функциональные зависимости :
1. Kod_abonenta > (Familiy, name, otchestvo, data_rogdeniy, seriy_pasporta, nomer_pasporta, kem_vidan, kogda_vidan, address)
2. (seriy_pasporta, nomer_pasporta) > (Kod_abonenta ,familiy, name, otchestvo, data_rogdeniy, kem_vidan, kogda_vidan, address)
3. (Familiy, name, otchestvo, data_rogdeniy, address) > (Kod_abonenta, seriy_pasporta, nomer_pasporta, kem_vidan, kogda_vidan)
Проверка на нормальные формы (НФ):
1НФ прошла, 2НФ прошла, НФБК прошла. Многозначных зависимостей нет. Таблица находится в ДКНФ.
Таблица Uslugi
Функциональные зависимости:
1. Kod_uslugi > (Opisanie, primechanie, stoimost)
1НФ прошла, 2НФ прошла, 3НФ прошла. Многозначных зависимостей нет. Таблица находится в ДКНФ.
Таблица Abonentskie_uslugi
Функциональные зависимости:
1. Kod_uslugi > (Nomer_dogovora, data_podklucheniy, data_okonchaniy)
2. Nomer_dogovora > (Data_podklucheniy, data_okonchaniy)
3. (Nomer_dogovora, data_podklucheniy > (Data_okonchaniy)
1НФ прошла, 2НФ прошла, 3НФ прошла. Многозначных зависимостей нет. Таблица находится в ДКНФ.
Таблица Tarifi
Функциональные зависимости:
1. Nazvanie_tarifa > (St_vh_vn_s, st_ish_vn_s, st_vh_dr_op, St_ish_na_dr_op, st_vh_s_gor_tel, st_ish_na_gor_tel,st_sms, internet_trafic)
1НФ прошла, 2НФ прошла, 3НФ прошла. Многозначных зависимостей нет. Таблица находится в ДКНФ.
Таблица Licevoi_schet
Функциональные зависимости:
1. Id > (Nom_licevogo_scheta, data, vremya, summa, nomer_dogovora)
2. Nom_licevogo_scheta > (Id, data, vremya, summa, nomer_dogovora)
3. (Nom_licevogo_scheta, data) > (vremya, summa)
4. Nomer_dogovora > Nom_licevogo_scheta
1НФ прошла, 2НФ прошла, 3НФ прошла. Многозначных зависимостей нет. Таблица находится в ДКНФ.
Таблица Zakluchenie_dogovora
Функциональные зависимости:
1. Kod_abonenta > (Nom_dogovora, data_zaklucheniy, abonents_nom,tariff, nom_licevogo_sheta)
2. Nom_dogovora > (Kod_abonenta, data_zaklucheniy, abonents_nom,tariff, nom_licevogo_sheta)
3. Abonents_nom > Nom_licevogo_sheta
1НФ прошла, 2НФ прошла, 3НФ прошла. Многозначных зависимостей нет. Таблица находится в ДКНФ.
Таким образом, все обнаруженные аномалии обновления устранены. Реляционная модель, состоящая из отношений, находящихся в третьей нормальной форме, является адекватной описанной модели предметной области.
3.3 Проектирование ограничений целостности
Таблица 1. "Abonenti"
|
Имя столбца |
Тип |
Null/not null |
Primary key/unique |
Check |
Foreign key |
Примечания |
|
|
Kod_abonenta |
Integer |
not null |
Primary key |
Код абонента |
|||
|
Familiy |
Varchar (25) |
not null |
Фамилия абонента |
||||
|
Name |
Varchar (15) |
not null |
Имя абонента |
||||
|
Otchestvo |
Varchar (25) |
not null |
Отчество абонента |
||||
|
Data_rogdeniya |
Date |
null |
Дата рождения абонента |
||||
|
Seriya_pasporta |
Integer |
not null |
Серия паспорта |
||||
|
Nomer_pasporta |
Integer |
not null |
Номер паспорта |
||||
|
Kem_vidan |
Varchar (35) |
not null |
Кем выдан |
||||
|
Kogda_vidan |
Date |
not null |
Когда выдан |
||||
|
Adress |
Varchar (85) |
null |
Адрес абонента |
Таблица 2. "Uslugi"
|
Имя столбца |
Тип |
Null/ not null |
Primary key/unique |
Check |
Foreign key |
Примечания |
|
|
Kod_uslugi |
Integer |
not null |
Primary key |
Код услуги |
|||
|
Opisanie |
Varchar(150) |
not null |
Описание услуги, ее название |
||||
|
Primechanie |
Varchar(150) |
null |
Примечания, |
||||
|
Stoimost |
Float |
not null |
Стоимость услуги |
Таблица 3. "Abonentskie_uslugi"
|
Имя столбца |
Тип |
Null/ not null |
Primary key/unique |
Check |
Foreign key |
Примечания |
|
|
Kod_uslugi |
Integer |
not null |
Foreign key |
Код услуги |
|||
|
Nomer_dogovora |
Integer |
not null |
Foreign key |
Номер договора |
|||
|
Data_Podklucheniy |
Date |
not null |
Дата подключения услуги |
||||
|
Data_okonchaniy |
Date |
null |
Дата окончания услуги |
Таблица 4. "Zakluchenie_dogovora"
|
Имя столбца |
Тип |
Null/ not null |
Primary key/unique |
Check |
Foreign key |
Примечания |
|
|
Kod_abonenta |
Integer |
not null |
Foreign key |
Код абонента |
|||
|
Nom_dogovora |
Integer |
not null |
Primary key |
Номер договора |
|||
|
Data_zaklucheniy |
Date |
not null |
Дата заключения договора |
||||
|
Abonents_nom |
Integer |
not null |
Абонентский номер |
||||
|
Tarif |
Varchar (45) |
not null |
Foreign key |
Тарифный план |
|||
|
Nomer_Licevogo scheta |
Integer |
not null |
Foreign key |
Номер лицевого счета абонента |
Таблица 5. "Licevoi_schet"
|
Имя столбца |
Тип |
Null/not null |
Primary key/unique |
Check |
Foreign key |
Примечания |
|
|
Id |
Integer |
not null |
Primary key |
Порядковый номер |
|||
|
Nomer_licevogo_scheta |
Integer |
not null |
Номер лицевого счета |
||||
|
Data |
Date |
not null |
Дата |
||||
|
Vremya |
Time |
not null |
Время |
||||
|
Summa |
Float |
not null |
Сумма |
||||
|
Nomer_dogovora |
Integer |
not null |
Номер договора |
Таблица 6. "Tarifi"
|
Имя столбца |
Тип |
Null/ not null |
Primary key/unique |
Check |
Foreign key |
Примечания |
|
|
Nazvanie_tarifa |
Varchar (45) |
not null |
Primary key |
Название тарифа |
|||
|
St_vh_vn_s |
Float |
not null |
Стоимость входящих вызовов внутри сети |
||||
|
St_ish_vn_s |
Float |
not null |
Стоимость исходящих вызовов внутри сети |
||||
|
St_vh_dr_op |
Float |
not null |
Стоимость входящих вызовов с другого оператора сотовой связи |
||||
|
St_ish_na_dr_op |
Float |
not null |
Стоимость исходящих вызовов на другой оператор сотовой связи |
||||
|
St_vh_s_gor_tel |
Float |
not null |
Стоимость входящих вызовов с городского номера телефона |
||||
|
St_ish_na_gor_tel |
Float |
not null |
Стоимость исходящих вызовов на городской номер телефона |
||||
|
St_sms |
Float |
not null |
Стоимость смс |
||||
|
Internet_trafic |
Float |
not null |
Стоимость интернет трафика за мегабайт |
3.4 Разработка операций выборки данных
Разработка операции выборки данных представлена в таблице 7.
Таблица 7. "Разработка операций выборки данных"
|
№п/п |
Описание действия |
Входные параметры (имя, тип) |
Выходные параметры (имя, тип) |
Алгоритм выполнения |
|
|
1 |
Добавление нового абонента (процедура ADD_NEW_ABONENT) |
KOD_ABONENTA integer FAMILIY varchar(25) NAME varchar(15), OTCHESTVO varchar(25), DATA_ROGDENIYA date, SERIY_PASPORTA integer, NOMER_PASPORTA integer, KEM_VIDAN varchar(35), KOGDA_VIDAN date, ADDRESSvarchar (85) |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Abonenti человек с такими же кодом абонента, если да то выйти с кодом ошибки 0, если нет то добавить новую строку с данными о новом клиенте в таблицу и отправить значения выходных параметров на выход с кодом 1 |
|
|
2 |
Редактирование данных об абоненте (процедура UPDATE_DANNIE_OB_ABONENTE) |
KOD_ABONENTA integer FAMILIY varchar(25) NAME varchar(15), OTCHESTVO varchar(25),DATA_ROGDENIYA date, SERIY_PASPORTAinteger,NOMER_PASPORTA integer,KEM_VIDAN varchar(35), KOGDA_VIDAN date,ADDRESSvarchar(85) |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Abonenti человек с таким же кодом абонента, то изменяем нужные данные и выходим с параметром 1, если нет то выходим с кодом ошибки о. |
|
|
3 |
Удаление абонента (процедура DELETE_ABONENT) |
KOD_ABONENTA integer |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Abonenti человек с таким же номером абонента, если да, то удалить строку с его данными, если нет, то выйти с кодом ошибки 0. |
|
|
4 |
Добавление нового договора (процедура ADD_DOGOVOR) |
KOD_ABONENTA integer, NOM_DOGOVORA integer, DATA_ZAKLUCHENIY date, ABONENTS_NOM bigint, TARIF varchar(45), NOM_LICEVOGO_SCHETA integer |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Zakluchenie_dogovora номер договора, совпадаемый с вводимым, если да, то выйти с кодом ошибки 0, если нет, то добавить новую строку со всеми данными в таблицу и отправить значения выходных параметров на выход с кодом 1 |
|
|
5 |
Удаление договора (процедура DELETE_DOGOVOR ) |
NOM_DOGOVORA integer |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Zakluchenie_dogovora номер договора, совпадаемый с вводимым, если да, тогда удалить строку из таблицы, если нет, то выйти с кодом ошибки 0. |
|
|
6 |
Добавление нового тарифного плана (процедура ADD_NEW_TARIF) |
NAZVANIE_TARIFA varchar(45), ST_VH_VN_S float,ST_ISH_VN_S float,ST_VH_DR_OPfloat,ST_ISH_NA_DR_OP float, ST_VH_S_GOR_TEL float, ST_ISH_NA_GOR_TEL float ST_SMS float, NTERNET_TRAFIC float |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Tarifi тариф с таким же названием, если да, то выйти с кодом ошибки 0, если нет то добавить строку с информацией о тарифе в таблицу и отправить значения выходных параметров на выход с кодом 1 |
|
|
7 |
Изменение данных о тарифе (процедура UPDATE_DANNIE_O_TARIFE) |
NAZVANIE_TARIFA varchar(45), ST_VH_VN_S float,ST_ISH_VN_S float,ST_VH_DR_OPfloat,ST_ISH_NA_DR_OP float, ST_VH_S_GOR_TEL float, ST_ISH_NA_GOR_TEL float ST_SMS float, NTERNET_TRAFIC float |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Tarifi тариф с таким же названием, если да, то изменяем данные и отправить значения выходных параметров на выход с кодом 1, если нет, то выходим с кодом ошибки 0 |
|
|
8 |
Удаление тарифа (процедура DELETE_TARIF) |
NAZVANIE_TARIFA varchar(45) |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Tarifi тариф с таким же названием, если да, тогда удаляем строку из таблицы, иначе выходим с кодом ошибки 0. |
|
|
9 |
Добавление новой услуги (процедура ADD_NEW_USLUGA) |
KOD_USLUGI integer, OPISANIE varchar(150), PRIMECHANIE varchar(150), STOIMOST float,SPOSOB_PODKLUCHENIY varchar(200) |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Uslugi услуга с таким же кодом услуги, если да, то выйти с кодом ошибки 0, если нет, то добавить строку с информацией об услуге в таблицу и отправить значения выходных параметров на выход с кодом 1 |
|
|
10 |
Изменение сведений об услугах (процедура UPDATE_DANNIE_OB_USLUGAH) |
KOD_USLUGI integer, OPISANIE varchar(150), PRIMECHANIE varchar(150), STOIMOST float,SPOSOB_PODKLUCHENIY varchar(200) |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Uslugi услуга с таким же кодом услуги, если да, то изменяем данные и отправить значения выходных параметров на выход с кодом 1, если нет, то выходим с кодом ошибки 0 |
|
|
11 |
Удаление услуги (процедура DELETE_USLUGA) |
KOD_USLUGI integer |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Uslugi ресурс с таким же кодом услуги, если да, то удаляем строку с данными, иначе выходим с кодом ошибки 0 |
|
|
12 |
Добавление лицевого счета (процедура ADD_NEW_LIC_SCHET) |
ID integer, NOM_LICEVOGO_SCHETA integer, DATA date, VREMYA time, SUMMA float, NOMER_DOGOVORA integer |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Licevoi_schet клиент с запрашиваемым id, если да, то выходим с кодом ошибки 0, иначе добавляем данные в таблицу и отправляем значения выходных параметров на выход с кодом 1 |
|
|
13 |
Удаления лицевого счета (процедура DELETE_LIC_SCHET) |
ID integer |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Licevoi_schet клиент с запрашиваемым id, если да, то удалить строку с данными, иначе выйти с кодом ошибки 0 |
|
|
14 |
Изменение вносимой суммы (процедура UPDATE_SUMMA) |
NOM_LICEVOGO_SCHETA integer, SUMMA float, |
Код ошибки - integer: 0- ошибка |
Проверить существует ли в таблице Licevoi_schet клиент с запрашиваемым id, если да, то изменяем сумму и отправляем на выход значение 1, иначе выходим с кодом ошибки 0 |
3.5 Выдача прав доступа
Права доступа к объектам БД приведены в таблице 8. По горизонтали - объекты БД. По вертикали - пользователи или роли. В ячейках - комбинация из букв, обозначающих права доступа:
s - право на чтение (select);
i - право на добавление строк (insert);
u - право на редактирование строк (update);
d - право на удаление строк (delete);
e - право на запуск хранимых процедур (execute).
Таблица 8. "Выдача прав доступа"
|
Объект БД |
Роли: |
|||
|
Adnin |
manager |
Prodavec |
||
|
Таблица abonenti |
siud |
s |
suid |
|
|
Таблица Uslugi |
siud |
suid |
s |
|
|
Таблица Abonentskie_uslugi |
siud |
s |
siud |
|
|
Таблица Tarifi |
siud |
suid |
s |
|
|
Таблица Licevoi_schet Содержание
|