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

5.                  Учет исполнения

На данном этапе происходит учет исполнения постановления – в течение месяца постановление должно быть исполнено. За неисполнение на нарушителя составляется протокол по статье, указанной в КоАП [7].

Глава 2. Проектирование базы данных

«Учет административных правонарушений»

§1. Логическая модель данных

Процесс выделения всех сущностей закончен  – далее представлены составленные сущности:

1.      Нарушитель_ФЛ_ДЛ (Номер нарушителя, фамилия, имя, отчество, дата рождения, место рождения, место жительства (прописки), контактный телефон, место работы (службы или учебы), занимаемая должность, семейное положение, количество иждивенцев, Ф_или_Д);

2.      Нарушитель_ЮЛ (Номер нарушителя, полное наименование ЮЛ, сокращенное наименование ЮЛ, место нахождения, законный представитель ЮЛ, Банковские реквизиты);

3.      Потерпевшие (Номер потерпевшего, фамилия, имя, отчество, место жительства, контактный телефон); 

4.      Свидетели (Номер свидетеля, фамилия, имя, отчество, место жительства, контактный телефон);

5.      Статьи (Номер статьи, Имя в Законе, Штраф_ФЛ_Мин, Штраф_ФЛ_Макс, Штраф_ДЛ_Мин, Штраф_ДЛ_Макс, Штраф_ЮЛ_Мин, Штраф_ЮЛ_Макс, Пояснения );

6.      Протокол_ФЛ_ДЛ (номер протокола, дата протокола, место совершения, Номер_нарушителя_ФЛ_ДЛ, описание нарушения, Номер статьи, Номер свидетеля, Номер доп_свидетеля, Номер потерпевшего, Номер доп_потерпевшего, объяснения нарушителя, приложенные документы, подвергалось ли?);

7.      Протокол_ЮЛ (номер протокола ,дата протокола, место совершения, Номер нарушителя_ЮЛ, описание нарушения, Номер статьи , Номер свидетеля, Номер доп_свидетеля, Номер потерпевшего, Номер доп_потерпевшего, объяснения нарушителя, приложенные документы, подвергалось ли?););

8.      Постановления (Номер постановления, Дата постановления, Состав комиссии, Статус постановления, Штраф, Статус штрафа, отменено ли?);

9.      Дела_ФЛ_ДЛ (Номер дела , дата заведения дела, номер протокола_ФЛ_ДЛ, номер постановления, приложенные документы);

10. Дела_ЮЛ (Номер дела , дата заведения дела, номер протокола_ЮЛ, номер постановления, приложенные документы).

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

      Сущность «Протокол_ФЛ_ДЛ»:

      Протокол_ФЛ_ДЛ – Нарушитель_ФЛ_ДЛ. Каждый нарушитель может нарушить Закон множество раз (что будет зафиксировано в каждом случае в протоколе), но каждый отдельно составленный протокол содержит только одного нарушителя. Таким образом, связь вида «один-ко-многим» [1,3].

      Протокол_ФЛ_ДЛ – Статьи. Статьи Закона могут содержаться во многих протоколах, но каждый отдельно составленный протокол ссылается только на одну статью. Таким образом, связь вида «один-ко-многим» [1,3].

      Протокол_ФЛ_ДЛ(ЮЛ) – Свидетели (свидетель, дополнительный свидетель). Каждый свидетель может оказаться участником нескольких правонарушений, но каждый отдельно составленный протокол ссылается только на одного свидетеля. Таким образом, связь вида «один-ко-многим» [1,3].

      Протокол_ФЛ_ДЛ(ЮЛ) – Потерпевшие (потерпевший, дополнительный потерпевший). Каждый потерпевший может оказаться участником нескольких правонарушений, но каждый отдельно составленный протокол ссылается только на одного потерпевшего. Таким образом, связь вида «один-ко-многим» [1,3].

      Сущность «Протокол_ЮЛ»:

      Протокол_ЮЛ – Нарушитель_ЮЛ - Каждый нарушитель может нарушить Закон множество раз (что будет зафиксировано в каждом случае в протоколе), но каждый отдельно составленный протокол содержит только одного нарушителя. Таким образом, связь вида «один-ко-многим» [1,3].

      Протокол_ЮЛ – Статьи. Статьи Закона могут содержаться во многих протоколах, но каждый отдельно составленный протокол ссылается только на одну статью. Таким образом, связь вида «один-ко-многим» [1,3].

      Протокол_ЮЛ – Свидетели (свидетель, дополнительный свидетель). Каждый свидетель может оказаться участником нескольких правонарушений, но каждый отдельно составленный протокол ссылается только на одного свидетеля. Таким образом, связь вида «один-ко-многим» [1,3].

      Протокол_ЮЛ – Потерпевшие (потерпевший, дополнительный потерпевший). Каждый потерпевший может оказаться участником нескольких правонарушений, но каждый отдельно составленный протокол ссылается только на одного потерпевшего. Таким образом, связь вида «один-ко-многим» [1,3].

      Сущность «Дела_ФЛ_ДЛ»:

      Дела_ФЛ_ДЛ – Протокол_ФЛ_ДЛ. Составленных протоколов много, но только один находится в каждом деле. Таким образом, связь вида «один-ко-многим» [1,3].

      Дела_ФЛ_ДЛ – Постановления. Постановления могут быть вынесены на многих лиц, в том числе и на физических и должностных, но в каждом отдельном деле хранятся лишь данные об одном постановлении. Таким образом, связь вида «один-ко-многим» [1,3].

      Сущность «Дела_ЮЛ»:

      Дела_ЮЛ – Протокол_ЮЛ. Составленных протоколов много, но только один находится в каждом из дел. Таким образом, связь вида «один-ко-многим» [1,3].

      Дела_ЮЛ – Постановления. Постановления могут быть вынесены на многих лиц,  но в каждом отдельном деле хранятся данные только об одном постановлении. Таким образом, связь вида «один-ко-многим» [1,3].

