:
) ОВД;
) Должность;
) Следователь;
) Уголовное дело;
) Решение.
Первичное описание информационного обеспечения (исходные данные)
ОбъектАтрибутОписание атрибута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НФ, и каждый не ключевой атрибут функционально полно зависит от составного первичного ключа.
НФ:
Все неключевые атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.
Таким образом, база данных удовлетворяет всем требованиям нормализации таблиц и третья нормальная форма - окончательный результат нормализации моей Базы данных.
Даталогическая модель в 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 с базой данных и имеющихся в них папок
Создадим запрос "Запрос звание+сотрудник ", связывающий таблицы "Звание" и "Следователь" и "Должность" по полю связи "к _звания".
Рис. 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 запрос выглядит так:
dbo.следователь.ФИО, dbo.должность.должность, dbo.звание.званиеdbo.должность INNER JOIN.следователь ON dbo.должность.к_должности = dbo.следователь.к_должности INNER JOIN.звание ON dbo.следователь.к_звания = dbo.звание.к_звания
или в режиме скрипта 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 видно, что создаваемая функция "Функция отбора по возрасту" выполняется после записи ввода всей записи представленной в данной окне.
Данная функция будет считать сколько лет следователю, находящемся в базе данных «уголовное_дело». Проверяю создалась ли функция.(рис. 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ÇAVaJõÐ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
На этом задача резервного копирования закончилась. Но для целостности и сохранности БД " УЧЕТ РЕШЕНИЙ ПО УГОЛОВНЫМ ДЕЛАМ" создадим копирование 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
.М.В. Сухарев Основы C#, издательство Наука и техника, 2009
.Г.В. Галисеев, Компоненты в Delphi 6: профессиональная работа, издательство Диалектика, 2004
.В.И. Ключко Методическое указание к выполнению курсовой работы, Краснодар, Издательство КубГТУ, 2010
.М.П. Малыхина Базы данных: основы, проектирование, использование
.Т.М. Карпова Базы данных: модели, разработка, реализация, издательство Питер, 2009
.Кандзюба С. П. Delphi 6/7. Базы данных и приложения. Лекции и упражнения. - СПб.: ООО «ДиаСофтЮП», 2002. - 576.