База данных ‘Учет решений по уголовным делам’

метки: Уголовный, Преступление, Единый, Система, Правоохранительный, Основной, Решение, Таблица

Основные идеи современной информационной технологии базируются на концепции баз данных (БД).

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

Обычно существует три класса СУБД, которые обеспечивают работу иерархических, сетевых и реляционных моделей. Однако различия между этими классами постепенно стираются, причем, видимо, будут появляться другие классы, что вызывается прежде всего интенсивными работами в области баз знаний (БЗ) и объектно-ориентированной инфотехнологией. Поэтому традиционная классификация используется все реже, а пока мы будем придерживаться ее, как наиболее устоявшейся. Каждая из этих моделей имеет функции, которые делают ее наиболее удобной для конкретных приложений.

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

Первоначально OLE был стандартом для связывания и встраивания объектов. Активация приложения сервера OLE происходит в контейнере, расположенном в приложении. Визуально, когда сервер OLE активирован, текущие панели инструментов и меню заменяются или объединяются с панелями инструментов и меню сервера OLE. Кроме того, часть формы становится окном сервера OLE, поскольку сервер берет на себя управление областью формы. Связыванием называют ассоциирование файла объекта OLE с контейнером OLE. Объектный файл никогда не сохраняется в контейнере, но контейнер OLE ссылается на файл. Одним из преимуществ связывания объектов является то, что несколько пользователей, серверов OLE и контейнерных приложений могут получить доступ к одному документу. При встраивании объектов фактический объект сохраняется в приложении, и другие контейнеры OLE не имеют доступа к этому объекту. Преимущество внедрения заключается в том, что данные хранятся как часть приложения.

Передо мной были поставлены следующие задачи:

• Даталогическое моделирование
• Создание базы данных и объектов базы данных
• Резервное копирование

Цель данной работы — создать базу данных в СУБД Microsoft SQL Server 2008, объекты базы данных, распределить полномочия и роли, предусмотреть возможность резервного копирования.

Дипломная работа восстановление данных

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

1. Выбор автоматизируемых функций и информационного обеспечения

1 Описание предметной области

Тематическая область, часть которой представлена ​​в данной программе, — внедрение и функционирование информационной системы «Регистрация решений по уголовным делам». Это большая и часто используемая задача в современном мире, требующая точного выполнения. Описаны операционная среда, объект и объект управления, цели и задачи управления.

Операционная среда системы «Учет решений по уголовным делам» включает в себя наименование УВД, работающих в нем следователей, какие уголовные дела они ведут и какие решения были приняты по этому делу.

Объектом управления является процесс расследования уголовных дел в отношении лиц, нарушивших конституционные права граждан. Которые были нарушены в результате противоправных действий злостных нарушителей общественного порядка.

Объектом управления являются сотрудники, которые работают в данном ОВД и обеспечивают функционирование информационной системы «Регистрация решений по уголовным делам».

Задача отдела — раскрытие следователями уголовных дел и вынесение решения.

Для достижения этой цели в процессе управления решаются следующие задачи:

Выбор уголовных дел, начатых в заданный период времени в данном ОВД

Выбор следователей заданного ОВД, которым возвращены уголовные дела на доследование

Выбор приостановленных дел указанного ОВД

Выбор уголовных дел, ведущихся данным следователем, по которым проходит больше заданного количества обвиняемых

2 Выбор и описание автоматизируемых функций

Перечень автоматизируемых функций

В рамках данного проекта для автоматизации выбраны следующие функции автоматизированной системы УЧЕТ РЕШЕНИЙ ПО УГОЛОВНЫМ ДЕЛАМ :

) ОВД;

) Должность;

) Следователь;

) Уголовное дело;

) Решение.

Первичное описание информационного обеспечения (исходные данные)

ОбъектАтрибутОписание атрибута1. ОВД1.1 ФИО куратора 1.2 Наименование ОВД 1.3. Служба ведущая дело Название ОВД Какая служба занимается делом2. Должность2.1 ДолжностьЗамещаемая должность3. Уголовное дело3.1 Дата начала УД 3.2 Дата окончания УД 3.3. Кол-во обвиняемых 3.4. Кол-во эпизодов 3.5. Квалификация В чём обвиняется4. Следователь1.1 ФИО 1.2 Дата рожденияФИО следователя5. Решение5.1 Принятое решение 5.2 Дата принятия решения 5.3 Лицо принявшее решение 6. Звание6.1 Звание