Теперь, основываясь на созданных сущностях и описанных связях, которые были построены методом «сущность-связь», можно создать логическую модель данных – ER-диаграмму (Приложение-Рис.1) [3]. В качестве инструментального средства был выбран построитель схем данных Microsoft Office Access 2007.

§2. Физическая модель данных

Итак, построение логической модели данных посредством ER-диаграмм позволило осуществить переход к следующему этапу проектирования - построению физической модели базы данных. Результатом работы на данном этапе является реляционная модель данных, представляющая собой схему структуры базы данных разрабатываемой ИС [1].

Результатом соответствующего параграфа данной главы стала группа сущностей. Необходимо рассмотреть каждую и каждому атрибуту сопоставить домен.

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

Fam VARCHAR2(30) NOT NULL

Name VARCHAR2(30) NOT NULL

Ptr VARCHAR2(30) NOT NULL

BDate DATE NOT NULL

BPlace VARCHAR2(70) NOT NULL

LPlace VARCHAR2(100) NOT NULL

Phone NUMBER(11),

JPlace VARCHAR2(40) NOT NULL

Post VARCHAR2(30)

MStatus VARCHAR2(20) NOT NULL

NDep NUMBER(1) NOT NULL

PHorOff VARCHAR2(1) NOT NULL

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

LgFullName VARCHAR2(100)

LgName VARCHAR2(100) NOT NULL

Place VARCHAR2(100) NOT NULL

LgRpsnt VARCHAR2(70) NOT NULL

Requisit VARCHAR2(150) NOT NULL

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

Fam VARCHAR2(30) NOT NULL

Name VARCHAR2(30) NOT NULL

Ptr VARCHAR2(30) NOT NULL,

LPlace VARCHAR2(100)

Phone NUMBER(11)

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

Fam VARCHAR2(30) NOT NULL

Name VARCHAR2(30) NOT NULL

Ptr VARCHAR2(30) NOT NULL,

LPlace VARCHAR2(100)

Phone NUMBER(11)

5.                  Сущность «Статьи». Данной сущности соответствует таблица Article. Ключевое поле – Номер статьи (NAr) - определено на домене NUMBER(2). Остальные атрибуты сущности и их домены (в порядке соответствующем в параграфе 1):

NFromLaw VARCHAR2(8) NOT NULL

PenaltyPhMin NUMBER(6)

PenaltyPhMax NUMBER(6)

PenaltyOffMin NUMBER(6)

PenaltyOffMax NUMBER(6)

PenaltyLgMin NUMBER(6)

PenaltyLgMax NUMBER(6)

Explain VARCHAR2(300)

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

RDate DATE NOT NULL

Place VARCHAR2(150) NOT NULL

NPhOffIfr NUMBER(6) NOT NULL

About VARCHAR2(100) NOT NULL

NAr NUMBER(2) NOT NULL

NWt NUMBER(5)

dop_NWt NUMBER(5)

NVc NUMBER(5)

dop_NVc NUMBER(5)

Explanat VARCHAR2(200)

Docs VARCHAR2(100)

ifPnshm VARCHAR2(1)

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

FOREIGN KEY (NPhOffIfr) REFERENCES PhysicalOfficialInfringer

FOREIGN KEY (NAr) REFERENCES Article

FOREIGN KEY (NWt) REFERENCES Witness

FOREIGN KEY (NVc) REFERENCES Victim

FOREIGN KEY (dop_NWt) REFERENCES Witness(NWt)

FOREIGN KEY (dop_NVc) REFERENCES Victim(NVc)

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

RDate DATE NOT NULL

Place VARCHAR2(150) NOT NULL

NLgIfr NUMBER(6) NOT NULL

About VARCHAR2(100) NOT NULL

NAr NUMBER(2) NOT NULL

NWt NUMBER(5)

dop_NWt NUMBER(5)

NVc NUMBER(5)

dop_NVc NUMBER(5)

Explanat VARCHAR2(200)

Docs VARCHAR2(100)

ifPnshm VARCHAR2(1)

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

FOREIGN KEY (NLgIfr) REFERENCES LegalInfringer

FOREIGN KEY (NAr) REFERENCES Article

FOREIGN KEY (NWt) REFERENCES Witness

FOREIGN KEY (NVc) REFERENCES Victim

FOREIGN KEY (dop_NWt) REFERENCES Witness(NWt)

FOREIGN KEY (dop_NVc) REFERENCES Victim(NVc)

8.                  Сущность «Постановления». Данной сущности соответствует таблица Decisions. Ключевое поле – Номер постановления (NDecision) - определено на домене NUMBER(7). Остальные атрибуты сущности и их домены (в порядке соответствующем в параграфе 1) [1]:

DDate DATE

Commision VARCHAR2(200) NOT NULL

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НФ.