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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


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

Информация:

Тип работы: курсовая работа. Добавлен: 08.11.2012. Сдан: 2012. Страниц: 14. Уникальность по antiplagiat.ru: < 30%

Описание (план):


?Министерство образования и науки Российской Федерации
Государственное образовательное учреждение
Высшего профессионального образования
«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
 
Факультет
Механико-математический
Кафедра
«Информатики и вычислительной математики»
Специальность
«Математическое обеспечение и
администрирование информационных систем»
 
 
РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ УЧЕТА
АДМИНИСТРАТИВНЫХ ПРАВОНАРУШЕНИЙ
КУРСОВАЯ РАБОТА
 
Выполнил студент
3 курса 22.301.10 группы
Старобинец
Валентин Викторович
 
____________________
 
Научный руководитель
к. ф.-м.н., доцент
Луканов А.С.
 
____________________
 
Работа защищена
«___»_________2010 г.
Зав. кафедрой
д.ф.-м.н., профессор
Степанов А.Н.
 
____________________
 
«___»_________2010 г.
 
Самара, 2010 г.

Содержание:

Введение
Глава 1. Анализ предметной области учета административных правонарушений
Глава 2. Проектирование базы данных «Учет административных правонарушений»
§1. Логическая модель данных
§2. Физическая модель данных
§3. Нормализация. Приведение к третьей нормальной форме
Глава 3. Проектирование и реализация информационной системы «Учет АП»
§1. Построение модели архитектуры системы
§2. Описание интерфейса приложений клиентской части
§3. Клиент-серверная реализация проекта
§4. Руководство пользователя ИС «Учет АП»
Заключение
Список использованной литературы
Приложения

 
 



Введение
 
В настоящее время, несмотря на повышение компьютеризации общества, во многих сферах жизни общества до сих пор нет средств, позволяющих в достаточной мере автоматизировать процесс составления стандартных бланков, ведения документации и отчетности.
Одной из составных задач можно рассматривать проблему ведения отчетности по делам об административных правонарушениях.
О своевременности и актуальности рассматриваемой проблемы говорит тот факт, что достаточно большую часть своего времени работники административных комиссий тратят на поиски дел и протоколов об административных правонарушениях и составление отчетов для вышестоящих органов  доступными им средствами [6]. А также тот факт, что результатом запроса во всемирной сети интернет вида «Программа для учета дел об административных правонарушениях» - являются только законы и постановления.
В каждом городе в каждом районе присутствует административная комиссия. Также существуют учреждения, занимающиеся учетом работы комиссий и исполнений постановлений, все эти органы работают «по-старинке».
Учитывая вышесказанное, возникает вопрос: как же организовать данный процесс целиком, начиная от составления протокола и до исполнения постановления, более эффективно и при меньших затратах, чем процесс, выработанный и отлаженный годами, тысячами людьми [5].
Поиск ответа порождает выделение целей, для достижения которых ставятся задачи и ищутся пути их решения. Традиционная система учета, контроля и хранения информации является достаточно  надежной и устойчивой, но обладает некоторыми недостатками, такими как:
?                  Моральное старение бумажного носителя как средства хранения информации;
?                  Высокая нагрузка на всех сотрудников, участвующих в данном процессе;
?                  Необходимость вести архивы, на управление которыми требуются дополнительные сотрудники;
?                  Необходимость специального обучения сотрудников;
?                  Сложность в составлении отчетности по более общим участкам (таким как город), так как все сотрудники индивидуальны.
Выделение данных недостатков, а также актуальность проблемы послужили предпосылками к разработке данного проекта. Цель данной работы - создание производительной, универсальной информационной системы (ИС), включающей в себя хорошо масштабируемую, а также надежную базу данных и взаимодействующее с ней клиентское приложение [2,3].
Результатом работы должна стать безопасная, устойчивая к физическим и логическим противоречиям, возникающим при некорректной работе с данными, удобная в использовании ИС, выполненная по архитектуре клиент-сервер. Безусловно, разрабатываемая ИС, должна обеспечивать разделение ресурсов и операций над ними, которые будут поддерживаться ИС [1,3]. Также следует учесть, что архитектура сервера БД может быть выполнена по-разному, в зависимости от производителя - следовательно, клиентская часть разработанной ИС должна обладать  независимостью от выбора сервера[1,3].


Глава 1. Анализ предметной области учета административных правонарушений
 
