Розробка бази даних інформаційної системи для автоматизації, обліку відрахувань на медичне cтрахування

     1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ 

     1.1. Опис предметної області 

    Розглядається процедура медичного страхування  працівників трикотажного підприємства. Страхування здійснюється за рахунок відрахувань коштів у страховий фонд. Відрахування у страхову компанію проходять через бухгалтерію фірми. Перелік коштів здійснюється щомісячно (з заробітної плати кожного працівника, щомісячно відраховується 3.9% у страховий фонд). На підприємстві працюють робітники, для кожного з яких в базі виділені стандартні дані (прізвище, ім’я, по-батькові, адреса, телефон). По кожному робітнику ведеться облік заробітної плати, облік робочого часу працівників, а також лікарняних листів.

Найважливішими  компонентами для даної сфери  є:

• робітники;
• кошти;
• облік.

 

             На рис. 1 наведена спрощена схема бізнес процесу.

 
 
 
 
 
 
 
 
 

     Рис. 1.1 - Узагальнена схема бізнес-процесу

     Описані виробничі процеси виконуються  працівниками даного підприємства, організаційна  структура, якого наведена на рис. 1.2: 

 
 

     Рис. 1.2 – Організаційна схема підприємства 

     Оскільки потрібно вести облік відрахувань на медичне страхування, то розгляданню підлягають процеси організаційної роботи бухгалтерії з даного питання.  З кожного робітника залежно від нарахувань заробітної плати відраховується відсоток (3.9%) на його медичне страхування. Заробітна плата робітника залежить від вартості робочої зміни та займаної посади працівника. Відсоток відрахувань від заробітної плати залежить від умов укладеного договору між підприємством і страховою компанією. Згідно з умов договору являється те, що компанія повинна виплачувати кожного місяця певну суму.

     На  основі аналізу предметної області та відповідно до стандарту IDEF0 засобами пакету AllFusion Process Modeler створена модель AS-IS, яка описує стан модельованої інформаційної системи на момент створення моделі. Розроблена концептуальна діаграма відрахувань коштів у страхову компанію з точки зору директора підприємства наведені на рис. 1.3.

  

 

     Рис. 1.3 – Концептуальна діаграма відрахування коштів у страхову компанію 

     На  етапі декомпозиції виділені дві  роботи, які відбуваються в межах  даного випадку:

• нарахування заробітної плати;
• відрахування відсотку у страховий фонд.

Детальні  послуги медичного страхування  не розглядаються, оскільки  вони виходить за межі поставленої задачі, що розглядається.

     Вищенаведена  концептуальна модель показує зв’язок  між відрахуванням коштів підприємства та наданням послуг страховою компанією. Він полягає в тому, що в залежності від кількості робочих змін працівника підприємства та вартості його тарифної ставки нараховується заробітна плата, від якої відраховується певний відсоток. Фінансово-економічний відділ підприємства передає кошти згідно договору на рахунок страхової компанії. Після чого, надаються послуги медичного страхування.

     На  рис. 1.4 наведена діаграма декомпозиції, що віддзеркалює внутрішні зв’язки  в межах підприємства. 

   

 

     Рис. 1.4 – Діаграма декомпозиції 

     Вхідними  даними для поставленої задачі є:

• Інформація про кількість відпрацьованих змін робітників;
• журнал обліку фінансової діяльності.

          Вихідними даними є:

• інформація про кошти, переведені на рахунок страхової компанії;
• вихідна документація.
 

     Дані  процеси в основному відбуваються на території складального заводу (склад  та складальний цех). Замовлення комплектуючих на заводі-виробнику виходить за межі підприємства. В розглянутому випадку організація спільного використання даних працівниками складу та складального цеху основана на локальній мережі та сервері БД.

     Мотивація діяльності підприємства зумовлена  наступними бізнес-задачами:

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

В процесі  аналізу предметної області були виділені головні елементи, які необхідні для побудови інформаційної моделі підприємства (рис. 1.3):

 

     2. ПРОЕКТУВАННЯ БАЗИ ДАНИХ 

     2.1. Постановка задачі 

     Розробити базу даних інформаційної системи для обліку відрахувань на медичне страхування. БД повинна містити інформацію про:

