Разработка информационной системы по учету административных правонарушений

      Во всех таблицах притствует только один потенциальный первичный ключ. Предположение: «Никакая комбинация столбцов не сможет однозначно идентифицировать строку» Стоит убедиться в этом на сущности Нарушитель_ФЛ_ДЛ. Если объединить все столбцы, кроме ключевого, то можно однозначно идентифицировать нарушителя, так как не существует двух однофамильцев, работающих на одном и том же предприятии, занимающих одну и ту же должность. Если они оба являются не работающими, то контактный телефон в купе с местом жительства сможет определить личность.

Выдвинутое предположение опровергнуто, следовательно созданная реляционная модель не находится в НФБК.

Как писалось ранее, база данных, находящаяся в 3НФ, является довольно устойчивой и правильно построенной. В созданной модели отсутствует или практически отсутствует избыточность, дублирование данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем использованного дискового пространства.

Глава 3. Проектирование и реализация

информационной системы «Учет АП»

§1. Построение модели архитектуры системы

В ходе анализа предметной области и поиска решения поставленной задачи, были выделены следующие функциональные возможности, которые должна обеспечивать разрабатываемая система [2]:

1.   Манипуляции с данными

1.1    Добавление информации в базу

1.1.1       Нарушителей

1.1.2       Протоколов

1.1.3       Дел

1.1.4       Постановлений

1.2    Поиск в базе

1.2.1       Нарушителей

1.2.2       Протоколов

1.2.3       Дел

1.2.4       Постановлений

1.3    Обновление/удаление данных

1.3.1       Добавление постановления

1.3.2       Обновление справочников

1.3.3       Удаление дел и всех данным, связанных с ним

1.4    Генерация отчетности

1.4.1       Отчета за период

1.4.2       Протоколов

1.4.3       Постановлений

1.4.4       Статистический отчет

2.   Администрирование

2.1  Создание пользователей

2.1.1       Разграничение привилегий

2.2  Удаление пользователей

2.3  Резервирование базы данных

2.4  Восстановление базы данных

3.   Задачи по расписанию

3.1  Резервирование данных БД по расписанию

3.2  Уведомления о проверке исполнения постановлений

В качестве наборов  прав и привилегий были выбраны следующие роли: менеджер, главный менеджер, администратор.

На основе выявленных функциональных возможностей, была разработана диаграмма использования USE-CASE. Данная диаграмма была создана с помощью инструментального средства IBM Rational Rose v.7.0.0. (приложение-рис.3) [2].

§2. Описание интерфейса клиентской части

После построения модели архитектуры разрабатываемой ИС и определения функциональных возможностей, необходимо построить модель интерфейса разрабатываемого приложения.

Данный процесс состоит в перечислении основных необходимых средств для построения приложения, а также приблизительный интерфейс пользователя, который должен быть понятным и дружественным.

Так как разрабатываемая ИС обладает большим набором функций, то было принято решение о создании многооконного приложения, каждое из которых будет выполнять свою функцию или определенную группу функций. Каждый модуль приложения практически всегда должен содержать таблицу для отображения данных, полученных из БД. Размер таблицы может меняться в зависимости от выполняемой функции [4]. На каждом модуле будет располагаться множество кнопок, с помощью которых пользователь сможет выполнить требуемые манипуляции. Главное окно будет состоять из окна приветствия и главного меню, которое поможет пользователю с легкостью найти нужный ему модуль и выполнить поставленную задачу. Так как разрабатываемое приложение имеет функционал по определению ролей,  следовательно, должно разграничивать права пользователей, то перед запуском главного окна, необходимо создать окно авторизации пользователя.

§3. Клиент-серверная реализация проекта

1.      Сервер

Задача заключается в том, чтобы на момент запуска системы и на всем протяжении ее эксплуатации обеспечить требуемые:

• функциональность и адаптируемость;

• пропускную способность;

• время реакции;

• готовность;

• простоту эксплуатации;

• безопасность.

Всем выше перечисленным требованиям обладает СУБД Oracle [1]. Именно поэтому разработка серверной части будет проходить под управлением Oracle. Еще одним достоинством является то, что компания предоставляет бесплатный дистрибутив для использования, с ограничениями по распространению, а именно релиз версии 10g R2 XE [8].

2.      Клиент

