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

DecStatus VARCHAR2(30) NOT NULL

Penalty NUMBER(6) NOT NULL

PenStatus VARCHAR2(1) NOT NULL

ifStop VARCHAR2(1) NOT NULL

9. Сущность «Дела_ФЛ_ДЛ». Данной сущности соответствует таблица PhOffCase_SSU. Ключевое поле – Номер дела (NCase) - определено на домене NUMBER(6). Остальные атрибуты сущности и их домены (в порядке соответствующем в параграфе 1) [1]:

CDate DATE NOT NULL

RepNum NUMBER(6) NOT NULL

NDecision NUMBER(5)

Docs VARCHAR2(100)

Внешние ключи:

FOREIGN KEY (RepNum) REFERENCES PhOffReport

FOREIGN KEY (NDecision) REFERENCES Decisions

10. Сущность «Дела_ЮЛ». Данной сущности соответствует таблица LgCase_SSU. Ключевое поле – Номер дела (NCase) - определено на домене NUMBER(5). Остальные атрибуты сущности и их домены (в порядке соответствующем в параграфе 1) [1]:

CDate DATE NOT NULL

RepNum NUMBER(6) NOT NULL

NDecision NUMBER(5)

Docs VARCHAR2(100)

Внешние ключи:

FOREIGN KEY (RepNum) REFERENCES LgReport

FOREIGN KEY (NDecision) REFERENCES Decisions 

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

§3. Нормализация.

Приведение  к третьей нормальной форме.

 

   База  данных считается нормализованной, если ее таблицы (по крайней мере, большинство  таблиц) представлены как минимум в третьей нормальной форме. Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации необходимо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе [3].

Стоит перечислить все свойства созданных таблиц:

• отсутствуют повторяющиеся столбцы (содержащие одинаковую по смыслу информацию);
• отсутствуют множественные столбцы (содержащие значения типа списка и т.п.);
• первичный ключ присутствует у каждой таблицы, по нему можно однозначно идентифицировать любую строку;

Данные  свойства говорят  о том, что таблицы  находятся в 1НФ.

• Неключевые столбцы таблиц зависят от первичного ключа в целом, но не от его части. Все ключи состоят из одного столбца;

Данное свойство говорит о том, что таблицы  находятся в 2НФ.

• Неключевые столбцы во всех таблицах не зависят от других неключевых столбцов, а зависят только от первичного ключа;

Данное свойство говорит о том, что таблицы находятся в 3НФ.

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

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

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

 

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

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

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

 

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

1. Манипуляции с данными
1. Добавление информации в базу
1. Нарушителей
2. Протоколов
3. Дел
4. Постановлений
2. Поиск в базе
1. Нарушителей
2. Протоколов
3. Дел
4. Постановлений
3. Обновление/удаление данных
1. Добавление постановления
2. Обновление справочников
3. Удаление дел и всех данным, связанных с ним
4. Генерация отчетности
1. Отчета за период
2. Протоколов
3. Постановлений
4. Статистический отчет
2. Администрирование

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

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

2. Удаление пользователей
3. Резервирование базы данных
4. Восстановление базы данных

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

1. Резервирование данных БД по расписанию
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;