• робітників (код робітника, ПІБ, вік, посада, адреса, телефон);
• розрахунок заробітної плати (код робітників, вартість зміни, кількість відпрацьованих змін, назва місяця).

     Створена  база даних повинна надавати користувачеві  інформацію про:

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

     2.2. Розробка логічної моделі

    Логічна модель віддзеркалює дані предметної області як сукупність сутностей  та зв’язків між ними. Сутність складається з логічно зв’язаних атрибутів,  які є кількісними та якісними характеристиками предметної області. У заданій предметній області можна виділити три сутності: РОБІТНИКИ, ЖУРНАЛ, МІСЯЦІ.

    Сутності  вибираються на основі опису предметної області, спираючись на функціональну залежність між атрибутами. 
 
 
 
 

     2.3. Вхідна інформація

    База  даних інформаційної системи  повинна містити інформацію про  робітників, розрахунок заробітної плати, місяці року відповідно пп. 2.1. Тому документи, які повинні бути на вході:

• журнал обліку, що містить дані про працівника та відпрацьовані зміни;
• платіжна відомість для передачі коштів.

     Ці  документи-джерела є довідковою інформацією. Довідкова інформація міститься у наступних таблицях 2.1 – 2.2: 

     Таблиця 2.1 – Робітники

 

     Таблиця 2.2 – Місяці

 

    Крім  довідкової інформації, є також облікова інформація. Для даної предметної області це інформація про:

• журнал обліку заробітної плати (табл. 2.3).

 

Таблиця 2.3 – Журнал

     2.4. Вихідна інформація

   Вихідною  інформацією є дані, які користувач отримує в процесі роботи з  системою. База даних містить інформацію про всіх робітників, які працюють на підприємстві,  а також про розрахунок заробітної плати. 

     2.5. Визначення функціональних залежностей між сутностями

    З аналізу документу «Робітники» (табл. 2.1) виділяється одна сутність – РОБІТНИК, в якій атрибути «ПІБ робітника», «Вік», «Посада», «Адреса» та «Телефон» є довідковими і кожен з них залежить тільки від ключового атрибуту – «Id робітника» (ідентифікаційний номер робітника).

    На  основі аналізу документу «Журнал» (табл. 2.3) утворено  сутність – ЖУРНАЛ, що має атрибути -  «Код робітника», «Вартість зміни», «Кількість відпрацьованих змін», «Код місяця» та «Нараховано».

    Аналогічно  на основі аналізу документу «Місяці» (табл. 2.2) утворено сутність – МІСЯЦЬ, що має атрибути – «Назва» та «Кількість днів». Для ідентифікації місяця обраний її Id (ідентифікаційний номер).

    Визначені сутності пов’язані між собою наступним чином.

    Зв’язок між сутностями РОБІТНИК – ЖУРНАЛ характеризуються як «один-до-багатьох», оскільки один робітник отримує заробітну плату щомісячно. Зв’язок між ними реалізується за ідентифікаційним номером робітника («Id робітника»), який є унікальним для сутності РОБІТНИК.

    Аналогічно  встановлюється зв’язок між сутностями МІСЯЦЬ – ЖУРНАЛ (показник кардинальності зв’язку - «один-до-багатьох», зв’язок встановлюється за ідентифікаційним номером місяця – «Id місяця»).

    Зв’язки між сутностями наведені в таблиці 2.6: 
 
 
 

    Таблиця 2.6 – Зв’язки сутностей

 

На  рис. 2.7 наведена розроблена логічна модель предметної області.

Рис. 2.7 – Логічна модель предметної області

  Наведена  структура відповідає вимогам до побудови реляційної моделі. Виконуються умови:

1-ї нормальної  форми: 

• кожне поле є неподільним;
• відсутні поля та групи полів, що повторюються.

2-ї нормальної  форми:

• виконані умови 1-ї нормальної форми;
• первинні ключі однозначно визначають об’єкти;
• всі поля сутностей залежать від первинних ключів;
• первинні ключі не є надлишковими.

3-ї нормальної  форми:

• виконані умови 2-ї нормальної форми;
• жодне не ключове поле не залежить від іншого не ключового поля;
• відсутні транзитивні зв’язки всередині таблиць.

   Завдяки цьому не виникає ефекту надмірності даних, що свідчить про нормалізованість  отриманої логічної  моделі. 

     2.6. Вибір та опис використаної СУБД