Современные методы защиты информации в СУБД Microsoft Access

1.2 Отражение бизнес-процессов в BPwin

Отразим действующие процессы документооборота в организации с использованием средств BPwin. Для отражениея этих процессов используем модель AS-IS (Приложение А).

 

ПРОЦЕСС: Регистрация документа.

ВХОД: Входящий документ.

ВЫХОД: Зарегистрированный входящий документ.

АЛГОРИТМ: Зарегистрировать поступивший входящий документ, присвоив ему уникальный номер, в соответствии с Инструкцией по делопроизводству и внутренним Порядком документооборота.

 

ПРОЦЕСС: Обработка документа.

ВХОД: Зарегистрированный входящий документ.

ВЫХОД: Исполненный входящий документ, исходящий ответный документ.

АЛГОРИТМ: Исполнить поступивший документ и, если требуется, подготовить и  отправить ответный исходящий документ.

ПОДПРОЦЕССЫ:

Вынесение резолюций.

Постановка  на контроль.

Исполнение  документа.

Снятие  с контроля.

 

ПРОЦЕСС: Списание в дело.

ВХОД: Исполненный входящий документ.

ВЫХОД: Списанный документ.

АЛГОРИТМ: Подшить обработанный документ в  дело с соответствующей номенклатурой.

 

ПРОЦЕСС: Формирование отчетов.

ВХОД: Списанный документ, исходящий ответный документ.

ВЫХОД: Реестр зарегистрированных входящих/ исходящих документов, Реестр документов, переданных на исполнение, Сводка об исполнении документов.

АЛГОРИТМ: Ручное формирование необходимых отчетов.

ПОДПРОЦЕССЫ:

Поиск форм отчетов.

Ручное  заполнение форм отчетов.

Печать  отчетов.

Эта модель показывает, как функционирует  документооборот в организации, когда процессы не автоматизированы.

После внедрения проектируемой информационной системы, организация документооборота будет представлена в виде модели TO-BE (Приложение Б).

ПРОЦЕСС: Автоматизированное рабочее место  «Делопроизводство».

ВХОД: Входящие документы.

ВЫХОД: Автоматизированные отчеты.

ПОДПРОЦЕССЫ:

АРМ «Делопроизводство: работа с документами».

АРМ «Делопроизводство: отчетность».

 

ПРОЦЕСС: АРМ «Делопроизводство: работа с документами».

ВХОД: Входящие документы.

ВЫХОД: Исполненные документы, исходящие  ответные документы.

АЛГОРИТМ: Автоматизированный учет документов и  контроль за их исполнением.

ПОДПРОЦЕССЫ:

Регистрация в АРМ «Делопроизводство».

Рассмотрение документа.

Исполнение  документа.

 

ПРОЦЕСС: АРМ «Делопроизводство: отчетность».

ВХОД: Исполненные документы, исходящие  ответные документы.

ВЫХОД: Автоматизированные отчеты.

АЛГОРИТМ: Автоматизирование формирование отчетов  и вывод их на бумажные носители.

ПОДПРОЦЕССЫ:

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

Вывод отчетов.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 Проектирование АРМ «Делопроизводство»

2.1 Концепция  СУБД Microsoft Access

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

Любая СУБД позволяет выполнять  четыре простейшие операции с данными:

• добавить в таблицу одну или несколько записей;

• удалить из таблицы одну или несколько записей;

• обновить значения некоторых полей в одной или нескольких записях;
• найти одну или несколько записей, удовлетворяющих заданному условию.

Для выполнения этих операций используется механизм запросов. Результатом выполнения запросов является либо отобранное по определённым критериям множество записей, либо изменение в таблицах.

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

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

При проектировании таблиц лучше разработать структуру на бумаге и только затем начинать работу с СУБД Access. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:

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

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

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

- Каждое поле должно быть связано с темой таблицы;

- Не рекомендуется  включать в таблицу данные, которые  являются результатом выражения;

- В таблице должна присутствовать вся необходимая информация;

- Информацию следует разбивать  на наименьшие логические единицы.

 

 

 

 

2.2 Нормализация  отношений

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

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

Устранение  избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).

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

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

 

 

 

Регистрационный номер входящего документа

Регистрационная дата входящего документа

Исходящий номер  входящего документа

Исходящая дата входящего документа

Вид документа

Корреспондент, направивший документ

Адрес корреспондента

Телефон корреспондента

Содержание входящего документа

Вид доставки входящего  документа

Текст резолюции

Ответственный исполнитель

Срок исполнения

Отметка об исполнении

Дата исполнения

Регистрационный номер исходящего документа

Регистрационная дата исходящего документа

Автор исходящего документа

Вид исходящего документа

Вид доставки исходящего документа

Содержание  исходящего документа

Получатель  исходящего документа

 

 

Полученная таблица с атрибутами в соответствии с определением находится в первой в нормальной форме.

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

Таблица находится  во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный  ключ, связаны полной функциональной зависимостью с первичным ключом.

Сгруппируем атрибуты, выделив из них первичных ключ (*), в соответствии с определением.

 

 

Входящие документы

Регистрационный номер *

Регистрационная дата

Исходящий номер

Исходящая дата

Код вида документа

Код корреспондента

Содержание документа

Код вида доставки

Текст резолюции

Табельный номер  сотрудника

Срок исполнения

Отметка об исполнении

Дата исполнения

 

Исходящие документы

Регистрационный номер *

Регистрационная дата

Табельный номер  сотрудника

Код вида документа

Код вида доставки

Содержание  исходящего документа

Код корреспондента

Создадим справочники  для таблиц Входящие документы и  Исходящие документы:

Виды документов

Код вида документа *

Вид документа

 

Виды доставки

Код вида доставки *

Вид доставки

Корреспонденты

Код корреспондента *

Наименование  корреспондента

Адрес

Телефон

Сотрудники

Табельный номер *

ФИО

Код подразделения

Код должности

Для таблицы  Сотрудники создадим два справочника:

Подразделения

Код подразделения *

Наименование  подразделения

Должности

Код должности*

Наименование  должности

Таблица находится  в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и не одно из ее неключевых полей  не зависит функционально от любого другого неключевого поля.

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

Построим информационно  логическую модель данных.

Рисунок 1 - Инфологическая модель данных

 

2.3 Построение базы данных

 

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

На первом этапе  определим пользователей системы:

а) администратор  системы – имеет неограниченный доступ к системе. Отслеживает неполадки  системы, устраняет лишние метаданные и добавляет новые.

б) делопроизводитель (или пользователь) – специалист службы ДОУ. Осуществляет непосредственное пользование системой.

На втором этапе  опишем реализацию системы.

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

Рисунок 2 –  Схема данных

 

 

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