Для понимания сущности проблемы необходимо знать, где описан процесс, начинающийся составлением протокола об административном правонарушении и заканчивающийся исполнением постановлением, вынесенным административной комиссией и из каких частей он состоит и, наконец, что же такое административное правонарушение. Данный процесс описан в кодексе Российской Федерации об административных правонарушениях (КоАП РФ) [7].
КоАП РФ - кодифицированный нормативный акт, регулирующий общественные отношения по привлечению к административной ответственности, а также устанавливающий общие начала, перечень всех административных правонарушений  (который может быть дополнен на региональном уровне), органы, рассматривающие дела, порядок привлечения к административной ответственности и порядок исполнения решений по административным делам.
Административное правонарушение — противоправное, виновное действие (бездействие) лица (физического или юридического), за которое законодательством об административных правонарушениях установлена административная ответственность[5].
Объектами посягательства при административных правонарушениях могут являться собственность, здоровье населения и общественная нравственность, общественный порядок, экология и т. д.
Ознакомившись с определениями и понятиями, можно выделить стадии [7]:
1.                  Административное нарушение
2.                  Составление протокола
2.1   Сбор данных о нарушителе
2.2   Сбор данных потерпевших
2.3   Сбор данных о свидетелях
2.4   Выбор статьи из Закона[12] и штрафа из статьи
3.                  Вынесение решения по нарушению
4.                  Создание дела об административном правонарушении
4.1   Подкрепление созданного протокола
4.2   Подкрепление созданного постановления
5.                  Учет исполнения постановления
А также, по окончанию месяца, квартала, года составление отчетности о работе административных комиссий по районам и по городу, дополнительные отчеты по нарушениям в разных сферах правонарушений для ведения статистики и формирования общественного мнения.
На каждой стадии  легко выделяется ключевой объект. Были изучены основные свойства каждого, особенности и функции, которые они выполняют, связи с другими объектами. Результатом данной работы, выполненной на каждом этапе, стала сущность, каждая из которых станет элементом будущей концептуальной модели данных [1].
Для каждого этапа параллельно будем решать, что из данных, принадлежащих этапу, является сущностью, а что атрибутами сущности.
1.                  Административное нарушение
Этот этап не имеет прямого отношения к данной работе, но его нельзя опустить, так как он является началом для работы сотрудников правопорядка, а значит важным в анализе предметной области.
2.                  Составление протокола
Данный этап очень важен, так как является ключевым и фиксирует факт нарушения, но является довольно общим, поэтому сначала рассмотрим его составляющие:
2.1        Сбор данных о нарушителе
Необходимо вспомнить, что Закон, который рассматривается, регулирует ответственность за правонарушения для физических (ФЛ), должностных (ДЛ) и юридических (ЮЛ) лиц.
Необходимые сведения:
2.1.1           Физическое лицо: фамилия, имя, отчество, дата рождения, место рождения, место жительства (прописки), контактный телефон, место работы (службы или учебы), занимаемая должность, семейное положение, количество иждивенцев; Являются атрибутами;
2.1.2           Юридическое лицо: полное наименование ЮЛ, сокращенное наименование ЮЛ, место нахождения, законный представитель ЮЛ, Банковские реквизиты; Являются атрибутами;
2.1.3           Должностное лицо: это «особенное» физическое лицо. Его отличие состоит в том, что оно обязательно является сотрудником какой-либо организации и для него присутствуют «особые» штрафы в Законе;
На данном этапе можно выделить две сущности, да, именно две, так как нет смысла хранить два отдельных справочника об одинаковых структурах (ФЛ и ДЛ). Это затруднит запросы, усложнит структуру БД и увеличит время выборки данных. Чтобы решить проблему идентификации типа лица, введем дополнительный атрибут «Ф или Д».
Выделенные сущности еще фактически не являются таковыми, так как в них нет ключевых полей, ведь кортежи должны обладать уникальностью в пределах сущности [3]. Тут мы вводим искусственный атрибут «Номер_ФЛ_ДЛ (ЮЛ)». Этот атрибут и поможет нам  однозначно идентифицировать лицо.
На данном шаге было выделено 2 сущности – «Нарушитель_ФЛ_ДЛ» и «Нарушитель_ЮЛ» с указанными выше атрибутами. Являются справочниками.
2.2             Сбор данных о потерпевших
Необходимые сведения: фамилия, имя, отчество, место жительства, контактный телефон;
Все сведения являются явными атрибутами, для составления сущности воспользуемся способом, указанным в п. 2.1. Получена сущность «Потерпевшие (Номер потерпевшего, … )».  Является справочником.
2.3             Сбор данных о свидетелях
Необходимые сведения: фамилия, имя, отчество, место жительства, контактный телефон;
Все сведения являются явными атрибутами, для составления сущности воспользуемся способом, указанным в п. 2.1. Получена сущность «Свидетели (Номер потерпевшего, … )».  Является справочником.
2.4             Выбор статьи Закона и штрафа
Закон является справочником нарушений, но закон находится на бумаге и будущая ИС не сможет «пролистать» и посмотреть, какой назначить штраф.
Закон следует оформить как сущность со следующими атрибутами: Штраф_ФЛ_Мин, Штраф_ФЛ_Макс, Штраф_ДЛ_Мин, Штраф_ДЛ_Макс, Штраф_ЮЛ_Мин, Штраф_ЮЛ_Макс. Необходимо добавить 2 дополнительных поля -  первое - для хранения каких-либо пояснений, второе - для хранения наименования главы, статьи и, возможно, пункта. Для составления сущности воспользуемся способом, указанным в п. 2.1 . Получена сущность «Статьи (Номер статьи, Имя в Законе, …, Пояснения )».
На этом рассмотрение всех составляющих будущей сущности протокол закончено. Выделяем более общую сущность «Протокол» для каждого типа нарушителя. Эти объекты будут идентичны по составу, но будут связаны с разными сущностями. Возникает связь, а для этого необходимы два объекта, для чего воспользуемся ранее созданными сущностями [1,3]. Связи будут осуществляться следующим образом – Номер потерпевшего, Номер_доп_потерпевшего с сущностью «Потерпевшие» с полем Номер_потерпевшего; «Номер свидетеля», Номер_доп_свидетеля с сущностью «Свидетели» с полем «Номер свидетеля»; Номер_нарушителя_ФЛ_ДЛ (ЮЛ) с сущностью «Нарушитель_ФЛ_ДЛ» с полем Номер_нарушителя_ФЛ_ДЛ (ЮЛ); Номер статьи с сущностью «Статьи» с полем «Номер статьи».
Также сущность «Протокол_ФЛ_ДЛ(ЮЛ)» содержит следующие данные – номер протокола(п.2.1), дата протокола, место совершения, описание нарушения, объяснения нарушителя, приложенные документы и специальная метка, обозначающая  «злостного нарушителя» -  подвергалось ли данное лицо административному наказанию в течение года – данные злоупотребления тоже регулируются в Законе.
3.                  Вынесение решения по нарушению
Вынесением решения занимается административная комиссия в составе нескольких компетентных человек, которые принимают решение о наказании. Решение оформляется в виде постановления [7]. Комиссия может отменить принятое постановление.
Таким образом, сущность «Постановления» обладает следующими атрибутами: номер постановления (п.2.1), дата постановления, состав комиссии, штраф, статус штрафа (оплачен?), статус постановления, «отменено ли?».
Постановление может находиться в 4 состояниях:
а.               Возвращено
б.               Прекращено
в.               Вынесено предупреждение
г.               Вынесен штраф
4.                  Создание дела об административном правонарушении
На этом этапе аналогично выделяется 2 сущности, содержащие атрибуты: Номер дела (п.2.1), дата заведения дела, номер протокола (связь с сущностью «Протокол»), номер постановления (связь с сущностью «Постановления»), приложенные документы). Получили сущности «Дела_ФЛ_ДЛ» и «Дела_ЮЛ».
 
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НФ.
?      Во всех таблицах притствует только один потенциальный первичный ключ. Предположение: «Никакая комбинация столбцов не сможет однозначно идентифицировать строку» Стоит убедиться в этом на сущности Нарушитель_ФЛ_ДЛ. Если объединить все столбцы, кроме ключевого, то можно однозначно идентифицировать нарушителя, так как не существует двух однофамильцев, работающих на одном и том же предприятии, занимающих одну и ту же должность. Если они оба являются не работающими, то контактный телефон в купе с местом жительства сможет определить личность.
Выдвинутое предположение опровергнуто, следовательно созданная реляционная модель не находится в НФБК.
Как писалось ранее, база данных, находящаяся в 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;
 
Также существуют триггеры на проверку существования данной записи в таблице. Данный триггер актуален для сущности «Нарушители». Нет необходимости записывать «злостного нарушителя» еще раз, этим действием происходит экономия дискового пространства.
Стоит отметить, что в программе происходит много операций поиска, а
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.