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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

КУРСОВАЯ РАБОТА

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

Содержание

Введение

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

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

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

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

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

2.2 Даталогическая модель базы данных

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

3.1 Создание базы данных

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

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

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

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

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

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

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

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

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

Заключение

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

Введение

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

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

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

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

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

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

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

--Резервное копирование

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

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

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

Предметная область, часть которой представлена в этой программе - реализация и функционирование информационной системы «Учёт решений по уголовным делам». Это обширная и часто используемая в современном мире задача, требующая точности исполнения. Описываются среда функционирования, объект и субъект управления, цели и задачи управления.

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

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

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

Цель управления состоит в раскрытии уголовных дел следователями и принятием решения.

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

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

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

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

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

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

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

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

1) ОВД;

2) Должность;

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

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

5) Решение.

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

Объект	Атрибут	Описание атрибута
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 Нормализация

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

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

2 НФ:

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

3 НФ:

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

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

Даталогическая модель в 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. Создание базы данных и объектов базы данных

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 запрос выглядит так:

SELECT TOP 1000 [к_должности]

,[должность]

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

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

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

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

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

SELECT TOP 1000 [к_звания]

,[звание]

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

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

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

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

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

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

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

SELECT TOP 1000 [к_ОВД]

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

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

,[служба_ведущая_дело]

FROM [уголовное_дело].[dbo].[ОВД]

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

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

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

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

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

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

SELECT TOP 1000 [к_решения]

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

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

,[лицо_принявшее_решение]

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

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

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

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

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

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

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

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

SELECT TOP 1000 [к_следователя]

,[ФИО]

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

,[к_звания]

,[к_должности]

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

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

К_уг_дела - номер (код) уг дела. Поле является счетчиком.

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

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

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

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

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

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

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

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

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

SELECT TOP 1000 [к_уг_дела]

,[к_ОВД]

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

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

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

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

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

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

,[к_решения]

FROM [уголовное_дело].[dbo].[уг_дело]

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

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

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

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

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

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

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

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

Создадим запрос "Запрос звание+сотрудник ", связывающий таблицы "Звание" и "Следователь" и "Должность" по полю связи "к _звания".

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

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

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

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

Теперь перейдем к связыванию таблиц "Звание" и "Следователь" и "Должность" по полям связи "к_звания". Связь отобразится в виде ломаной линии соединяющей эти три поля связи (рис. 3.4.3.).

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

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

Запрос выполнился правильно. Сохраняем его.

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

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

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

Проверим работоспособность созданного запроса вне конструктора запросов. Запустим вновь созданный запрос " Запрос звание+сотрудник " без использования конструктора запросов.

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

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

SELECT dbo.следователь.ФИО, dbo.должность.должность, dbo.звание.звание

FROM dbo.должность INNER JOIN

dbo.следователь ON dbo.должность.к_должности = dbo.следователь.к_должности INNER JOIN

dbo.звание ON dbo.следователь.к_звания = dbo.звание.к_звания

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

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

SET QUOTED_IDENTIFIER ON

GO

CREATE VIEW [dbo].[звание+сотрудник]

AS

SELECT dbo.следователь.ФИО, dbo.должность.должность, dbo.звание.звание

FROM dbo.должность INNER JOIN

dbo.следователь ON dbo.должность.к_должности = dbo.следователь.к_должности INNER JOIN

dbo.звание ON dbo.следователь.к_звания = dbo.звание.к_звания

GO

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

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

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

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

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

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

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

SELECT ФИО, должность, звание

FROM dbo.[звание+сотрудник]

WHERE (звание = 'Капитан')

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

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

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

SET QUOTED_IDENTIFIER ON

GO

CREATE VIEW [dbo].[фильтр_звания]

AS

SELECT ФИО, должность, звание

FROM dbo.[звание+сотрудник]

WHERE (звание = 'Капитан')

GO

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

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

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