Постановка задачи

Написать программу, которая позволит реализовать порядок функционирования информационной системы «УЧЕТ РЕШЕНИЙ ПО УГОЛОВНЫМ ДЕЛАМ». Разработанный программный продукт должен частично или полностью заменить стандартные методы организации информации в работе следователей.

Задачи программы:

нормализация базы данных

создание БД в SQL сервере;

База данных: подсистема «ЗАГС»

... работы программы При запуске программы появляется окно, содержащее поле для выбора таблицы. После выбора таблицы происходит открытие этой таблицы и все её данные отражаются в специально-отведенной части. Таблица «ЗАГС» ... технических аспектов, связанных с проектированием базы данных. Концептуальная модель данных не привязана к конкретной физической реализации баз данных и не зависит от конкретной ...

администрирование базы данных (резервное копирование);

создание таблиц;

использование триггеров (триггер на добавление) и встроенных процедур;

создание запросов (сложных и простых);

Фильтры (вывести на экран только звание «подполковник»)

Триггеры (индикатор на добавление);

Функции (функция отбора по возрасту);

Ограничения (ограничение возраста сотрудника менее 18 и более 80 лет):

Пользователи и роли.

2. Даталогическое моделирование

2.1 Нормализация

НФ (Нормальная Форма)

Название таблицыКлючевое поледолжность звание ОВД решение следователь уг_делок_должности к_звания к_ОВД к_решения к_следователя, к_звания, к_должности к_уг_дела, к_следователя, к_решения, к_ОВД

НФ:

Ограничения 1NF удовлетворяются, и каждый неключевой атрибут функционально полностью зависит от составного первичного ключа.

НФ:

Все неключевые атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.

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

Даталогическая модель в MS SQL Server

Таблица данных A — уг_делоИмяТип данныхРазмер поляNULLк_уг_делаbigintк_ОВДbigintдак_следователяbigintдадата_начала УДdateдаДата_окончания dateдаквалификациятекстовый50дакол_во_обвиняемыхтекстовый50дакол_во эпизодовтекстовый50дак_решенияbigintдаКлючи связиТип ключаСостав полейНазначениеПервичныйк_уг_делаВторичныйк_ОВДСвязь с таблицей СВторичныйк_следователяСвязь с таблицей FВторичныйк_решенияСвязь с таблицей BТаблица данных B — решениеИмяТип данныхРазмер поляNULLк_решенияbigintпринятое_решениетекстовый50дадата_принятиятекстовый50далицо_принявшее_решениетекстовый50даКлючи связиТип ключаСостав полейНазначениеПервичныйк_решенияСвязь с таблицей АТаблица данных C -ОВДИмяТип данныхРазмер поляNULLк_ОВДbigintнаименивание_ОВДтекстовый50даФИО_куратора_ОВДтекстовый50даслужба_ведущая_делотекстовый50даКлючи связиТип ключаСостав полейНазначениеПервичныйк_ОВДСвязь с таблицей АТаблица данных D — званиеИмяТип данныхРазмер поляNULLк_званияbigintзваниетекстовый50даКлючи связиТип ключаСостав полейНазначениеПервичныйк_званияСвязь с таблицей FТаблица данных E — должностьИмяТип данныхРазмер поляNULLк_должностиbigintдолжностьтекстовый50даКлючи связиТип ключаСостав полейНазначениеПервичныйк_должностиСвязь с таблицей FТаблица данных F — следовательИмяТип данныхРазмер поляNULLк_следователяbigintФИОтекстовый50дадата_рождения dateдак_званияbigintдак_должностиbigintдаКлючи связиТип ключаСостав полейНазначениеПервичныйк_следователяСвязь с таблицей АВторичныйк_званияСвязь с таблицей DВторичныйк_должностиСвязь с таблицей E

Заключение эксперта-бухгалтера и оценка его следователем и судом

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

3. Создание базы данных и объектов базы данных

.1 Создание базы данных

Рис. 3.1.1 Внешний вид окна программы Microsoft SQL Server Management Studio Express

Создадим новую базу данных. Окно создания БД представлено на рис. 3.1.2.

Рис. 3.1.2 Окно создания БД

Рис. 3.1.3 Вид Management Studio с созданной базой данных

Создаем таблицы:

Рис. 3.1.4 Среда Management Studio в режиме создания таблицы

