Расчет заработной платы в поликлинике

Содержание

 

 

Введение

 

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

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

 

 

Постановка задачи

 

Цель разработки:

1. Спроектировать логическую структуру базы данных, позволяющей решать типовые задачи учета заработной платы в поликлинике.
2. Выбрать программную платформу для физической реализации проекта БД.
3. Реализовать БД в виде сценария на языке описания данных выбранной в пункте 2 серверной платформе.
4. Разработать основные процедуры администрирования БД.
5. Предложить типовые запросы к БД на языке запросов выбранной серверной платформе.
6. Разработать процедуры оценки качества разработанной БД.

 

1. Проектирование структуры базы данных

 

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

Основные этапы жизненного цикла ПС:

1. Планирование разработки БД. Планирование наиболее эффективного способа реализации этапов жизненного цикла системы.

2. Определение требований  к системе. Определение диапазона действий и границ приложения БД, состава его пользователей и областей применения.

3. Сбор и анализ  требований пользователей. Сбор и анализ требований из всех возможных областей применения.

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

5. Выбор целевой СУБД.

Следующие этапы жизненного цикла системы выходят за рамки  проектирования БД:

 

6. Разработка приложений.

7. Создание прототипов.

8. Реализация.

9. Преобразование и  загрузка данных.

10. Тестирование.

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

 

 

1.1. Техническое задание

 

Основанием для начала проектирования служит техническое задание (ТЗ).

ТЗ для задачи проектирования БД учета  заработной платы в поликлинике оформляется согласно ГОСТ 19.201-78.

1. Введение.

Наименование разработки: База данных по учету заработной платы в поликлинике.

Область применения: бухгалтерия.

2. Основания для разработки: Приказ руководства поликлиники

3. Назначение разработки: база данных для использования в комплексе бухгалтерских программ поликлиники.

4. Требования к программе.

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

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

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

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

По информационной и  программной совместимости: функционирование на базе операционной системы Microsoft Windows Server 2003.

По защите информации: соответствие уровню безопасности С2.

5. Требования к программной документации.

Документация согласно РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

6. Технико-экономические  показатели

7. Стадии и этапы  разработки

8. Порядок контроля  и приемки

 

 

 

1.2. Концептуальное проектирование

 

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

Этапы разработки концептуальной модели:

 

1. Определение типов сущностей

Таблица 1. Сущности

Сущность (Entity)	Описание
Worker	Работник, получающий зарплату в поликлинике
Phase	Фаза изменения работника
Work	Некоторая работа, за которую  работник получает некоторую зарплату
Job	Должность
Tariff	Тариф, по которому ведется  оплата
Ratio	Разряд
Division	Подразделение поликлиники
Charge	Вид начисления
Hold	Вид удержания
Calc	Расчет зарплаты конкретному  работнику за конкретный месяц
Charging	Начисление по расчету
Holding	Удержание по расчету

 

2. Определение типов связей

Таблица 2. Связи

Связь (Relation)	Описание
WorkerPhase	Данные работника изменяются с течением времени
DivisionPhase	Работник числится в  конкретном подразделении поликлиники
JobPhase	Работник числится на конкретной должности
RatioPhase	Работник имеет конкретный разряд
RatioTariff	Тариф изменяется в зависимости  от разряда
ChargePhase	Работник получает конкретные виды начислений
HoldPhase	Работник имеет конкретные виды удержаний с зарплаты
PhaseWork	Работник выполнил конкретные работы
PhaseCalc	Работнику произведен расчет зарплаты на конкретный месяц
CalcCharging	Начисление по расчету  зарплаты
CalcHolding	Удержание по расчету  зарплаты
ChargeCharging	Начисление произведено  по конкретному виду начислений
HoldHolding	Удержание произведено  по конкретному виду удержаний
ChargeWork	Начисление произведено  по конкретной работе

 

Для большей наглядности  и удобства представления следует использовать ER-диаграмму.

 

 

Рисунок 1. Диаграмма Entity-Relation (Сущность-связь)

 

3. Определение  атрибутов и связывание их с типами сущностей и связей

Таблица 3. Атрибуты

