Файл: Автоматизация учета кадров ООО Дальлесстрой.pdf

2. разработать программное обеспечение на основе разработанного алгоритма;

3. провести тестирование разработанного алгоритма.

В основе формирования личностных данных сотрудника использует так называемые справочники.

Справочники – таблицы БД, содержащие статические данные (Области, города, улицы).

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

В таблице 1, приведены все данные которые должны хранится в «личной карточке» сотрудника.

Таблица 2

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

В основном, в БД используется связь 1:1(один-к-одному), так называемая идентифицирующая связь, также используется связь 1:М(один-ко-многим), связь М:М(многие-ко-многим) не используется.

Проведя анализ данных и самой БД, можно выделить функции которые должен выполнять конвертор:

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

2.2. Используемые классификаторы и системы кодирования

Использование модулей при разработке алгоритма дает следующие преимущества:

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

Однако у такой структуры есть и ряд недостатков:

• сложно связать все модули в единую систему;
• требования к ресурсам системы возрастают.

В результате анализа задач, били разработаны следующие модули:

1. модуль подключения к БД;
2. модуль копирования данных в БД;
3. модуль поиска соответствий обрабатываемых данных в БД;
4. модуль записи результатов в БД;
5. модуль формирования отчетов;
6. модуль удаления БД.

На рисунке 4. приведена схема потока данных при работе конвертора БД.

Рисунок 4 - Схема потока данных при работе конвертора БД.

Разработка алгоритма конвертора БД

Весь алгоритм конвертора состоит из девяти частей (модулей). Основными модулями являются:

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

На рисунке 5. приведена обобщенная блок-схема алгоритма модуля предварительной обработки данных.

Рисунок 5. блок-схема алгоритма модуля предварительной обработки данных.

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

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

, (1)

где N_оп – количество выполненных операций алгоритмом;

m – количество операций выполняемых циклом;

n – количество операций выполняемых в блоке сравнения.

2.3. Характеристика нормативно-справочной, входной и оперативной информации

Рассмотрим последовательность действий, шагов, которые необходимо выполнить при проектировании БД.

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

- сможет ли новая система объединить существующие приложения;

- какие данные используются разными приложениями;

- кто будет вводить данные в базу и в какой форме;

- достаточно ли будет для Вашей предметной области одной базы;

- какая информация является наиболее чувствительной к скорости ее извлечения и изменения.

II. Следующий шаг включает в себя анализ объектов реального мира, которые необходимо смоделировать в базе данных. Формирование концептуальной модели базы данных включает в себя:

- идентификацию функциональной деятельности Вашей предметной области;

- идентификацию объектов, которые осуществляют эту функциональную деятельность.

- идентификацию характеристик этих сущностей.

- идентификацию взаимосвязей между сущностями.

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

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

V. Пятый шаг предполагает выработку правил, которые будут устанавливать и поддерживать целостность данных. Будучи определенными, такие правила в клиент-серверных СУБД поддерживаются автоматически - сервером баз данных; в локальных же СУБД их поддержание приходится возлагать на пользовательское приложение. Эти правила включают:

- определение типа данных;

- выбор набора символов, соответствующего данной стране;

- создание полей, опирающихся на домены;

- установка значений по умолчанию;

- определение ограничений целостности;

- определение проверочных условий.

VI. На шестом шаге устанавливаются связи между объектами (таблицами и столбцами) и производится очень важная операция для исключения избыточности данных - нормализация таблиц.

Каждый из различных типов связей должен быть смоделирован в базе данных. Существует несколько типов связей:

• связь "один-к-одному";
• связь "один-ко-многим";
• связь "многие-ко-многим".

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

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

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

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

После применения правил нормализации логические группы данных располагаются не более чем в одной таблице. Это дает следующие преимущества:

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

Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ). С практической точки зрения, достаточно трех первых форм - следует учитывать время, необходимое системе для "соединения" таблиц при отображении их на экране. Поэтому мы ограничимся изучением процесса приведения отношений к первым трем формам. Этот процесс включает:

• устранение повторяющихся групп (приведение к 1НФ);
• удаление частично зависимых атрибутов (приведение к 2НФ);
• удаление транзитивно зависимых атрибутов (приведение к 3НФ).

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

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

В качестве примера, была разработана Структура проектируемой БД кадрового учета рисунок 6.

В таблице 2. приведены данные, которые будут храниться в проектируемой БД.

Таблица 3. – Данные, хранимые в проектируемой БД