Чтобы определить отношения между таблицами, вам необходимо указать первичные ключи таблиц. (рис. 3.1.5).

Рис. 3.1.5 Задание первичного ключа (Remove Primary Key)

Создание таблиц

Таблицы

Моя База Данных содержит 6 таблиц:

ОВД

Уг_дела

Следователь

Звание

Должность

Решение

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

Таблица должность: содержит 2 поля и содержит информацию о должности следователей:

к_должности — номер должности. Поле является счетчиком.

Должность — название должности следователей

В режиме SQL запрос выглядит так:TOP 1000 [к_должности]

,[должность][уголовное_дело].[dbo].[должность]

Таблица звание: содержит 2 поля:

к_звания- номер звания. Поле является счетчиком.

звание — звание следователя

В режиме SQL запрос выглядит так:TOP 1000 [к_звания]

,[звание][уголовное_дело].[dbo].[звание]

Таблица ОВД: содержит 4 поля и краткую информацию о ОВД:

к_ОВД — номер кода ОВД. Поле является счетчиком.

ФИО_куратора — фамилия, имя, отчество куратора ОВД.

наименование — название ОВД

служба_ведущая_дело — служба_ведущая_дело

В режиме SQL запрос выглядит так: TOP 1000 [к_ОВД]

Режим труда и отдыха следователя

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

,[наименование_овд]

,[ФИО_куратора_ОВД]

,[служба_ведущая_дело][уголовное_дело].[dbo].[ОВД]

Таблица решение: содержит 4 поля:

к_решения — номер решения. Поле является счетчиком.

принятое_решение- принятое решение по УД

дата_принятия — дата принятия УД.

лицо_принявшее — лицо принявшее решение по УД.

В режиме SQL запрос выглядит так:TOP 1000 [к_решения]

,[принятое_решение]

,[дата_принятия]

,[лицо_принявшее_решение][уголовное_дело].[dbo].[решение]

Таблица следователь: содержит 5 полей и информацию о следователях:

к_следователя — номер следователя. Поле является счетчиком.

ФИО — фамилия, имя, отчество следователя

дата_рождения — дата рождения следователя.

к_звания — номер звания.

к_должности — номер должности

В режиме SQL запрос выглядит так:TOP 1000 [к_следователя]

,[ФИО]

,[дата_рождения]

,[к_звания]

,[к_должности][уголовное_дело].[dbo].[следователь]

Таблица уг_дела: содержит 9 полей и информацию о уголовном деле:

К_ОВД — номер ОВД

К_следователя — номер следователя.

Дата_начала — дата начала УД.

Дата_окончания — дата окончания УД.

квалификация — вид нарушения.

Кол_во_обвиняемых- Кол_во_обвиняемых.

Кол_во_эпизодов — Кол_во_эпизодов.

К_решения — номер решения

В режиме SQL запрос выглядит так:TOP 1000 [к_уг_дела]

,[к_ОВД]

,[к_следователя]

,[дата_начала]

,[дата_окончания]

,[квалификация]

,[кол_во_обвиняемых]

,[кол_во_эпизодов]

,[к_решения][уголовное_дело].[dbo].[уг_дело]

В этих таблицах мы видим уже имеющуюся в этих таблицах информацию для дальнейшей работы с базами данных в SQL Server.

Следователь в уголовном процессе

... исследования, Целью данной работы Концепция и полномочия следователя в уголовном процессе Концепция следователя как стороны уголовного обвинения Следователь При назначении следователя в качестве ... меры; Проведение следственных действий, санкционированных только постановлением суда. Указания, данные прокуратурой следователю по конкретному уголовному делу, также обязательны для начальника ...

.3 Создание связей

Вторичные ключи создаю через диаграмму. Для создания связей между таблицами и схемы базы данных необходимо создать новую диаграмму базы данных, выбрав соответствующий пункт в контекстном меню ветви «Диаграммы баз данных (Database Diagrams)». Добавив в появившемся окне необходимые таблицы в диаграмму, получаем следующий вид среды Management Studio (рис. 3.3.1.)

Рис. 3.3.1 Начало построения диаграммы БД

После создания остальных таблиц и их связей схема данных будет выглядеть следующим образом (рис. 3.3.2.).

.4 Создание запросов

Перейдем к созданию статических запросов и разберем один из примеров. В обозревателе объектов «Microsoft SQL Server Management Studio» все запросы БД находятся в папке «Views» (рис. 3.4.1.).