Сущность	Атрибут	Описание	Тип данных	Пустые значения
Worker	WorkerId	Идентификатор работника	Целое	Нет
	DOB	Дата рождения	Дата	Нет
	Sex	Пол	Символ	Нет
Phase	PhaseId	Идентификатор фазы	Целое	Нет
	Surname	Фамилия	Строка	Нет
	Name	Имя	Строка	Нет
	Patronymic	Отчество	Строка	Да
	Tabel	Табельный номер	Целое	Нет
	Child	Количество детей	Целое	Да
Work	WorkId	Идентификатор работы	Целое	Нет
	Start	Время начала работы	Время	Нет
	Duration	Продолжительность работы	Число	Нет
	Rate	Коэффициент пересчета	Число	Нет
Job	JobId	Идентификатор должности	Целое	Нет
	Name	Наименование должности	Строка	Да
Tariff	TariffId	Идентификатор тарифа	Целое	Нет
	Rate	Тарифный коэффициент	Число	Нет
	TariffYear	Год действия тарифной сетки	Целое	Нет
Ratio	RatioId	Номер разряда	Целое	Нет
Division	DivId	Идентификатор подразделения	Целое	Нет
	Name	Наименование подразделения	Строка	Да
Charge	ChargeId	Идентификатор вида начисления	Целое	Нет
	Name	Наименование вида начисления	Строка	Да
Hold	HoldId	Идентификатор вида удержания	Целое	Нет
	Name	Наименование вида удержания	Строка	Да
	Percent	Процент удержания	Число	Нет
	LimitUp	Верхний предел	Денежное	Да
	LimitDown	Нижний предел	Денежное	Да
Calc	CalcId	Идентификатор расчета	Целое	Нет
	CalcMonth	Месяц на который выполнен расчет	Целое	Нет
	CalcYear	Год расчета	Целое	Нет
Charging	ChargingId	Идентификатор начисления	Целое	Нет
	Summa	Сумма начисления	Денежное	Нет
Holding	HoldingId	Идентификатор удержания	Целое	Нет
	Summa	Сумма удержания	Денежное	Нет

 

 

 

 

4. Определение атрибутов, являющихся потенциальными и первичными ключами.

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

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

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

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

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

В нашей модели альтернативных первичных ключей не выявлено.

 

5. Проверка модели на отсутствие избыточности.

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

1. Повторное исследование связей «один к одному»

2. Удаление избыточных связей.

В нашей модели избыточности данных не выявлено.

6. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

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

Например: Проверим соответствие модели транзакции расчета зарплаты конкретному работнику на конкретный месяц по тарифному окладу:

Работник – Worker

Текущие данные по работнику – Phase по связке WorkerPhase

Значение разряда – Ratio по связке RatioPhase

Значения тарифа – Tariff по связке RatioTariff

Работы, выполненные работником в заданном месяце – Work по связке PhaseWork.

Транзакцию можно также  отобразить на ER-диаграмме модели БД:

Рисунок 2. Проверка транзакции с помощью пути выполнения

 

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

 

1.3. Логическое проектирование

 

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

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

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

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

Реляционная модель ориентирована  на организацию данных в виде двумерных  таблиц. Каждая реляционная таблица  представляет собой двумерный массив и обладает следующими свойствами:

1. каждый элемент таблицы - один элемент данных

2. все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)

3. каждый столбец имеет уникальное имя

4. одинаковые строки в таблице отсутствуют

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

 

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

1. Исключение особенностей, не совместимых с реляционной моделью.

На этом этапе выполняется  следующие операции:

1) удаление двухсторонних связей «многие ко многим»

2) удаление рекурсивных  связей «многие ко многим»

3) удаление сложных  связей

4) удаление многозначных  атрибутов

В концептуальной модели БД имеются 2 связи вида «многие ко многим»: HoldPhase и ChargePhase. Это означает, что работник может иметь по нескольку видов начислений и удержаний, равно как и 1 вид удержаний или начислений может быть у нескольких работников. Поскольку реляционная модель данных не поддерживает такой тип связи, необходимо выполнить декомпозицию, заменив связь «многие ко многим» на 2 связи «один ко многим».

Таблица 4. Новые сущности для декомпозиции связей «многие ко многим»