Реферат Отчет о прохождении производственной практики в Министерстве здравоохранения и социального раз
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Кафедра «Информационно-вычислительные системы»
Отчет
о прохождении производственной практики
в Министерстве здравоохранения и социального развития
Пензенской области
Выполнила: ст-ка гр.05ВЭ2
___________ Вергазова И.А.
Руководитель от университета:
доцент каф. ИВС
___________ Баусова З.И.
Руководитель от министерства:
2010
Введение. 3
1 Анализ предметной области. 4
2 Техническое задание. 9
2.1 Основание для разработки. 9
2.2 Назначение разработки. 9
2.3 Требования к программе. 9
2.3.1 Требования к функциональным характеристикам. 9
2.3.2 Требования к надежности. 10
2.3.3 Требования к составу и параметрам технических средств. 11
2.3.4 Требования к информационной и программной совместимости. 11
3 Функциональное проектирование АИС расчета заработной платы в медицинском учреждении. 12
3.1 Описание средства проектирования системы BPWin. 12
3.2 Описание функциональной модели системы.. 14
4 Инфологическое проектирование АИС расчета заработной платы в медицинском учреждении. 20
4.1 Описание средства проектирования ERWin. 20
4.2 Логическое проектирование системы.. 21
4.3 Разработка структуры связей. 24
4.4 Нормализация базы данных. 27
4.5 Физическое проектирование системы.. 29
5 Обоснование целесообразности использования выбранного средства реализации 34
Заключение. 36
Приложение А. Функциональная модель системы.. 38
Приложение Б. Инфологическая модель системы.. 42
В настоящее время ЭВМ широко применяется во многих отраслях деятельности человека. Ни одно учреждение не может обойтись в своей работе без применения компьютеров. Они с успехом заменяют рутинную работу, выполнявшуюся ранее в ручную, повышая эффективность работы любого учреждения.
С ростом автоматизации бизнес-процессов связано увеличение потребности в системах обработки и хранения данных, развитие их функциональности и удобства использования. Использование систем обработки данных упрощает общение человека с огромным количеством информации, которая теперь хранится в компьютере.
Разрабатываемая автоматизированная информационная система, предназначена для автоматизации деятельности расчетного отдела любого учреждения здравоохранения. Система позволит упростить работу по редактированию базы данных сотрудников, ведению кадрового учета, составлению штатного расписания, ведению учета сведений по оплате труда, расчет заработной платы сотрудников и формированию всех необходимых выходных документов: «Расчетно-платежной ведомости», «Свода начислений и удержаний», «Расчетных листов», «Отчетов по уплате взносов во внебюджетные фонды».
Разрабатываемая система позволит существенно сократить затраты рабочего времени и повысить эффективность работы сотрудника расчетного отдела за счет того, что система легка в обращении, позволяет хранить большое количество сведений в одной базе данных и создает все основные отчеты.
Отчет содержит анализ предметной области, техническое задание, функциональное и логическое проектирование.
Предметной областью для данной разработки является деятельность расчетного отдела медицинского учреждения. Основной целью деятельности расчетного отдела является расчет заработной платы сотрудников.
В основные функции отдела входит:
- ведение кадрового учета;
- ведение табельного учета;
- учет начислений;
- учет удержаний.
Расчёт заработной платы — процесс начисления оплаты нанятым работникам согласно условиям найма и удержания налогов и прочих вычетов согласно законодательству, договоров, поручений и т. п., так же их документальное оформление. Этапы расчёта:
- расчёт сумм оплаты труда и других выплат работникам, а также лицам, выполняющим работу по договорам гражданско-правового характера;
- расчёт налогов на доходы физических лиц;
- расчёт других налогов и взносов, связанных с доходами физических лиц, устанавливаемых Федеральным законодательством и законодательством субъектов Федерации;
- подготовка комплекта документов по оформлению выплат работникам.
Результатом расчёта заработной платы является комплект документов:
- расчётные ведомости;
- расчётные листки;
- другие документы имеющие значение для проведения расчётов.
Размеры окладов медицинских и фармацевтических работников учреждений в зависимости от профессиональной квалификационной группы, квалификационного уровня и вида подразделения устанавливаются в соответствии с «Положением о системе оплаты труда работников государственных бюджетных учреждений здравоохранения Пензенской области».
К окладу на определенный период времени в течение соответствующего календарного года и с учетом обеспечения финансовыми средствами могут быть установлены повышающие коэффициенты:
- повышающий коэффициент к окладу по занимаемой должности в размере до 2,5;
- повышающий коэффициент к окладу по Учреждению (структурному подразделению Учреждения);
- персональный повышающий коэффициент к окладу.
Таблица 1 - Размер повышающего коэффициента к окладу за
квалификационную категорию
| Номер | Квалификационная категория | Размер повышающего коэффициента |
| 1 | 2 | 3 |
| 1. | Врачи, провизоры: | Размер повышающего коэффициента к минимальной ставке заработной платы, установленной для 1 квалификационного уровня ПКГ "Врачи и провизоры" |
| 1.1 | Высшая квалификационная категория | 0,650 |
| 1.2 | Первая квалификационная категория | 0,465 |
| 1.3 | Вторая квалификационная категория | 0,279 |
| 2. | Средний медицинский персонал, главные акушерки, фармацевты | Размер повышающего коэффициента к минимальной ставке заработной платы, установленной для 1 квалификационного уровня ПКГ " Средний медицинский и фармацевтический персонал " |
| 1 | 2 | 3 |
| 2.1 | Высшая квалификационная категория | 0,398 |
| 2.2 | Первая квалификационная категория | 0,284 |
| 2.3 | Вторая квалификационная категория | 0,171 |
Повышающий коэффициент к окладу за квалификационную категорию применяется при условии занятости работника в Учреждении не менее чем на полную ставку в соответствии с полученной специальностью и квалификацией за фактически отработанное время по основному месту работы.
почетное звание
| Наименование повышающего коэффициента | Размер повышающего коэффициента |
| Повышающий коэффициент к окладу за ученую степень доктора наук, ученое звание профессор | 0,2 |
| Повышающий коэффициент к окладу за ученую степень кандидата наук, ученое звание доцент | 0,1 |
| Повышающий коэффициент к окладу за наличие почетного звания наличие почетного звания | 0,1 |
Министерством здравоохранения и социального развития Российской Федерации утверждены следующие выплаты компенсационного характера:
- выплаты работникам, занятым на тяжелых работах, работах с вредными и (или) опасными и иными особыми условиями труда;
- выплаты за работу в условиях, отклоняющихся от нормальных (при совмещении профессий (должностей), сверхурочной работе, работе в ночное время, при расширении зон обслуживания, при увеличении объема работы или исполнении обязанностей временно отсутствующего работника без освобождения от работы, определенной трудовым договором, за работу в выходные и нерабочие праздничные дни и при выполнении работ в других условиях, отклоняющихся от нормальных);
- надбавка за работу со сведениями, составляющими государственную тайну.
Размер указанной выплаты определяется путем умножения оклада работника на соответствующий повышающий коэффициент.
С целью стимулирования к качественному результату труда и поощрения работников за выполненную работу в Учреждениях, устанавливается перечень стимулирующих выплат:
- выплаты за интенсивность и высокие результаты работы:
- надбавка за перевыполнение отраслевых норм нагрузки;
- надбавка за участие в федеральных и отраслевых программах и т.д.
- выплаты за качество выполняемых работ, в соответствии с критериями качества, разработанными Министерством здравоохранения и социального развития Пензенской области.
- выплаты за стаж непрерывной работы, выслугу лет.
- удержания, предусмотренные федеральными законами и перечисляемые в бюджет (НДФЛ, штрафы за нарушение законодательства);
- обязательные удержания (удержания на основании исполнительных листов в пользу третьих лиц, в том числе алиментов, материального ущерба, понесенного организацией и другое);
- удержания из заработной платы работника для погашения его задолженности по инициативе работодателя (возмещение неотработанного, неизрасходованного или своевременно не возвращенного аванса, возврат сумм выплаченных работнику вследствие счетных ошибок и другое);
- удержания по просьбе самого работника (выплаты займов, перечисления за квартплату, платежи по личному страхованию, профсоюзные взносы и другое).
На данный момент расчет заработной платы ведется в разрозненном виде. Частично информация регистрируется и хранится в компьютерной базе данных, частично в бумажном виде. При возникновении нештатных ситуаций поиск необходимых данных потребует больших затрат времени и усилий.
На рынке бухгалтерского программного обеспечения в нашей стране есть несколько крупных фирм, занимающихся разработкой универсальных систем: 1С, Парус и Криста. Внедрение программных продуктов этих фирм, и им подобных, значительно облегчает и ускоряет ведение учета, но большинство из них отличаются высокой ценой, сложностью в эксплуатации и длительностью обучения персонала. У всех систем подобного рода, кроме 1С, отсутствует возможность доработки.
Министерством здравоохранения и социального развития было принято решение разработать систему расчета заработной платы для медицинского учреждения.
Система должна позволять:
- хранить всю необходимую информацию по отделениям и имеющимся в них должностям;
- хранить информацию по сотрудникам, назначения на должности;
- вести учет стимулирующих надбавок и удержаний;
- вести учет штатного расписания;
- вести учет сведений по оплате труда;
- начислять заработную плату сотрудникам;
- формировать необходимые отчетные документы.
2 Техническое задание
2.1 Основание для разработки
Основанием для разработки является задание на преддипломную практику, выданное руководителем доцентом кафедры ИВС Баусовой З.И. по заказу Министерства здравоохранения и социального развития.
2.2 Назначение разработки
Разрабатываемая конфигурация предназначена для автоматизации расчета заработной платы расчетным отделом медицинского учреждения, а именно: хранения информации об отделениях, сотрудниках, учета должностей, расчета заработной платы сотрудников и формирования основных отчетных документов.
2.3 Требования к программе
2.3.1 Требования к функциональным характеристикам
Разрабатываемая конфигурация «Расчет зарплаты в больнице» должна обеспечивать:
- учет и корректировку данных по отделениям;
- учет и корректировку данных по должностям;
- учет ставок;
- корректировку штатного расписания;
- учет и корректировку личных данных сотрудников;
- учет и корректировку данных по должностным окладам, надбавкам и удержаниям;
- учет и корректировку данных по отклонениям от графика работы сотрудников;
- ведение учета приказов;
- расчет заработной платы сотрудников с учетом всех надбавок и удержаний;
- вывод отчетов по начислениям.
Входными данными системы являются:
- сведения об отделениях;
- сведения о должностях;
- сведения о сотрудниках;
- сведения по вычетам НДФЛ;
- сведения о должностных окладах;
- сведения о надбавках и удержаниях;
- количество рабочих дней в месяц;
- сведения об отклонениях от графика работы сотрудников;
- приказы на назначение на должность;
- сведения по начислениям и удержаниям;
- расчетно-платежная ведомость;
- расчетные листы;
- отчеты по уплате взносов во внебюджетные фонды.
Разрабатываемая конфигурация должна иметь удобный графический интерфейс, не предъявляя высоких аппаратных требований. Кроме того, в конфигурации должна быть предусмотрена печать всех отчетных документов.
2.3.2 Требования к надежности
Конфигурация должна выдавать сообщения об ошибках при неверно заданных исходных данных, поддерживать диалоговый режим в рамках предоставляемых пользователю возможностей.
2.3.3 Требования к составу и параметрам технических средств
- тактовая частота процессора – 866 МГц;
- оперативная память – 256 Мбайт;
- на жестком диске при установке используется около 120 Мбайт;
- объем жестокого диска зависит от размера информационной базы, но должен быть не менее 1,5 Мбайта;
- принтер.
Конфигурация должна быть разработана на платформе «1С: Предприятие 8», работающей под управлением операционной системы Windows 98 и выше.
3 Функциональное проектирование АИС расчета заработной платы в медицинском учреждении
3.1 Описание средства проектирования системы BPWin
BPwin - средство функционального моделирования, которое используется для анализа, документирования и реорганизации сложных бизнес-процессов. BPwin поддерживает следующие методологии: IDEF0 (функциональная модель), IDEF3 (методология моделирования), DFD (диаграмма потоков данных), каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. с. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD.
Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель может содержать четыре типа диаграмм:
- контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);
- диаграммы декомпозиции;
- диаграммы дерева узлов;
- диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания.
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Диаграмма потоков данных DFD (Data Flow Diagramming) используется для описания документооборота и обработки информации. Данная диаграмма представляет моделируемую систему как совокупность связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:
- функции обработки информации (работы);
- документы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации;
- внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
-
таблицы для хранения документов (хранилище данных, data store).
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Внешние сущности изображают входы в систему и/или выходы из системы. Хранилища данных изображают объекты в покое. В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.
IDEF3 (workflow diagramming) - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации.
IDEF3 - это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное /4/.
3.2 Описание функциональной модели системы
В результате анализа предметной области была разработана функциональная модель системы начисления стипендий. Проектирование проводилось на основе методологий IDEF0 и DFD.
Диаграмма верхнего уровня (рисунок А.1) реализована с помощью методологии IDEF0.
Компонентой контекстной диаграммы является процесс «Расчет заработной платы в больнице». Входными данными для обеспечения работоспособности системы являются:
- сведения об отделениях;
- сведения о должностях;
- сведения о сотрудниках;
- сведения по вычетам НДФЛ;
- сведения о должностных окладах;
- сведения о надбавках и удержаниях;
- количество рабочих дней в месяц;
- сведения об отклонениях от графика работы сотрудников;
- приказы на назначение на должность;
Выходными данными являются:
- сведения по начислениям и удержаниям;
- расчетно-платежная ведомость;
- расчетные листы;
- отчеты по уплате взносов во внебюджетные фонды.
Расчет заработной платы производится на основе правил расчет зарплаты и трудового кодекса (стрелка управления) сотрудниками расчетного отдела (механизм).
Функциональная декомпозиция контекстной диаграммы системы «Расчет заработной платы в больнице» (рисунок А.2) проведена на основе анализа предметной области с помощью методологии DFD. В процессе декомпозиции выделено 10 бизнес-процессов:
- учет данных по отделениям;
- учет данных по должностям;
- учет личных данных сотрудников;
- учет должностных окладов;
- корректировка данных по вычетам НДФЛ;
- учет данных по удержаниям и надбавкам;
- учет данных по отклонениям от графика работы;
- учет ставок;
- корректировка штатного расписания;
- начисление зарплаты работникам.
Входными данными для реализации процесса «Учет данных по отделениям» являются сведения об отделениях, которые поступают в хранилище «Отделения».
Входными данными для реализации процесса «Учет данных по должностям» являются сведения о должностях, которые поступают в хранилище «Должности».
Входными данными для реализации процесса «Учет личных данных сотрудников» являются сведения о сотрудниках, которые поступают в хранилище «Сотрудники».
Входными данными для реализации процесса «Учет должностных окладов» являются сведения о должностных окладах, которые поступают в хранилище «Должностные оклады».
Входными данными для реализации процесса «Корректировка данных по вычетам» являются сведения по вычетам НДФЛ, которые поступают в хранилище «Стандартные вычеты».
Входными данными для реализации процесса «Учет данных по удержаниям и надбавкам» являются сведения об удержаниях и надбавках. Данные о суммах надбавок и удержаний заносятся в хранилище «Надбавки и удержания».
Входными данными для реализации процесса «Учет данных по отклонениям от графика работы» являются сведения об отклонениях от графика работы, которые поступают в хранилище «Отклонения от графика».
Процесс «Учет ставок» строится на основе данных по отделениям и должностям. Он формирует сводные данные по ним, которые заносятся в хранилище «Ставки».
Входными данными для реализации процесса «Корректировка штатного расписания» являются:
- информация по ставкам, отделениям и должностям;
- информация о сотрудниках;
- информация по окладам.
С помощью данного процесса осуществляется составление штатного расписания. Данные по штатному расписанию заносятся в хранилище «Штатное расписание».
Входными данными для реализации процесса «Начисление зарплаты работникам» является информация:
- по сотрудникам;
- по отделениям;
- по должностям;
- по окладам;
- по стандартным вычетам;
- по отклонениям от графика;
- по надбавкам и удержаниям.
Осуществляется начисление зарплаты работникам и формируются сведения по начислениям.
Компоненты диаграммы декомпозиции процесса «Расчет заработной платы в больнице» приведены в таблице 3.
Таблица 3 – Компоненты диаграммы декомпозиции процесса «Расчет заработной платы в больнице»
Для раскрытия всех аспектов работы «Начисление зарплаты работникам» необходимо провести последующую ее детализацию.
Диаграмма декомпозиции процесса «Начисление зарплаты работникам» представлена на рисунке А.3, а ее компоненты приведены в таблице 4.
Таблица 4 – Компоненты диаграммы декомпозиции процесса
«Начисление зарплаты работникам»
4 Инфологическое проектирование АИС расчета заработной платы в медицинском учреждении
4.1 Описание средства проектирования ERWin
ERwin - средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных.
ERwin имеет два уровня представления модели - логический и физический.Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже).
Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.
Различают три уровня логической модели, отличающихся по глубине представления информации о данных:
- диаграмма сущность-связь (Entity Relationship Diagram, ERD);
- модель данных, основанная на ключах (Key Based model, KB);
- полная атрибутивная модель (Fully Attributed model, FA).
Основные компоненты диаграммы Erwin - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта.
Различают два уровня физической модели:
- трансформационная модель (Transformation Model);
- модель СУБД (DBMS Model).
Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area) /4/.
4.2 Логическое проектирование системы
В соответствии с индивидуальным заданием определим требования к составу данных.
В расчетном отделе медицинского учреждения находится вся информация о начислении работникам заработной платы. При расчете заработной платы должностной оклад работника рассчитывается в зависимости от занимаемой им должности и количества ставок, на которых он работает. К окладу устанавливается повышающий коэффициент за квалификационную категорию, ученую степень, почетные звания и другое. Кроме того работнику может быть начислена надбавка, как выплата компенсационного характера или стимулирующая выплата. После определения начисленной суммы заработной платы рассчитываются размеры удержаний. Затем производится расчет зарплаты к выдаче.
На основе анализа предметной области выделено 17 сущностей:
- сущность «Отделение» определяется следующими атрибутами: код отделения, название отделения, источник средств;
- сущность «Сотрудник» определяется следующими атрибутами: табельный номер, ФИО, пол, дата рождения, фотография, документ, номер документа, адрес, страховой номер, ИНН, форма работы, резидент, сведения, инвалидность, является членом профсоюза, номер лицевой карточки, сведения по вычетам, дата принятия на работу, причина увольнения;
- сущность «Вычеты НДФЛ» определяется следующими атрибутами: табельный номер, код вычета личный, код вычета на детей, количество детей, код вычета на детей инвалидов, количество детей инвалидов;
- сущность «Приказ» определяется следующими атрибутами: табельный номер, номер приказа, дата, вид приказа, содержание;
- сущность «Профессиональные группы» определяется следующими атрибутами: квалификационная группа;
- сущность «Квалификационный уровень» определяется следующими атрибутами: квалификационный уровень, квалификационная группа;
- сущность «Должность» определяется следующими атрибутами: квалификационный уровень, название должности, месяц, количество рабочих дней в месяц;
- сущность «Ставки» определяется следующими атрибутами: квалификационный уровень, название отделении, название должности, количество ставок;
- сущность «Размеры окладов» определяется следующими атрибутами: квалификационный уровень, название должности, размер оклада;
- сущность «Штатное расписание» определяется следующими атрибутами: название отделения, табельный номер, название должности, квалификационный уровень;
- сущность «Отклонения от графика» определяется следующими атрибутами: код отклонения, наименование отклонения;
- сущность «Табельный учет» определяется следующими атрибутами: табельный номер, код отклонения, начало, конец, всего дней;
- сущность «Надбавка» определяется следующими атрибутами: код надбавки, наименование надбавки, сумма, основание;
- сущность «Начисление надбавки» определяется следующими атрибутами: табельный номер, код надбавки, сумма по надбавкам, дата начисления надбавки;
- сущность «Удержания» определяется следующими атрибутами: код удержания, наименование удержания, сумма, основания;
- сущность «Начисление удержания» определяется следующими атрибутами: код удержания, табельный номер, сумма по удержаниям, дата начисления удержания;
- сущность «Расчет заработной платы» определяется следующими атрибутами: номер расчета, табельный номер, код отделения, название должности, квалификационный уровень, рабочие дни, норма часов, код отклонения, начислено за отработанное время, код надбавки, код удержания, начислено аванс, к выдаче.
Однозначно идентифицируем каждый экземпляр сущности - выделим первичные ключи.
Сущность «Сотрудник» - первичный ключ «Табельный номер».
Сущность «Вычеты НДФЛ» - первичный ключ «Табельный номер».
Сущность «Приказ» - составной первичный ключ «Табельный номер», «Номер приказа».
Сущность «Отделения» - первичный ключ «Название отделения».
Сущность «Отклонения от графика» - первичный ключ «Код отклонения».
Сущность «Табельный учет» - составной первичный ключ «Табельный номер», «Код отклонения».
Сущность «Надбавка» - первичный ключ «Код надбавки».
Сущность «Начисление надбавки» - составной первичный ключ «Табельный номер», «Код надбавки».
Сущность «Удержания» - первичный ключ «Код удержания».
Сущность «Начисление удержания» - составной первичный ключ «Табельный номер», «Код удержания».
Сущность «Проф группы» - первичный ключ «Квалификационная группа».
Сущность «Ставки» - составной первичный ключ «Квалификационный уровень», «Название должности», «Название отделения».
Сущность «Квалификационный уровень» - первичный ключ «Квалификационный уровень».
Сущность «Должность» - составной первичный ключ «Квалификационный уровень», «Название должности».
Сущность «Штатное расписание» - составной первичный ключ «Название отделения», «Табельный номер».
Сущность «Размеры окладов» - составной первичный ключ «Название должности», «Квалификационный уровень».
Сущность «Расчет заработной платы» - составной первичный ключ «Табельный номер», «Номер расчета», «Название отделения».
4.3 Разработка структуры связей
Свяжем таблицы через внешние ключи.
Сущности «Сотрудник» и «Вычеты НДФЛ» связаны через внешний ключ по полю «Табельный номер». Т.к. вычеты предоставляются на каждого сотрудника, то эта связь будет «один-к-одному».
Сущности «Сотрудник» и «Приказ» связаны через внешний ключ по полю «Табельный номер». Т.к. на каждого сотрудника может быть несколько приказов, то эта связь будет «один-ко-многим».
Сущности «Табельный учет» и «Отклонения от графика» связаны через внешний ключ по полю «Код отклонения». Т.к. у каждого сотрудника может быть несколько отклонений, то эта связь будет «один-ко-многим».
Сущности «Удержание» и «Начисление удержания» связаны через внешний ключ по полю «Код удержания». Т.к. по одному виду удержания может быть много начислений, то эта связь будет «один-ко-многим».
Сущности «Надбавка» и «Начисление надбавки» связаны через внешний ключ по полю «Код надбавки». Т.к. по одному виду надбавки может быть много начислений, то эта связь будет «один-ко-многим».
Сущности «Начисление удержания» и «Расчет заработной платы» связаны через внешний ключ по полю «Код удержания». Т.к. начисленные удержания на сотрудника могут быть во многих его расчетах зарплаты, то эта связь будет «один-ко-многим».
Сущности «Начисление надбавки» и «Расчет заработной платы» связаны через внешний ключ по полю «Код надбавки». Т.к. начисленные надбавки на сотрудника могут быть во многих его расчетах зарплаты, то эта связь будет «один-ко-многим».
Сущности «Табельный учет» и «Расчет заработной платы» связаны через внешний ключ по полю «Код отклонения». Т.к. табельный учет по отклонениям от графика работы на каждого сотрудника может быть во многих его расчетах зарплаты, то эта связь будет «один-ко-многим».
Сущности «Сотрудник» и «Начисление удержания» связаны через внешний ключ по полю «Табельный номер». Т.к. у одного сотрудника может быть много удержаний, то эта связь будет «один-ко-многим».
Сущности «Сотрудник» и «Начисление надбавки» связаны через внешний ключ по полю «Табельный номер». Т.к. у одного сотрудника может быть много надбавок, то эта связь будет «один-ко-многим».
Сущности «Сотрудник» и «Табельный учет» связаны через внешний ключ по полю «Табельный номер». Т.к. у одного сотрудника может быть много отклонений от графика работы, то эта связь будет «один-ко-многим».
Сущности «Профессиональные группы» и «Квалификационный уровень» связаны через внешний ключ по полю «Квалификационная группа». Т.к. в одной профессиональной группе может быть несколько квалификационных уровеней, то эта связь будет «один-ко-многим».
Сущности «Квалификационный уровень» и «Должность» связаны через внешний ключ по полю «Квалификационный уровень». Т.к. на одном квалификационном уровне может быть несколько дожностей, то эта связь будет «один-ко-многим».
Сущности «Должность» и «Штатное расписание» связаны через внешние ключи: «Название должности», «Квалификационный уровень». Т.к. одна должность может повторятся в штатном расписании несколько раз, то эта связь будет «один-ко-многим».
Сущности «Должность» и «Размеры окладов» связаны через внешние ключи: «Название должности», «Квалификационный уровень». Т.к. одной должности может соответствовать только один оклад, то эта связь будет «один-к-одному».
Сущности «Сотрудник» и «Штатное расписание» связаны через внешний ключ по полю «Табельный номер». Т.к. один сотрудник может быть несколько раз в штатном расписании (совместитель), то эта связь будет «один-ко-многим».
Сущности «Отделение» и «Ставки» связаны через внешний ключ по полю «Код отделения». Т.к. одна должность может быть в разных отделениях, то эта связь будет «один-ко-многим».
Сущности «Ставки» и «Должности» связаны через внешние ключи: «Название должности», «Квалификационный уровень». Т.к. в одном отделении может быть несколько должностей, то эта связь будет «один-ко-многим».
Сущности «Размеры окладов» и «Расчет заработной платы» связаны через внешние ключи: «Название должности», «Квалификационный уровень». Т.к. должностной оклад может назначаться несколько раз одному сотруднику, если он работает совместителем, то эта связь будет «один-ко-многим».
Сущности «Штатное расписание» и «Расчет заработной платы» связаны через внешние ключи: «Код отделения», «Табельный номер». Т.к. для каждого сотрудника, находящегося на конкретной должности в месяц может производится один расчет заработной платы, то эта связь будет «один-к-одному».
4.4 Нормализация базы данных
Проанализируем отношения с учетом их первичных ключей и функциональных зависимостей для доказательства нормализации.
В отношениях «Сотрудник», «Вычеты НДФЛ», «Приказ», «Отделение», «Ставки», «Должность», «Штатное расписание», «Профессиональные группы», «Квалификационный уровень», «Надбавки», «Начисление надбавки», «Размеры окладов», «Отклонения от графика», «Табельный учет», «Удержания», «Начисление удержаний» и «Расчет заработной платы» нет повторяющихся групп данных, т.е. все значения их атрибутов неделимы. Следовательно, данные отношения находятся в первой нормальной форме (НФ).
В отношениях «Отделение», «Сотрудник», «Вычеты НДФЛ», «Студент», «Удержание», «Приказ», «Стипендия», «Надбавка», «Профессиональные группы», «Квалификационный уровень», «Надбавки», «Отклонения от графика», «Удержания» уникальными являются только первичные ключи, остальные не ключевые атрибуты не уникальны и функционально полно зависят от ключа.
В отношении «Приказ» уникальным является составной первичный ключ, который состоит из атрибутов: «Табельный номер» и «Номер приказа». Не ключевыми атрибутами являются: «Дата», «Вид приказа», «Содержание». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Должность» уникальным является составной первичный ключ, который состоит из атрибутов: «Название должности» и «Квалификационный уровень». Не ключевыми атрибутами являются: «Месяц», «Количество рабочих дней в месяц». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Ставки» уникальным является составной первичный ключ, который состоит из атрибутов: «Код отделения», «Название должности» и «Квалификационный уровень». Не ключевым атрибутом является: «Количество ставок». Атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Штатное расписание» уникальным является составной первичный ключ, который состоит из атрибутов: «Табельный номер», «Код отделения». Не ключевыми атрибутами являются: «Название должности», «Квалификационный уровень». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Начисление удержания» уникальным является составной первичный ключ, который состоит из атрибутов: «Табельный номер» и «Код удержания». Не ключевыми атрибутами являются: «Дата начисления удержания», «Сумма по удержанию». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Начисление надбавки» уникальным является составной первичный ключ, который состоит из атрибутов: «Табельный номер» и «Код надбавки». Не ключевыми атрибутами являются: «Дата начисления надбавки», «Сумма по надбавке». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Расчет заработной платы» уникальным является составной первичный ключ, который состоит из атрибутов: «Номер расчета», «Табельный номер» и «Код отделения». Не ключевыми атрибутами являются: «Название должности», «Квалификационный уровень», «Рабочие дни», «Норма часов», «Код отклонения», «Начислено за отработанное время», «Код надбавки», «Код удержания», «Начислено аванс», «К выдаче». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
Ни в одном из отношений не существует транзитивных зависимостей, т.е. не ключевые атрибуты не зависят функционально друг от друга. Таким образом, отношения находятся в 3НФ.
Логическая структура базы данных (ER – диаграмма) представлена на рисунке Б.1.
4.5 Физическое проектирование системы
На этапе логического проектирования на основе семантического анализа предметной области осуществляется разбиение БД на таблицы. При этом каждой сущности предметной области ставится в соответствие таблица, атрибутам объекта соответствуют атрибуты таблицы, а идентификатору объекта соответствует ключ таблицы.
Типы данных атрибутов сущностей приведены в таблицах 5-21.
Таблица 5 - Типы данных атрибутов сущности «Отделение»
Таблица 6 - Типы данных атрибутов сущности «Сотрудник»
Таблица 7 - Типы данных атрибутов сущности «Вычеты НДФЛ»
Таблица 8 - Типы данных атрибутов сущности «Приказ»
Таблица 9 - Типы данных атрибутов сущности «Удержание»
Таблица 10 - Типы данных атрибутов сущности «Начисление удержания»
Таблица 11 - Типы данных атрибутов сущности «Отклонения от графика»
Таблица 12 - Типы данных атрибутов сущности «Табельный учет»
Таблица 13 - Типы данных атрибутов сущности «Надбавка»
Таблица 14 - Типы данных атрибутов сущности «Начисление надбавки»
Таблица 15 - Типы данных атрибутов сущности «Профессиональные
группы»
Таблица 16 - Типы данных атрибутов сущности «Квалификационный
уровень»
Таблица 17 - Типы данных атрибутов сущности «Должность»
Таблица 18 - Типы данных атрибутов сущности «Ставки»
Таблица 19 - Типы данных атрибутов сущности «Штатное расписание»
Таблица 20 - Типы данных атрибутов сущности «Размеры окладов»
Таблица 21 - Типы данных атрибутов сущности «Расчет заработной платы»
ER – диаграмма физической структуры базы данных представлена на рисунке Б.2.
5 Обоснование целесообразности использования выбранного средства реализации
Автоматизация информационных систем должна осуществляться на основе максимально стандартизованных систем, так как это позволяет удешевить внедрение и повысить его качество.
На настоящий момент наиболее оптимальной программной системой для автоматизации учета является «1С: Предприятие 8».
Система «1С: Предприятие» является универсальной системой автоматизации экономической и организационной деятельности организаций и частных лиц. Поскольку такая деятельность может быть довольно разнообразной, система «1С: Предприятие» имеет возможность «приспосабливаться» к особенностям конкретной области деятельности, в которой она используется.
«1С: Предприятие» – это не просто программа, существующая в виде набора неизменяемых файлов, а совокупность различных программных инструментов, с которыми работают разработчики и пользователи. Логически всю систему можно разделить на две большие части, которые тесно взаимодействуют друг с другом: конфигурацию и платформу /2/.
Сама платформа «1C:Предприятие 8» не является программным продуктом для конечных пользователей, которые обычно работают с одним или несколькими прикладными решениями (конфигурациями), разработанными на данной платформе. Такой подход позволяет автоматизировать различные виды деятельности, используя единую технологическую платформу «1С: Предприятие 8».
Прикладное решение (конфигурация) использует механизмы «1С: Предприятия 8» и работает только под управлением платформы, поэтому оно не может быть использовано самостоятельно, как отдельное приложение. Конечный пользователь всегда работает с системой программ «1С: Предприятие 8», которая включает в себя платформу и прикладные решения.
Разработка и модификация прикладного решения производится в специальном режиме «Конфигуратор». В данном режиме разработчик определяет общую архитектуру прикладного решения и структуру данных, создает макеты отчетов и экранные формы, пишет программные модули на встроенном языке программирования. Конечный пользователь работает в обычном режиме «Предприятие», вводит данные в базу данных, формирует отчеты и т.д.
На этапе разработки или модификации конфигурации разработчик анализирует предметную область и требования пользователей, создает или изменяет объекты конфигурации, настраивает связи между ними путем установки их свойств, проектирует экранные формы и макеты отчетов, реализует алгоритмы работы системы на встроенном языке. В результате получается прикладное решение, призванное автоматизировать работу конечных пользователей, обеспечить им информационную поддержку при принятии управленческих решений.
Заключение
В результате прохождения практики была изучена работа расчетного отдела медицинского учреждения, его основные задачи, направления деятельности и документация. После анализа полученных сведений было сформулировано техническое задание на разработку автоматизированной информационной системы расчета заработной платы в медицинском учреждении.
В ходе проделанной работы было проведено инфологическое проектирование, в результате чего были построены логическая модель и физическая модель системы с использованием CASE-средства ERWin. Также была разработана функциональная модель системы с использованием CASE-средства BPWin.
Список использованных источников
1. Митичкин С. А. Разработка в системе 1С: Предприятие 8.0. – М.: ООО «1С-Паблишинг», 2003. – 413 с.
2.Радченко М. Г. 1С: Предприятие 8.0. Практическое пособие разработчика. Примеры и типовые приемы. – М.: ООО «1С-Паблишинг», 2004. –656 с.
3. Горбаченко В.И., Убиенных Г.Ф., Убиенных А.Г. Работа с базами данных в среде Microsoft Access 2002: Лабораторный практикум. – Пенза: Изд-во Пенз. гос. ун-та, 2003.
4. Маклаков С.В. BPwin и ERwin: CASE-средства для разработки информационных систем. – http://www.isuct.ru/~ivt/books/CASE/case5/Prewords.html.
Приложение А
(обязательное)
Приложение Б
(обязательное)
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Диаграмма потоков данных DFD (Data Flow Diagramming) используется для описания документооборота и обработки информации. Данная диаграмма представляет моделируемую систему как совокупность связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:
- функции обработки информации (работы);
- документы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации;
- внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
-
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Внешние сущности изображают входы в систему и/или выходы из системы. Хранилища данных изображают объекты в покое. В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.
IDEF3 (workflow diagramming) - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации.
IDEF3 - это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное /4/.
3.2 Описание функциональной модели системы
Диаграмма верхнего уровня (рисунок А.1) реализована с помощью методологии IDEF0.
Компонентой контекстной диаграммы является процесс «Расчет заработной платы в больнице». Входными данными для обеспечения работоспособности системы являются:
- сведения об отделениях;
- сведения о должностях;
- сведения о сотрудниках;
- сведения по вычетам НДФЛ;
- сведения о должностных окладах;
- сведения о надбавках и удержаниях;
- количество рабочих дней в месяц;
- сведения об отклонениях от графика работы сотрудников;
- приказы на назначение на должность;
Выходными данными являются:
- сведения по начислениям и удержаниям;
- расчетно-платежная ведомость;
- расчетные листы;
- отчеты по уплате взносов во внебюджетные фонды.
Функциональная декомпозиция контекстной диаграммы системы «Расчет заработной платы в больнице» (рисунок А.2) проведена на основе анализа предметной области с помощью методологии DFD. В процессе декомпозиции выделено 10 бизнес-процессов:
- учет данных по отделениям;
- учет данных по должностям;
- учет личных данных сотрудников;
- учет должностных окладов;
- корректировка данных по вычетам НДФЛ;
- учет данных по удержаниям и надбавкам;
- учет данных по отклонениям от графика работы;
- учет ставок;
- корректировка штатного расписания;
- начисление зарплаты работникам.
Входными данными для реализации процесса «Учет данных по отделениям» являются сведения об отделениях, которые поступают в хранилище «Отделения».
Входными данными для реализации процесса «Учет данных по должностям» являются сведения о должностях, которые поступают в хранилище «Должности».
Входными данными для реализации процесса «Учет личных данных сотрудников» являются сведения о сотрудниках, которые поступают в хранилище «Сотрудники».
Входными данными для реализации процесса «Учет должностных окладов» являются сведения о должностных окладах, которые поступают в хранилище «Должностные оклады».
Входными данными для реализации процесса «Учет данных по удержаниям и надбавкам» являются сведения об удержаниях и надбавках. Данные о суммах надбавок и удержаний заносятся в хранилище «Надбавки и удержания».
Входными данными для реализации процесса «Учет данных по отклонениям от графика работы» являются сведения об отклонениях от графика работы, которые поступают в хранилище «Отклонения от графика».
Процесс «Учет ставок» строится на основе данных по отделениям и должностям. Он формирует сводные данные по ним, которые заносятся в хранилище «Ставки».
Входными данными для реализации процесса «Корректировка штатного расписания» являются:
- информация по ставкам, отделениям и должностям;
- информация о сотрудниках;
- информация по окладам.
С помощью данного процесса осуществляется составление штатного расписания. Данные по штатному расписанию заносятся в хранилище «Штатное расписание».
Входными данными для реализации процесса «Начисление зарплаты работникам» является информация:
- по сотрудникам;
- по отделениям;
- по должностям;
- по окладам;
- по стандартным вычетам;
- по отклонениям от графика;
- по надбавкам и удержаниям.
Осуществляется начисление зарплаты работникам и формируются сведения по начислениям.
Таблица 3 – Компоненты диаграммы декомпозиции процесса «Расчет заработной платы в больнице»
| Процесс | Входные данные | Выходные данные | Хранилище |
| 1 | 2 | 3 | 4 |
| Учет данных по отделениям | - сведения об отделениях | - данные об отделениях | Отделения |
| Учет данных по должностям | - сведения о должностях | - данные о должностях | Должности |
| Учет должностных окладов | - сведения о должностных окладах | - данные по окладам | Должностные оклады |
| 1 | 2 | 3 | 4 |
| Учет личных данных сотрудников | - сведения о сотрудниках | - данные о сотрудниках | Сотрудники |
| Корректировка данных по вычетам НДФЛ | - сведения по вычетам НДФЛ | - данные по вычетам | Стандартные вычеты |
| Учет данных по отклонениям от графика | - сведения об отклонениях от графика работы | - данные об отклонениях | Отклонения от графика |
| Учет ставок | - информация об отделениях; - информация о должностях. | - данные по ставкам | Ставки |
| Корректировка штатного расписания | - информация по ставкам, отделениям и должностям; - информация по сотрудникам; - информация по окладам. | - данные по отделениям, должностям, сотрудникам, окладам. | Штатное расписание |
| Учет данных надбавкам и удержаниям | - сведения об удержаниях и надбавках. | - данные о надбавках и удержаниях. | Надбавки и удержания |
| Начисление зарплаты работникам | - информация по отделениям, должностям, сотрудникам, окладам; - информация по стандартным вычетам; - информация по отклонениям; - информация по надбавкам и удержаниям. | - расчетный лист; -расчетно-платежная ведомость; - свод начислений и удержаний. | |
Для раскрытия всех аспектов работы «Начисление зарплаты работникам» необходимо провести последующую ее детализацию.
Таблица 4 – Компоненты диаграммы декомпозиции процесса
«Начисление зарплаты работникам»
| Процесс | Входные данные | Выходные данные |
| Начисление зарплаты сотруднику за отработанное время | - информация по отделениям; - информация по должностям; - информация по сотрудникам; - информация по окладам; - информация по отклонениям; - число рабочих дней в месяц. | - сумма зарплаты за отработанное время |
| Начислен аванс | - информация по должностным окладам. | - сумма аванса |
| Начисление надбавок | - информация по надбавкам. | - итого по надбавкам |
| Начислено всего | - сумма зарплаты за отработанное время; - итого по надбавкам | - сумма начислений |
| Удержания | - сумма начислений; - информация по стандартным вычетам. | - сумма всего |
| Начисление зарплаты к выдаче | - сумма аванса; - сумма всего. | - сумма к выдаче |
| Формирование сведений по выплатам зарплаты | - информация по отделениям, должностям, сотрудникам, должностным окладам; - число рабочих дней в месяц; - информация по удержаниям, надбавкам; - сумма к выдаче. | - расчетный лист; - расчетно-платежная ведомость; - свод начислений и удержаний. |
4 Инфологическое проектирование АИС расчета заработной платы в медицинском учреждении
4.1 Описание средства проектирования ERWin
ERwin - средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных.
ERwin имеет два уровня представления модели - логический и физический.Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже).
Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.
- диаграмма сущность-связь (Entity Relationship Diagram, ERD);
- модель данных, основанная на ключах (Key Based model, KB);
- полная атрибутивная модель (Fully Attributed model, FA).
Основные компоненты диаграммы Erwin - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта.
Различают два уровня физической модели:
- трансформационная модель (Transformation Model);
- модель СУБД (DBMS Model).
Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area) /4/.
В соответствии с индивидуальным заданием определим требования к составу данных.
В расчетном отделе медицинского учреждения находится вся информация о начислении работникам заработной платы. При расчете заработной платы должностной оклад работника рассчитывается в зависимости от занимаемой им должности и количества ставок, на которых он работает. К окладу устанавливается повышающий коэффициент за квалификационную категорию, ученую степень, почетные звания и другое. Кроме того работнику может быть начислена надбавка, как выплата компенсационного характера или стимулирующая выплата. После определения начисленной суммы заработной платы рассчитываются размеры удержаний. Затем производится расчет зарплаты к выдаче.
На основе анализа предметной области выделено 17 сущностей:
- сущность «Отделение» определяется следующими атрибутами: код отделения, название отделения, источник средств;
- сущность «Сотрудник» определяется следующими атрибутами: табельный номер, ФИО, пол, дата рождения, фотография, документ, номер документа, адрес, страховой номер, ИНН, форма работы, резидент, сведения, инвалидность, является членом профсоюза, номер лицевой карточки, сведения по вычетам, дата принятия на работу, причина увольнения;
- сущность «Вычеты НДФЛ» определяется следующими атрибутами: табельный номер, код вычета личный, код вычета на детей, количество детей, код вычета на детей инвалидов, количество детей инвалидов;
- сущность «Приказ» определяется следующими атрибутами: табельный номер, номер приказа, дата, вид приказа, содержание;
- сущность «Квалификационный уровень» определяется следующими атрибутами: квалификационный уровень, квалификационная группа;
- сущность «Должность» определяется следующими атрибутами: квалификационный уровень, название должности, месяц, количество рабочих дней в месяц;
- сущность «Ставки» определяется следующими атрибутами: квалификационный уровень, название отделении, название должности, количество ставок;
- сущность «Размеры окладов» определяется следующими атрибутами: квалификационный уровень, название должности, размер оклада;
- сущность «Штатное расписание» определяется следующими атрибутами: название отделения, табельный номер, название должности, квалификационный уровень;
- сущность «Отклонения от графика» определяется следующими атрибутами: код отклонения, наименование отклонения;
- сущность «Табельный учет» определяется следующими атрибутами: табельный номер, код отклонения, начало, конец, всего дней;
- сущность «Надбавка» определяется следующими атрибутами: код надбавки, наименование надбавки, сумма, основание;
- сущность «Начисление надбавки» определяется следующими атрибутами: табельный номер, код надбавки, сумма по надбавкам, дата начисления надбавки;
- сущность «Удержания» определяется следующими атрибутами: код удержания, наименование удержания, сумма, основания;
- сущность «Начисление удержания» определяется следующими атрибутами: код удержания, табельный номер, сумма по удержаниям, дата начисления удержания;
- сущность «Расчет заработной платы» определяется следующими атрибутами: номер расчета, табельный номер, код отделения, название должности, квалификационный уровень, рабочие дни, норма часов, код отклонения, начислено за отработанное время, код надбавки, код удержания, начислено аванс, к выдаче.
Сущность «Сотрудник» - первичный ключ «Табельный номер».
Сущность «Вычеты НДФЛ» - первичный ключ «Табельный номер».
Сущность «Приказ» - составной первичный ключ «Табельный номер», «Номер приказа».
Сущность «Отделения» - первичный ключ «Название отделения».
Сущность «Отклонения от графика» - первичный ключ «Код отклонения».
Сущность «Табельный учет» - составной первичный ключ «Табельный номер», «Код отклонения».
Сущность «Надбавка» - первичный ключ «Код надбавки».
Сущность «Начисление надбавки» - составной первичный ключ «Табельный номер», «Код надбавки».
Сущность «Удержания» - первичный ключ «Код удержания».
Сущность «Начисление удержания» - составной первичный ключ «Табельный номер», «Код удержания».
Сущность «Проф группы» - первичный ключ «Квалификационная группа».
Сущность «Ставки» - составной первичный ключ «Квалификационный уровень», «Название должности», «Название отделения».
Сущность «Квалификационный уровень» - первичный ключ «Квалификационный уровень».
Сущность «Должность» - составной первичный ключ «Квалификационный уровень», «Название должности».
Сущность «Штатное расписание» - составной первичный ключ «Название отделения», «Табельный номер».
Сущность «Размеры окладов» - составной первичный ключ «Название должности», «Квалификационный уровень».
Сущность «Расчет заработной платы» - составной первичный ключ «Табельный номер», «Номер расчета», «Название отделения».
Свяжем таблицы через внешние ключи.
Сущности «Сотрудник» и «Вычеты НДФЛ» связаны через внешний ключ по полю «Табельный номер». Т.к. вычеты предоставляются на каждого сотрудника, то эта связь будет «один-к-одному».
Сущности «Сотрудник» и «Приказ» связаны через внешний ключ по полю «Табельный номер». Т.к. на каждого сотрудника может быть несколько приказов, то эта связь будет «один-ко-многим».
Сущности «Табельный учет» и «Отклонения от графика» связаны через внешний ключ по полю «Код отклонения». Т.к. у каждого сотрудника может быть несколько отклонений, то эта связь будет «один-ко-многим».
Сущности «Удержание» и «Начисление удержания» связаны через внешний ключ по полю «Код удержания». Т.к. по одному виду удержания может быть много начислений, то эта связь будет «один-ко-многим».
Сущности «Надбавка» и «Начисление надбавки» связаны через внешний ключ по полю «Код надбавки». Т.к. по одному виду надбавки может быть много начислений, то эта связь будет «один-ко-многим».
Сущности «Сотрудник» и «Начисление удержания» связаны через внешний ключ по полю «Табельный номер». Т.к. у одного сотрудника может быть много удержаний, то эта связь будет «один-ко-многим».
Сущности «Профессиональные группы» и «Квалификационный уровень» связаны через внешний ключ по полю «Квалификационная группа». Т.к. в одной профессиональной группе может быть несколько квалификационных уровеней, то эта связь будет «один-ко-многим».
Сущности «Квалификационный уровень» и «Должность» связаны через внешний ключ по полю «Квалификационный уровень». Т.к. на одном квалификационном уровне может быть несколько дожностей, то эта связь будет «один-ко-многим».
Сущности «Должность» и «Штатное расписание» связаны через внешние ключи: «Название должности», «Квалификационный уровень». Т.к. одна должность может повторятся в штатном расписании несколько раз, то эта связь будет «один-ко-многим».
Сущности «Должность» и «Размеры окладов» связаны через внешние ключи: «Название должности», «Квалификационный уровень». Т.к. одной должности может соответствовать только один оклад, то эта связь будет «один-к-одному».
Сущности «Отделение» и «Ставки» связаны через внешний ключ по полю «Код отделения». Т.к. одна должность может быть в разных отделениях, то эта связь будет «один-ко-многим».
Сущности «Ставки» и «Должности» связаны через внешние ключи: «Название должности», «Квалификационный уровень». Т.к. в одном отделении может быть несколько должностей, то эта связь будет «один-ко-многим».
Сущности «Размеры окладов» и «Расчет заработной платы» связаны через внешние ключи: «Название должности», «Квалификационный уровень». Т.к. должностной оклад может назначаться несколько раз одному сотруднику, если он работает совместителем, то эта связь будет «один-ко-многим».
Сущности «Штатное расписание» и «Расчет заработной платы» связаны через внешние ключи: «Код отделения», «Табельный номер». Т.к. для каждого сотрудника, находящегося на конкретной должности в месяц может производится один расчет заработной платы, то эта связь будет «один-к-одному».
4.4 Нормализация базы данных
Проанализируем отношения с учетом их первичных ключей и функциональных зависимостей для доказательства нормализации.
В отношениях «Сотрудник», «Вычеты НДФЛ», «Приказ», «Отделение», «Ставки», «Должность», «Штатное расписание», «Профессиональные группы», «Квалификационный уровень», «Надбавки», «Начисление надбавки», «Размеры окладов», «Отклонения от графика», «Табельный учет», «Удержания», «Начисление удержаний» и «Расчет заработной платы» нет повторяющихся групп данных, т.е. все значения их атрибутов неделимы. Следовательно, данные отношения находятся в первой нормальной форме (НФ).
В отношении «Приказ» уникальным является составной первичный ключ, который состоит из атрибутов: «Табельный номер» и «Номер приказа». Не ключевыми атрибутами являются: «Дата», «Вид приказа», «Содержание». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Должность» уникальным является составной первичный ключ, который состоит из атрибутов: «Название должности» и «Квалификационный уровень». Не ключевыми атрибутами являются: «Месяц», «Количество рабочих дней в месяц». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Ставки» уникальным является составной первичный ключ, который состоит из атрибутов: «Код отделения», «Название должности» и «Квалификационный уровень». Не ключевым атрибутом является: «Количество ставок». Атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Штатное расписание» уникальным является составной первичный ключ, который состоит из атрибутов: «Табельный номер», «Код отделения». Не ключевыми атрибутами являются: «Название должности», «Квалификационный уровень». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Начисление надбавки» уникальным является составной первичный ключ, который состоит из атрибутов: «Табельный номер» и «Код надбавки». Не ключевыми атрибутами являются: «Дата начисления надбавки», «Сумма по надбавке». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
В отношении «Расчет заработной платы» уникальным является составной первичный ключ, который состоит из атрибутов: «Номер расчета», «Табельный номер» и «Код отделения». Не ключевыми атрибутами являются: «Название должности», «Квалификационный уровень», «Рабочие дни», «Норма часов», «Код отклонения», «Начислено за отработанное время», «Код надбавки», «Код удержания», «Начислено аванс», «К выдаче». Каждый атрибут зависит только от полного значения ключа, и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа. Следовательно, отношение находится во 2НФ.
Логическая структура базы данных (ER – диаграмма) представлена на рисунке Б.1.
4.5 Физическое проектирование системы
На этапе логического проектирования на основе семантического анализа предметной области осуществляется разбиение БД на таблицы. При этом каждой сущности предметной области ставится в соответствие таблица, атрибутам объекта соответствуют атрибуты таблицы, а идентификатору объекта соответствует ключ таблицы.
Типы данных атрибутов сущностей приведены в таблицах 5-21.
Таблица 5 - Типы данных атрибутов сущности «Отделение»
| Отделение | |
| Атрибут | Тип данных |
| Код отделения | Числовой |
| Название отделения | Текстовый (30) |
| Источник средств | Текстовый (18) |
Таблица 6 - Типы данных атрибутов сущности «Сотрудник»
| Сотрудник | |
| Атрибут | Тип данных |
| Табельный номер | Числовой |
| ФИО | Текстовый (100) |
| Пол | Текстовый (10) |
| Дата рождения | Дата |
| Документ | Текстовый (18) |
| Номер документа | Числовой |
| Адрес | Текстовый (50) |
| Страховой номер | Числовой |
| ИНН | Числовой |
| Форма работы | Текстовый (18) |
| Резидент | Булево |
| Сведения | Текстовый (100) |
| Инвалидность | Текстовый (18) |
| Является членом профсоюза | Булево |
| Номер лицевой карточки | Числовой |
| Дата принятия на работу | Дата |
| Фотография | Объект OLE |
| Вычеты НДФЛ | |
| Атрибут | Тип данных |
| Табельный номер | Числовой |
| Код вычета личный | Числовой |
| Код вычета на детей | Числовой |
| Количество детей | Числовой |
| Код вычета на детей инвалидов | Числовой |
| Количество детей инвалидов | Числовой |
Таблица 8 - Типы данных атрибутов сущности «Приказ»
| Приказ | |
| Атрибут | Тип данных |
| Табельный номер | Числовой |
| Номер приказа | Числовой |
| Дата | Дата |
| Вид приказа | Текстовый (40) |
| Содержание | Текстовый (200) |
Таблица 9 - Типы данных атрибутов сущности «Удержание»
| Удержание | |
| Атрибут | Тип данных |
| Код удержания | Числовой |
| Наименование удержания | Текстовый(30) |
| Сумма | Числовой |
| Основания | Текстовый(100) |
Таблица 10 - Типы данных атрибутов сущности «Начисление удержания»
| Начисление удержания | |
| Атрибут | Тип данных |
| Код удержания | Числовой |
| Табельный номер | Числовой |
| Сумма по удержанию | Числовой |
| Дата начисления удержания | Дата |
| Отклонения от графика | |
| Атрибут | Тип данных |
| Код отклонения | Числовой |
| Наименование отклонения | Текстовый (100) |
Таблица 12 - Типы данных атрибутов сущности «Табельный учет»
| Табельный учет | |
| Атрибут | Тип данных |
| Табельный номер | Числовой |
| Код отклонения | Числовой |
| Начало | Дата |
| Конец | Дата |
| Всего дней | Числовой |
Таблица 13 - Типы данных атрибутов сущности «Надбавка»
| Надбавка | |
| Атрибут | Тип данных |
| Код надбавки | Числовой |
| Наименование надбавки | Текстовый (20) |
| Сумма | Числовой |
| Основания | Текстовый (100) |
Таблица 14 - Типы данных атрибутов сущности «Начисление надбавки»
| Начисление надбавки | |
| Атрибут | Тип данных |
| Табельный номер | Числовой |
| Код надбавки | Числовой |
| Дата начисления надбавки | Дата |
| Сумма по надбавке | Числовой |
Таблица 15 - Типы данных атрибутов сущности «Профессиональные
группы»
| Профессиональные группы | |
| Атрибут | Тип данных |
| Квалификационная группа | Текстовый (30) |
Таблица 16 - Типы данных атрибутов сущности «Квалификационный
уровень»
| Квалификационный уровень | |
| Атрибут | Тип данных |
| Квалификационная группа | Текстовый (30) |
| Квалификационный уровень | Текстовый (18) |
Таблица 17 - Типы данных атрибутов сущности «Должность»
| Должность | |
| Атрибут | Тип данных |
| Название должности | Текстовый (18) |
| Квалификационный уровень | Текстовый (18) |
| Месяц | Текстовый (18) |
| Количество рабочих дней в месяц | Числовой |
Таблица 18 - Типы данных атрибутов сущности «Ставки»
| Ставки | |
| Атрибут | Тип данных |
| Код отделения | Числовой |
| Квалификационный уровень | Текстовый (18) |
| Название должности | Текстовый (30) |
| Количество ставок | Числовой |
Таблица 19 - Типы данных атрибутов сущности «Штатное расписание»
| Штатное расписание | |
| Атрибут | Тип данных |
| Табельный номер | Числовой |
| Код отделения | Числовой |
| Наименование должности | Текстовый (18) |
| Квалификационный уровень | Текстовый (18) |
Таблица 20 - Типы данных атрибутов сущности «Размеры окладов»
| Размеры окладов | |
| Атрибут | Тип данных |
| Квалификационный уровень | Текстовый (18) |
| Название должности | Текстовый (18) |
| Размеры окладов | Текстовый (18) |
Таблица 21 - Типы данных атрибутов сущности «Расчет заработной платы»
| Расчет заработной платы | |
| Атрибут | Тип данных |
| Код отделения | Числовой |
| Номер расчета | Числовой |
| Квалификационный уровень | Текстовый (18) |
| Рабочие дни | Числовой |
| Норма часов | Числовой |
| Код отклонения | Числовой |
| Начислено за отработанное время | Числовой |
| Код надбавки | Числовой |
| Код удержания | Числовой |
| Начислено аванс | Числовой |
| К выдаче | Числовой |
ER – диаграмма физической структуры базы данных представлена на рисунке Б.2.
5 Обоснование целесообразности использования выбранного средства реализации
Автоматизация информационных систем должна осуществляться на основе максимально стандартизованных систем, так как это позволяет удешевить внедрение и повысить его качество.
На настоящий момент наиболее оптимальной программной системой для автоматизации учета является «1С: Предприятие 8».
Система «1С: Предприятие» является универсальной системой автоматизации экономической и организационной деятельности организаций и частных лиц. Поскольку такая деятельность может быть довольно разнообразной, система «1С: Предприятие» имеет возможность «приспосабливаться» к особенностям конкретной области деятельности, в которой она используется.
Сама платформа «1C:Предприятие 8» не является программным продуктом для конечных пользователей, которые обычно работают с одним или несколькими прикладными решениями (конфигурациями), разработанными на данной платформе. Такой подход позволяет автоматизировать различные виды деятельности, используя единую технологическую платформу «1С: Предприятие 8».
Прикладное решение (конфигурация) использует механизмы «1С: Предприятия 8» и работает только под управлением платформы, поэтому оно не может быть использовано самостоятельно, как отдельное приложение. Конечный пользователь всегда работает с системой программ «1С: Предприятие 8», которая включает в себя платформу и прикладные решения.
Разработка и модификация прикладного решения производится в специальном режиме «Конфигуратор». В данном режиме разработчик определяет общую архитектуру прикладного решения и структуру данных, создает макеты отчетов и экранные формы, пишет программные модули на встроенном языке программирования. Конечный пользователь работает в обычном режиме «Предприятие», вводит данные в базу данных, формирует отчеты и т.д.
В результате прохождения практики была изучена работа расчетного отдела медицинского учреждения, его основные задачи, направления деятельности и документация. После анализа полученных сведений было сформулировано техническое задание на разработку автоматизированной информационной системы расчета заработной платы в медицинском учреждении.
В ходе проделанной работы было проведено инфологическое проектирование, в результате чего были построены логическая модель и физическая модель системы с использованием CASE-средства ERWin. Также была разработана функциональная модель системы с использованием CASE-средства BPWin.
Список использованных источников
1. Митичкин С. А. Разработка в системе 1С: Предприятие 8.0. – М.: ООО «1С-Паблишинг», 2003. – 413 с.
2.
3. Горбаченко В.И., Убиенных Г.Ф., Убиенных А.Г. Работа с базами данных в среде Microsoft Access 2002: Лабораторный практикум. – Пенза: Изд-во Пенз. гос. ун-та, 2003.
4. Маклаков С.В. BPwin и ERwin: CASE-средства для разработки информационных систем. – http://www.isuct.ru/~ivt/books/CASE/case5/Prewords.html.
ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ СИСТЕМЫ
Приложение А
(обязательное)
ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ СИСТЕМЫ
Приложение Б
(обязательное)