Рис. 3.4.1 Вид Management Studio с базой данных и имеющихся в них папок

Мы создаем запрос «Ранг + запрос сотрудника», связывая таблицы «Ранг», «Исследователь» и «Позиция» через поле ссылки «to _title».

Рис. 3.4.2 Окно созданных таблиц

Добавим в новый запрос таблицы «Звание» и «Следователь» и «Должность».

Появится окно конструктора запросов (рис. 3.4.3.).

Рис. 3.4.3 Окно выбранных таблиц в заданный запрос

Теперь перейдем к связыванию таблиц «Title», «Investigator» и «Position» через поля связывания c_title». Связь отобразится в виде ломаной линии соединяющей эти три поля связи (рис. 3.4.3.).

Определим отображаемые поля нашего запроса, как это показано на рис. 3.4.3. (Отображаем все поля кроме полей с кодами, то есть полей связи).

На этом настройку нового запроса можно считать законченной. Перед сохранением запроса проверим его работоспособность, выполнив его. Результат выполнения запроса появиться в виде таблицы в области результата (рис. 3.4.3.).

Рис. 3.4.4 Окно сохранение запроса

Запрос появится в папке «Views» БД «уголовное_дело» в обозревателе объектов (рис. 3.4.5.).

Рис. 3.4.5 Окно запроса » Запрос звание+сотрудник «

Давайте проверим функциональность запроса, созданного вне конструктора запросов. Мы запускаем только что созданный запрос «Ранг + зависимый запрос» без использования конструктора запросов.

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

В режиме SQL запрос выглядит так:

dbo.следователь.ФИО, dbo.должность.должность, dbo.звание.званиеdbo.должность INNER JOIN.следователь ON dbo.должность.к_должности = dbo.следователь.к_должности INNER JOIN.звание ON dbo.следователь.к_звания = dbo.звание.к_звания

Создание юридического лица (2)

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

или в режиме скрипта SQL запрос выглядит так (как показано на рис. 3.4.6.)

Рис. 3.4.6 Окно запроса » Запрос звание+сотрудник » через скрипт

QUOTED_IDENTIFIER ONVIEW [dbo].[звание+сотрудник]dbo.следователь.ФИО, dbo.должность.должность, dbo.звание.званиеdbo.должность INNER JOIN.следователь ON dbo.должность.к_должности = dbo.следователь.к_должности INNER JOIN.звание ON dbo.следователь.к_звания = dbo.звание.к_звания

.5 Создание фильтров

На основе запроса «Запрос на звание + сотрудник» мы создадим фильтры, отображающие следователей на основе установленного звания.

Рис. 3.5.1 Окно созданных представлений

Для создания фильтра необходимо установить критерии отбора записей. Пусть наш фильтр показывает только следователей в звании «капитан». В строке «звание», в столбце «Filter» задаю следующее условие отбора =’Капитан’. (рис. 3.5.2.).

Рис. 3.5.2 Окно выбранных представлений

Настроим сортировку записей в фильтре. После установки сортировки записей в фильтре проверим его работоспособность, выполнив его. Результат выполнения фильтра должен выглядеть как на рис. 3.5.2.

В режиме SQL запрос выглядит так: ФИО, должность, званиеdbo.[звание+сотрудник](звание = ‘Капитан’)

Рис. 3.5.3 Проверка работоспособности фильтра

В режиме скрипта SQL запрос выглядит так (как показано на рис. 3.5.4)

Рис. 3.5.4 Окно фильтра «фильтр_звание» через скрипт

QUOTED_IDENTIFIER ONVIEW [dbo].[фильтр_звания]ФИО, должность, званиеdbo.[звание+сотрудник](звание = ‘Капитан’)

.6 Создание триггеров

Создадим триггеры для таблицы «следователь». (рис. 3.6.1.).

Рис. 3.6.1 Вид создания триггеров

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

Появится следующее окно с новым триггером (рис. 3.6.2):

Рис. 3.6.2 Окно структуры триггера

В окне нового триггера наберём код как показано на рис. 3.6.3.

Рис. 3.6.3 Окно создания триггера в SQL запросе

Выполним набранный код.

В режиме скрипта SQL запрос выглядит так:

TRIGGER [dbo].[Индикатор добавлення в следователь][dbo].[следователь]INSERTNOCOUNT ON;’Запись добавлена’