Создадим триггер, выводящий сообщение "запись добавлена" при добавлении записи в таблицу "следователь". Создадим новый триггер.

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

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

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

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

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

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

CREATE TRIGGER [dbo].[Индикатор добавлення в следователь]

ON [dbo].[следователь]

AFTER INSERT

AS

BEGIN

SET NOCOUNT ON;

PRINT 'Запись добавлена'

END

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

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

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

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

Рис. 3.7.2 Окно создания функций в SQL запросе

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

Данная функция будет считать сколько лет следователю, находящемся в базе данных «уголовное_дело». Проверяю создалась ли функция.(рис. 3.7.3).

Рис. 3.7.3

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

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

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

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

(

-- Add the parameters for the function here

)

RETURNS TABLE

AS

RETURN

(

SELECT ФИО, [дата_рождения], Возраст = 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 запрос выглядит так:

SELECT TOP (100) PERCENT ФИО, Возраст

FROM dbo.[Функция отбора по возрасту]() AS [Функция отбора по возрасту_1]

ORDER BY ФИО, Возраст DESC

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

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

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE VIEW [dbo].[Возраст_следователя]

AS

SELECT TOP (100) PERCENT ФИО, Возраст

FROM dbo.[Функция отбора по возрасту]() AS [Функция отбора по возрасту_1]

ORDER BY ФИО, Возраст DESC

GO

3.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_дата_рождения" через скрипт

CREATE TRIGGER [dbo].[TR_дата_рождения]

ON [dbo].[следователь]

for INSERT

AS

BEGIN

SET NOCOUNT ON;

If (select datediff(yy,дата_рождения,GETDATE()) from inserted)<18 or

(select datediff(yy,дата_рождения,GETDATE()) from inserted)>80

begin

print 'возраст сотрудника не подходит'

rollback

end

GO

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

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

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

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

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

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

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

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

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

Стандартные роли базы данных.

Public ? автоматически назначается всем пользователям базы. Удалить нельзя. В основном позволяет выполнять просмотр.

Db_owner ? все действия с базой данных.

Db_accessadmin ? добавление пользователей и управление их доступом.

Db_securityadmin ? управление ролями сервера и правилами доступа к объектам базы данных.

Db_ddladmin ? добавление, изменение, удаление объектов базы данных.

Db_backupoperator ? резервирование базы данных.

Db_datareader ? просмотр любой информации из любой таблицы базы данных.

Db_datawriter ? добавление, изменение, удаление информации из любой таблицы базы данных.

Db_denydatareader ? модификация структуры базы данных без права чтения информации.

Db_denydatawriterr ? запрет модификаций в базе данных.

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

Роли Таблицы	Начальник_ОВД	Следователь	Судья
ОВД	S, I, U, D.	-	?
звание	-	S, U	-
должность	-	S, U	?
следователь	-	S, I, U, D.	-
Уг_дело	S	S	S, I, U, D.
решение	S	S	S, 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.8 Окно объектов

Рис. 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-запрос выглядит так:

USE [master]

GO

CREATE LOGIN [Скоробогатов] WITH PASSWORD=N'\?_NI5CAVa“Jo?aA>u_µOBiOa(iIkX_', DEFAULT_DATABASE=[уголовное_дело], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

ALTER LOGIN [Скоробогатов] DISABLE

GO

Также создаем остальные пользователи и присваиваем им свои роли, как показано в табл. 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):

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

GO

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

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

sqlcmd -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”

На этом задача резервного копирования закончилась. Но для целостности и сохранности БД " УЧЕТ РЕШЕНИЙ ПО УГОЛОВНЫМ ДЕЛАМ" создадим копирование 1 раз в день в 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 Окно «планировщика заданий» с созданной задачей

Заключение

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

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

На сегодняшний день автоматизированная обработка информации распространяется практически на все сферы деятельности.

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

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

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

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

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

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

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

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

Размещено на Allbest.ru