Для создания клиента было принято решение использовать инструментальную среду программирования Borland® Delphi® for Microsoft® Windows™ Version 10.0.2288.42451 Update 2, которая обладает очень широкими возможностями для использования, огромную библиотеку визуальных компонентов [4], а также предлагает бесплатную 30-дневную лицензию для ознакомления, что являлось одним из ключевых факторов выбора данной среды [11].

3.      Клиент-серверное взаимодействие

Существуют две главных проблемы при реализации взаимодействия - обеспечение ссылочной целостности и логической непротиворечивости данных.

Для обеспечения ссылочной целостности все современные СУБД поддерживают триггеры на обновление и удаление [1]. Такие триггеры работают следующим образом – в зависимости от условия триггера происходит, например, удаление всех данных, связанных с таблицей, а затем удаляется сама запись в родительской таблице.

Рассмотрим случай, использованный в этом проекте. Есть сущность «Дела». Прежде чем удалить какую-либо запись из таблицы, следует произвести удаление нарушителя, на которого было заведено дело, протокол, созданный на него и свидетелей с потерпевшими, так как если дело отсутствует, то нет смысла хранить лишнюю информацию.

Текст триггера:

create or replace Trigger delete_case_report

AFTER delete on PHoffcase_ssu

FOR EACH ROW

begin

IF (:OLD.Ndecision<>0)

Then

delete from phoffcase_ssu where (NDecision=:OLD.Ndecision);

end if;

delete from phoffreport where repnum=:old.repnum;

end;

Данный триггер вызывает еще один, так как лишних данных достаточно много:

create or replace Trigger delete_report_vic_wit_ifr

AFTER delete on PHoffreport

FOR EACH ROW

begin

IF (:OLD.Nvc<>0)

Then

delete from victim where (NVc=:OLD.Nvc);

end if;

IF (:OLD.dop_Nvc<>0)

Then

delete from victim where (NVc=:OLD.dop_Nvc);

end if;

IF (:OLD.NWt<>0)

Then

delete from witness where (NWt=:OLD.NWt);

end if;

IF (:OLD.dop_NWt<>0)

Then

delete from witness where (Nwt=:OLD.dop_NWt);

end if;

delete from PHOFFIFR where (NPhOffIfr=:old.NPhOffIfr);

end;

Также существуют триггеры на проверку существования данной записи в таблице. Данный триггер актуален для сущности «Нарушители». Нет необходимости записывать «злостного нарушителя» еще раз, этим действием происходит экономия дискового пространства.

Стоит отметить, что в программе происходит много операций поиска, а чаще всего поиск нарушителя. Для более быстрого поиска, а главное для разгрузки СУБД, стоит создать индекс по фамилии, имени и отчеству [3]:

CREATE INDEX PHOFFIFR_IND on PHOFFIFR(Fam,Name,Ptr);

Каждый раз при добавлении какой-либо записи в таблицу, клиенту необходимо назначить первичный ключ. Данную операцию помогают выполнить последовательности, хранящиеся на сервере. Некоторые из них:

CREATE SEQUENCE Vic_Seq INCREMENT BY 1 START WITH 1 MAXVALUE 99999 NOCYCLE NOCACHE;

CREATE SEQUENCE Wit_Seq INCREMENT BY 1 START WITH 1 MAXVALUE 99999 NOCYCLE NOCACHE;

CREATE SEQUENCE PHOFFIFR_Seq INCREMENT BY 1 START WITH 1 MAXVALUE 999999 NOCYCLE NOCACHE;

CREATE SEQUENCE PHOFFCASE_Seq INCREMENT BY 1 START WITH 1 MAXVALUE 999999 NOCYCLE NOCACHE;

CREATE SEQUENCE PHOFFREP_Seq INCREMENT BY 1 START WITH 1 MAXVALUE 999999 NOCYCLE NOCACHE;

CREATE SEQUENCE DECISION_SEQ INCREMENT BY 1 START WITH 1 MAXVALUE 9999999 NOCYCLE NOCACHE;

Очень важным пунктом в ведении базы данных является сохранность данных и устойчивость к сбоям. Для этого необходимо, чтобы данные резервировались на ВЗУ с некоторой периодичностью. Oracle 10g обладает встроенным составителем расписаний, и к тому же позволяет запускать внешние по отношению к нему программы [1]. С помощью DBMS_SCHEDULER было создано расписание, программа для выполнения и задача, которая и будет по расписанию запускать резервирование данных. Принято решение о каждодневном однократном резервировании:

BEGIN

DBMS_SCHEDULER.CREATE_SCHEDULE

( schedule_name   => 'BackUP_schedule'

, start_date      => SYSTIMESTAMP

, repeat_interval => 'FREQ=WEEKLY; BYDAY=MON, TUE, WED, THU, FRI'

) ;

END;

BEGIN

DBMS_SCHEDULER.CREATE_PROGRAM

( program_name  => 'BackUP_program'

, program_type  => 'EXECUTABLE' , program_action => 'C:\oraclexe\app\oracle\product\10.2.0\server\BIN\BackUP.bat'

, enabled       => TRUE

);

END;

BEGIN

DBMS_SCHEDULER.CREATE_JOB

( job_name      => 'compound_job'

, program_name  => 'BackUP_program'

, schedule_name => 'BackUP_schedule'

, enabled       => TRUE

);

END;

В созданной базе данных присутствует сущность постановление, которое по закону следует исполнить, то есть оплатить. Для этого законом предусмотрено 30 суток. Тут возникает новая цель – введение некого «будильника», который будет напоминать административной комиссии, что следует проверить состояние исполнения постановления.

Следует отметить, что приложение, работающее в режиме «администратора» способно создавать и удалять пользователей, назначать роли и отбирать их, предоставлять привилегии на объекты.

Представленные связи между клиентом и сервером являются наиболее важные для рассмотрения, остальное взаимодействие происходит на уровне запросов.

Рассмотрим основные используемые компоненты для реализации клиента. Используются такие компоненты как ADOQuery, DBGrid, ADOConnection, DataSourсe. ADOQuery является связующим звеном, так как именно он отправляет запросы, требуемые пользователю, на сервер – полученные данные отображаются в компоненте DBGrid [4].

В создаваемой программе заявлена функция создания отчетности – данную функцию было решено реализовать с помощью подключаемого средства от Borland, называемое Rave Reports – генерация отчетов. С примером одного из возможных отчетов можно будет ознакомиться в приложении.

§4. Руководство пользователя ИС «Учет АП»

1.        Запуск и авторизация

При запуске созданной программы «Учет АП» появится окно процесса загрузки. Следующим шагом будет авторизация, и пользователь сможет выполнить вход в трех режимах – «Администратор», «Менеджеры» и «Демо». Последний был создан для ознакомления с интерфейсом программы, подключение к базе данных не будет осуществлено. Для выбора этого режима в поля «Имя пользователя» и «Пароль» необходимо ввести «demo» без кавычек. Результатом успешной авторизации будет отображение главного окна приложения.

2.        Работа в режиме «Менеджеры»

В данном режиме данные могут вводиться, обновляться и удаляться, но последние две группы функций доступны только в том случае, если пользователь является главным менеджером или администратором. Также возможна генерация всевозможных отчетов, их печать и сохранение на ВЗУ.

3.        Работа в режиме «Администратор»

В этом режиме появляется расширенное главное меню. Все функции, которые могут выполнять менеджеры, также доступны для администратора, но главной задачей этого режима является создание и удаление пользователей, распределение ролей, а также возможность дополнительного резервирования данных и восстановления данных в случае сбоя.

Заключение

Главной целью проделанной работы было создание надежной и удобной, приятной в использовании и непротиворечивой хорошо масштабируемой системы, основным назначением которой является учет административных правонарушений. Ключевыми критериями были масштабируемость, универсальность и однотипность [3]. Для реализации главной цели была изучена предметная область, после чего был создан проект системы, была построена логическая модель данных, физическая модель реляционной базы данных, диаграмма использования Use-Case, описание интерфейса клиентской части и выбор средств для реализации поставленных задач, как на сервере, так и на клиенте. В ходе моделирования базы данных и определения функциональных возможностей системы был выделен ряд задач, которые были решены на этапе реализации. После завершения написания кода программы , созданное ПО было протестировано по методу «белого ящика» - используя заведомо известные данные и результаты, проверялась правильность работы программы [2]. Как итог была получена расширяемая ИС с надежной, масштабируемой и универсальной базой данных. Данный продукт находится на стадии разработки, но возможно начать тестовое использование для проверки работоспособности и выявлении недочетов, а также новых функциональных возможностей.