.7 Создание пользовательских функций

Создадим «функцию отбора по возрасту» (рис. 3.7.1)

Рис. 3.7.1 Вид создания функций

Организация социального обслуживания граждан пожилого возраста

... К сожалению, с возрастом многие пожилые подопечные Хеседа страдают от ... социальной изоляции и невозможности воплощения своего творческого потенциала. Именно поэтому так важно не только обеспечить их материальные нужды, но и позаботиться об их духовных запросах. ... по силам. Услуги по данным программам предоставляются в ... несколько человек, помогающих организовать работу, кроме этого, доктору Лизе ...

В окне новой функции наберём код как показано на рис. 3.7.2.

Из рис. 3.7.1 видно, что создаваемая функция «Функция отбора по возрасту» выполняется после записи ввода всей записи представленной в данной окне.

Эта функция подсчитает, сколько лет следователь находится в базе данных «Criminal_case». Проверяю создалась ли функция.(рис. 3.7.3).

Рис. 3.7.3

Появится следующее окно. (рис. 3.7.4):

Рис. 3.7.4 dbo.Функция отбора по возрасту

В режиме скрипта SQL запрос выглядит так:

FUNCTION [dbo].[Функция отбора по возрасту]

— Add the parameters for the function here

)TABLE

(ФИО, [дата_рождения], Возраст = DateDiff(yy, [дата_рождения], GetDate()) FROM следователь

Просмотрим созданную функцию через запрос. (рис. 3.7.5)

Рис. 3.7.5 Окно созданных функций

Добавим запрос «функцию отбора по возрасту».

Появится окно конструктора запросов (рис. 3.7.6).

Рис. 3.7.6 Окно выбранной функции

Определим поля, отображаемые при выполнении запроса. Определим отображаемые поля нашего запроса, как это показано на рис. 3.7.6, отобразим поле «ФИО» и «Возраст».

Проверим запрос на работоспособность и сохраняем его. Результат выполнения запроса появиться в виде таблицы в области результата (рис. 3.7.7).

Запрос появится в папке «Views» БД «уголовное_дело» в обозревателе объектов (рис. 3.7.7).

Рис. 3.7.7 Проверка созданной функции

Давайте проверим функциональность запроса, созданного вне конструктора запросов. Результат представлен на рис. 3.7.7.

Данный запрос при выполнении дает информацию возраст следователю.

В режиме SQL запрос выглядит так:

TOP (100) PERCENT ФИО, Возрастdbo.[Функция отбора по возрасту]() AS [Функция отбора по возрасту_1]BY ФИО, Возраст DESC

В режиме скрипта SQL запрос выглядит так (как показано на рис. 3.7.8.)

Рис. 3.7.8 Окно функции «Function Возраст_следователя» через скрипт

ANSI_NULLS ONQUOTED_IDENTIFIER ONVIEW [dbo].[Возраст_следователя]TOP (100) PERCENT ФИО, Возрастdbo.[Функция отбора по возрасту]() AS [Функция отбора по возрасту_1]BY ФИО, Возраст DESC

.8 Создание ограничений

Создадим ограничение для таблицы «следователь» на ввод данных в таблицу. Ограничение на возраст следователя (нельзя ввести следователя, возраст которого меньше 18 лет и больше 80 лет).

Деятельность органов внутренних дел по выявлению, пресечению ...

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

Чтобы создать возрастное ограничение для следователя, оно должно быть создано с помощью триггера. (рис.3.8.1).

Рис. 3.8.1 Окно структуры триггера

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

В окне нового триггера набераю код как показано на рис. 3.8.2.

Рис. 3.8.2 Окно создания триггера в SQL запросе

Проверим работает ли данный триггер-ограничение. рис. 3.8.3.

Рис. 3.8.3 Данные в таблице «следователь»

И в после поля 9 вбиваем данные о следователе (рис. 3.8.4).

Рис. 3.8.4 Ошибка при вводе данных

После ввода данных в таблицу следователя Никифорчина С.Р.., где столбец «дата_рождения» вбито год рождение — 1900, и в данном случае следователю получается 112 лет, тем самым доказываю, что возраст следователь не подходит (рис. 3.8.5).

Рис. 3.8.5 Вывод об ошибке заполнения «возраст сотрудника не подходит»

В режиме скрипта SQL запрос выглядит так как показано на рис. 3.8.6

Рис. 3.8.6 Окно ограничения-триггера «TR_дата_рождения» через скрипт

TRIGGER [dbo].[TR_дата_рождения][dbo].[следователь] INSERTNOCOUNT ON;(select datediff(yy,дата_рождения,GETDATE()) from inserted)<18 or

(select datediff(yy,дата_рождения,GETDATE()) from inserted)>80’возраст сотрудника не подходит’

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

Основные разрешения для таблиц:

SELECT, INSERT, UPDATE, DELETE — выборка, добавление, корректировка, удаление строк;

ALTER — изменение свойств, в том числе структуры);

