Файл: Проектирование бизнес процесса расчет заработной платы.pdf

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

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

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

1) Входные и выходные документы. Входными документами системы является приходная накладная и накладная на внутреннее перемещение.

Выходными документами являются: журнал прихода, журнал отгрузок, отчет по качеству, отчет по остаткам, отчет по инвентаризации, отчет «Резервы отделов КЦ».

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

2) Экранные формы

Для построения диалога с пользователем возможны следующие способы: диалог типа «Вопрос-ответ»; диалог типа «Меню», диалог на основе экранных форм, диалог на основе командного языка.

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

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

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

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

4) Информационная база. Центральным компонентом информационного обеспечения является информационная база (ИБА), представляющая собой организованную определенным способом совокупность данных, хранимых в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. [1]

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

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

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

Основными способами организации БД являются создание централизованных и распределенных БД. [4] В рассматриваемой задаче не предполагается распределенная структура ИС, т.к. задача небольшая по объему данных и по количеству пользователей.

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

Обоснование проектных решений по программному обеспечению

Оптимальным будет выбор сделанный в пользу Microsoft Access, поскольку он обладает рядом преимуществ по сравнению с другими СУБД, а именно: удобство использования и одновременно мощность продукта — в сочетании с возможностью построения комплексных решений на базе современных технологий; совместим с большинством приложений работающих из под Windows; не требует установки драйверов доступа к данным в этом формате, так как они поставляются с операционными системами Windows.

ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ

Информационная модель и её описание

Графическое представление информационной модели отражено на рис. 2.1.

Рисунок 2.1 – Информационная модель системы

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

База данных должна содержать информацию следующего вида:

А: Служебная информация:

1. Табельный номер;
2. Фамилия Имя Отчество;
3. Наименование должности;
4. Отдел;
5. Вид оплаты труда;
6. Номер разрядаю.

Б: Личная информация:

1. Фамилия Имя Отчество;
2. Адрес;
3. Домашний телефон;
4. Мобильный телефон;
5. Дата рождения.

В: Сведения о детях сотрудника:

1. Фамилия Имя Отчество;
2. Фамилия Имя Отчество детей;
3. Дата рождения;
4. Место проживания.

Г: Расценок:

1. Вид оплаты труда;
2. Номер разряда;
3. Расценок.

Д: Процент премии:

1. Номер разряда
2. Процент премии

Характеристика результатной информации

Запросы базы данных:

1. Запрос на выборку с условием отбора: работники по заданному разряду;
2. Запрос на выборку с группировкой: средняя заработная плата по должностям ;
3. Запрос на выборку с расчетом: расчет премии по окладникам;
4. Запрос на выборку с расчетом: расчет премии по сдельщикам;
5. Запрос на выборку с расчетом: зарплата по окладникам;
6. Запрос на выборку с расчетом: зарплата по сдельщикам;
7. Запрос на обновление: повышение тарифов;
8. Запрос на удаление: увольнение;
9. Запрос на добавление: прием на работу нового работника;
10. Запрос на создание таблицы: дни рождения сотрудников;
11. Перекрестный запрос: суммы окладов по должностям.

Общие положения (дерево функций и сценарий диалога)

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

Рисунок 2.2 - Дерево функций системы сотрудника

Сценарии диалога, формирующийся на основе дерева функций, приведен на рисунке 2.3.

Рисунок 2.3 - Сценарий диалога для пользователя

Характеристика базы данных

На основании собранных исходных можем построить ER-диаграмму (см. рисунок 2.4).

Рисунок 2.4 - ER-диаграмма

1. Работники – имеют – личную информацию.

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

Класс принадлежности между сущностями РАБОТНИКИ и ЛИЧНАЯ ИНФОРМАЦИЯ обязательный потому, что каждому работнику соответствует своя индивидуальная информация.

2. Личная информация – включает – сведения о детях.

- Степень связи здесь 1:n.

Класс принадлежности: необязательный для ЛИЧНОЙ ИНФОРМАЦИИ и обязательный для СВЕДЕНИЙ О ДЕТЯХ (т.е. не каждый работник может иметь детей).

3.Работники – имеют - расценок.

- степень связи n:1, потому что много сотрудников может иметь один и тот же оклад (или тарифную ставку);

Класс принадлежности обязательный для РАБОТНИКОВ и необязательный для РАСЦЕНКА.

4. Расценок – включает – процент премии

- степень связи 1:1, потому что каждый оклад, который соответствует определенному разряду, может иметь только один определенный процент премии соответственно по тому же разряду;

Класс принадлежности сущности РАСЦЕНОК и ПРОЦЕНТ ПРЕМИИ необязательный.

Имена и содержание ключевых атрибутов сводятся в одну таблицу (см. табл. 2.1).

Таблица 2.1 - Имена и содержание ключевых атрибутов

Построение предварительных отношений

Для БД формируются следующие предварительные отношения (см. Таблицу 2.2).

Таблица 2.2 - Таблица предварительных отношений

Правила нормализации отношений

Если отношение находится в нормальной форме, то снимаются многие проблемы хранения и обработки данных. Разрабатываемые методы проектирования применимы к определенным нормальным формам.

Существует уже более 15 нормальных форм, но продолжается поиск новых. В пособии будут рассмотрены первые три нормальных формы и нормальная форма Бойса-Кодда.

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

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

Напомним кратко свойства отношений (это и будут свойства 1НФ):

В отношении нет одинаковых кортежей.

Кортежи не упорядочены.

Атрибуты не упорядочены и различаются по наименованию.

Все значения атрибутов атомарны.

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