CONTROL — управление, аналогичное владению;

REFERENCES — ссылка из внешнего ключа;

TAKE OWNERSHIP — передача права владения;

VIEW DEFINITION — доступ к метаданным.

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

Стандартные роли базы данных. − автоматически назначается всем пользователям базы. Удалить нельзя. В основном позволяет выполнять просмотр. _owner − все действия с базой данных. _accessadmin − добавление пользователей и управление их доступом. _securityadmin − управление ролями сервера и правилами доступа к объектам базы данных. _ddladmin − добавление, изменение, удаление объектов базы данных. _backupoperator − резервирование базы данных. _datareader − просмотр любой информации из любой таблицы базы данных. _datawriter − добавление, изменение, удаление информации из любой таблицы базы данных. _denydatareader − модификация структуры базы данных без права чтения информации. _denydatawriterr − запрет модификаций в базе данных.

В табл.1 представлены роли для каждого из которых созданы свои права (привилегии).

Роли ТаблицыНачальник_ОВДСледовательСудьяОВДS, I, U, D.-−звание-S, U-должность-S, U−следователь-S, I, U, D.-Уг_делоSSS, I, U, D.решениеSSS, I, U, D.Табл. 1 Роли и права

Примечание: S — select, I — insert, U — update, D — delete.

Создания роли » Начальник_ОВД (рис. 3.9.2)

Рис. 3.9.2 Создание ролей

Ввод имя роли (рис. 3.9.3).

Рис. 3.9.3 Ввод имя роли

Затем переходим в раздел «Securables» (рис. 3.9.4)

Рис. 3.9.4 Окно раздела «Securables»

Открываем окно создания «Search» (рис. 3.9.5).

Рис. 3.9.5 Окно создания «Search»

Открывается окно «Specific objects» и в ней открываем поде «Object Types» и появляется окно со списками объектов как показано на рис. 3.9.6

Рис. 3.9.6 Окно со списками объектов

Ставим галочку на объекте «Tables» (рис. 3.9.7)

Рис. 3.9.7 Окно с выбранными списками объектов

После нажатия кнопки «ОК», появиться диалоговое окно, которое уже у нас встречалось и в этой окне выбираем поле «Browse»(рис. 3.9.8).

В появившемся диалоговом окне он нам выдает список объектов таблиц (рис. 3.9.9), которые существует в базе данных «уголовное_дело».

Рис. 3.9.9 Окно списка объектов таблиц

В данном окне (рис. 3.9.9) ставим галочки, как было указано в табл. 1 Появиться окно уже с заполненными данными (рис. 3.9.10) и дальше жмем «ОК».

Рис. 3.9.10 Окно объектов с таблицами

Рис. 3.9.11 Окно раздела «Securables» с таблицами

В диалоговом окне во вкладке Explict присваиваем права по табл.1

Рис. 3.9.11

Рис. 3.9.12 Список созданных ролей

Теперь перейдем к созданию пользователей, в данной табл.2 представлены пользователи и их роли в БД «уголовное_дело».

ПользовательСкоробогатовЕрёминШагировРольНачальник_ОВДСледовательСудьяТабл. 2

Создадим пользователя «Скоробогатов» с ролью «Начальник_ОВД (рис. 3.9.13)

Рис. 3.9.13 Раздел Security для работы с пользователями и создание нового пользователя

Рис. 3.9.14 Окно раздела «General»

Рис. 3.9.15 Настройка роли базы данных для нового пользователя (весь список ролей баз данных с их привилегиями ниже)

Рис. 3.9.16 Разблокирование создаваемой учетной записи

В режиме скрипта SQL-запрос выглядит так:

[master]LOGIN [Скоробогатов] WITH PASSWORD=N’\³_NÎ5ÇAVa“JõÐaÀ>ú_µÓBiÒä(iÏkX_’, DEFAULT_DATABASE=[уголовное_дело], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFFLOGIN [Скоробогатов] DISABLE

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

Для полнофункциональной работы ролей в SQL Servere зайдем в раздел «Службы» — рис. 3.9.17. и перезапустим «SQL Server (SQLEXPRESS)»,

Рис. 3.9.17 Окно службы

Проверяю работоспособность ролей (рис. 3.9.18)

Рис. 3.9.18 Окно «Object Explorer»

Рис. 3.9.19 Окно «Connect to server»

Рис. 3.9.20 Окно об запрете на изменение

Добавляя новые данные в табл.уг_дело выходит сообщение об ошибке, т.к. для данного пользователя мы устанавливали SELECT, следовательно приоритеты мы создали правильно.

4. Резервное копирование

Создаю скрипт и сохраняю в формате .sql (рис. 4.1):

DATABASE [уголовное_дело] TO DISK = N’c:\СУБД\Backup\дело.bak’ WITH NOFORMAT, NOINIT, NAME = N’уголовное_дело-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10

Рис. 4.1 Скрипт на создание резервного копирования

Этот скрипт сохраняется папке С:\СУБД\ под именем дело.sql. В этой же папке создадим пакетный файл backup, следующего содержания (рис. 4.2):

-S АЛЕКСЕЙ-HP\SQLEXPRESS -i C:\SYBD\копирование.sql

o C:\SYBD\report.txt

Рис. 4.2 Создания файла в формате .bat — в блокноте

Теперь можем запустить исполняемый файл файл.bat и проверить работает ли резервное копирование или нет, для этого нажатием двойным щелчком по ЛКМ мы должны увидеть, что в C:\SYBD\Backup\ создался файл дело.bak и создался файл отчет (рапорт) в папке C:\SYBD\ с именем report.txt (рис. 4.3)

Рис. 4.3 Окно содержания папки SYBD

На этом задача резервного копирования закончилась. Но для целостности и безопасности базы данных «РЕШЕНИЯ ПО УГОЛОВНОМУ ДЕЛАМ» мы будем создавать копию один раз в день в 03:30 через планировщик задач.

Рис. 4.4 Окно «Пуск»

Рис. 4.5 Планировщик заданий

Рис. 4.6 Окно «Действия»

В окне «Создать простую задачу» введем имя и ее описание (рис.4.7).

Рис. 4.7 Окно «Мастер создания простой задачи» — создать задачу

Рис. 4.8 Окно на создания триггера задачи

Рис. 4.9 Окно «Ежедневно» в триггере задач

Рис. 4.10 Окно «Действие»

Теперь наша исполняемая задача запущена, каждый день в 3:30 будет создаваться файл.bak.

Рис. 4.11 Окно «запуска программы» с указанием пути

Для проверки создания задачи, зайдем в библиотеку планировщика и найдем в окне наш файл под именем «Создание копии БД уголовное дело», и как мы видим на рис. 4.12 данная задача создана. Таким образом, нам не нужно беспокоиться о целостности и безопасности базы данных, поскольку в дополнение к нашему настраиваемому сохранению базы данных «Учет решений по уголовным делам» в основной папке SQL Server Management Studio, резервная копия, созданная через планировщик будет создан автоматически.

Рис. 4.12 Окно «планировщика заданий» с созданной задачей

Заключение

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

Тестирование разработанной информационной системы показало, что она работает корректно и готова к использованию.

Сегодня автоматизированная обработка информации распространяется практически на все сферы бизнеса.

Список использованной литературы

[Электронный ресурс]//URL: https://urveda.ru/kursovaya/sistema-edinogo-ucheta-prestupleniy/

1.В.В. Фаронов C 6: Учебный Курс, Москва, Knowledge, 2011

.М.В. Сухарев Основы C#, издательство Наука и техника, 2009

.Г.В. Галисеев, Компоненты в Delphi 6: профессиональная работа, издательство Диалектика, 2004

.В.И. Ключко Методическое указание к выполнению курсовой работы, Краснодар, Издательство КубГТУ, 2010

.М.П. Малыхина Базы данных: основы, проектирование, использование

.Т.М. Карпова Базы данных: модели, разработка, реализация, издательство Питер, 2009

.Кандзюба С. П. Delphi 6/7. Базы данных и приложения. Лекции и упражнения. — СПб.: ООО «ДиаСофтЮП», 2002. — 576.