Database
 sql >> база данни >  >> RDS >> Database

Модел на данни за заплати

Моделът с данни за заплати ви позволява лесно да изчислявате заплатата на служителите си. Как работи този модел?

Без значение дали управлявате малка или голяма компания, имате нужда от някакво решение за заплати. Това е мястото, където приложението за заплати е полезно. Освен това, колкото по-голяма е компанията, толкова по-трудно се справя с изчисленията на заплатите на служителите; тук заявлението за заплати става необходимост. За да ви помогнем да разберете всички данни, необходими за такова приложение, ще ви преведем през свързан модел на данни.

Нека видим как работи нашият модел на данни за заплати!

Модел на данни

Със създаването на този модел на данни се опитах да създам модел, който е общоприложим за всеки бизнес. Разбира се, винаги ще има разлики в регулациите, политиките на компанията и т.н., които ще изискват моделът да бъде персонализиран, за да покрие нуждите на конкретна ведомост. Въпреки това принципите, изложени в този модел, трябва да са подходящи за повечето организации.

Трябва да се отбележи, че този модел е създаден с няколко предположения:

  • Заплатите, уговорени с трудовия договор, са на година.
  • Нетните заплати (т.е. с определени суми, приспаднати за данъци и др.) се изплащат на служителите.
  • Заплатите се изплащат месечно.

Моделът на данни се състои от четиринадесет таблици и е разделен на две предметни области:

  • Employees
  • Salaries

За да разберете по-добре модела, е необходимо да преминете през всяка тематична област задълбочено.

Служители

Тази тематична област съдържа подробна информация за служителите. Състои се от девет таблици:

  • employee
  • employment_terms
  • job_title
  • job_title_history
  • department
  • department_history
  • city
  • country
  • gender

Първата таблица, която ще разгледаме, е employee маса. Той съдържа списък на всички служители и съответните им данни. Атрибутите на таблицата са:

  • id – Уникален идентификационен номер за всеки служител.
  • first_name – Първото име на служителя.
  • last_name – Фамилията на служителя.
  • job_title_id – Препраща job_title маса.
  • department_id – Препраща към department маса.
  • gender_id – Препраща gender маса.
  • address – Адресът на служителя.
  • city_id – Препраща city маса.
  • email – Имейл на служителя.
  • employment_start – Датата, на която това лице е започнало работа.

Забележете, че колоните job_title_id и department_id са излишни, тъй като информацията за текущите длъжности и отдели може да бъде достъпна от job_title_history и department_history маси. Въпреки това ще запазим тези две колони в тази таблица за по-бърз достъп до информацията.

Следва employment_terms маса. Той съхранява данни за заплатата на всеки служител, както е договорено в трудовия договор, и как тя се е променила с течение на времето. Атрибутите на таблицата са:

  • id – Уникален идентификационен номер за всеки набор от условия за работа.
  • employee_id – Препраща към employee маса.
  • agreed_salary – Заплатата, посочена в трудовия договор.
  • salary_start_date – Начална дата на договорената заплата.
  • salary_end_date – Крайна дата на договорената заплата. Това може да бъде NULL, тъй като заплатата може да няма планирана промяна.

job_title таблицата е списък на длъжностите, които могат да бъдат присвоени на различни служители на компанията, напр. анализатор, шофьор, секретар, директор и др. Таблицата има следните атрибути:

  • id – Уникален идентификатор за всяка длъжност.
  • job_title – Името на длъжността. Това е алтернативният ключ.

Нуждаем се и от таблица, в която да съхраняваме историята на длъжностите на всеки служител. Имаме нужда от това, защото служителите могат да бъдат повишени, понижени или преназначени в рамките на компанията. job_title_history таблицата ще управлява тази информация и ще се състои от следните атрибути:

  • id – Уникален идентификатор за историческия запис на длъжността.
  • job_title_id – Препраща job_title маса.
  • employee_id – Препраща към employee маса.
  • start_date – Датата, на която служителят за първи път е заемал тази длъжност.
  • end_date – Когато служителят е престанал да има тази длъжност. Това може да бъде NULL, тъй като служителят в момента може да притежава тази длъжност.

Комбинацията от job_title_id , employee_id и start_date е алтернативният ключ за горната таблица. На даден служител може да бъде присвоена само една длъжност на дадена дата.

Следващата таблица е department маса. Това просто ще изброи всички отдели на компанията, като ИТ, счетоводство, правни въпроси и т.н. Той съдържа два атрибута:

  • id – Уникален идентификатор за всеки отдел.
  • department_name – Името на всеки отдел. Това е алтернативният ключ.

Служителите също могат да сменят отделите в компанията. Следователно, ние трябва да имаме department_history маса. Тази таблица ще съхранява следното:

  • id – Уникален идентификатор за исторически запис на този отдел.
  • department_id – Препраща към department маса.
  • employee_id – Препраща към employee маса.
  • start_date – Датата, на която служителят е започнал работа в отдел.
  • end_date - Датата, на която служител е спрял да работи в този отдел. Това може да бъде NULL, защото служителят може да работи там.

Комбинацията от department_id , employee_id и start_date е алтернативният ключ. Един служител може да работи само в един отдел наведнъж.

Следващата таблица, за която ще говорим, е city маса. Това е списък на всички подходящи градове. Той има следните атрибути:

  • id – Уникален идентификатор за всеки град.
  • city_name – Името на града.
  • country_id – Препраща country маса.

country таблицата е следващата в нашия модел. Това е просто списък с държави и съдържа следната информация:

  • id – Уникален идентификационен номер за всяка държава.
  • country_name – Името на държавата. Това е алтернативният ключ.

Последната таблица в тази тематична област е gender маса. Тази таблица изброява всички полове. Той съдържа следните атрибути:

  • id – Уникален идентификационен номер за всеки пол.
  • gender_name – Името на пола.

Нека сега анализираме втората тематична област.

Заплати

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

  • salary_payment
  • working_hours_log
  • working_hours_adjustment
  • adjustment
  • adjustment_amount

Сега нека разгледаме всяка таблица.

Първата таблица е salary_payment . Той съдържа всички релевантни подробности за заплатата, изплащана на всеки служител и има следните атрибути:

  • id – Уникален идентификационен номер за всяка заплата.
  • employee_id – Препраща към employee маса.
  • gross_salary – Брутната заплата, която ще бъде основа за по-нататъшни корекции.
  • net_salary – Нетната заплата (т.е. сумата, получена от служителя след различни удръжки).
  • salary_period – Периодът, за който се изчислява и изплаща заплатата.

Вторият е working_hours_log маса. Той съдържа данни за броя на отработените часове от всеки служител, които могат да повлияят на определени корекции на заплатите. Тази таблица има следните атрибути:

  • id – Уникален идентификатор за всеки запис в журнала.
  • employee_id – Препраща към employee маса.
  • start_time – Времето, в което служителят е влязъл, т.е. е започнал работа за деня.
  • end_time – Когато служителят излезе от системата. Може да е NULL, защото няма да знаем точния час, докато служителят не излезе.

Следващата таблица, която ще анализираме, е working_hours_adjustment . Тази таблица ще се използва само при изчисляването на корекции въз основа на отработените часове, т.е. тези, които имат TRUE стойност в is_working_hours_adjustment в adjustment маса. Атрибутите са както следва:

  • id – Уникален идентификатор за всяка корекция.
  • working_hours_log_id – Препраща към working_hours_log маса.
  • adjustment_id - Препраща към adjustment маса.
  • salary_payment_id – Препраща към salary_payment маса. Тази стойност може да бъде NULL, тъй като salary_payment_id ще се използва само веднъж месечно, когато започнем изчисляване на заплатата.
  • adjustment_amount – Размерът на корекцията.
  • adjustment_percentage – Процентната сума на корекцията. Това ще се използва за исторически цели, тъй като процентът може да се промени с течение на времето.

Следващата таблица, за която ще говорим, е adjustment маса. Той съдържа информация за всички корекции, използвани за изчисляване на заплатата, което означава всички данъци и вноски, които оказват влияние върху размера на заплатата. Също така, той ще съдържа всички корекции, които зависят от отработените и неотработените часове, като бонуси, извънреден труд, отпуск по болест и отпуск по майчинство/бащинство. За целта ни трябват следните данни:

  • id – Уникален идентификатор за всяка корекция.
  • adjustment_name – Име, описващо тази корекция.
  • adjustment_percentage – Процентната сума на конкретната корекция.
  • is_working_hours_adjustment – Това е маркировка на флага, ако корекцията директно зависи от работното време, напр. извънреден труд, отпуск по болест и др.
  • is_other_adjustment – Това е корекции за маркиране на флаг, които не пряко зависят от отработените часове, като данъчни облекчения, социалноосигурителни вноски, вноски на работодателя и др.

След това се нуждаем от adjustment_amount маса. Ще се използва за изчисляване на всички корекции на заплатите, с изключение на тези, които вече са в working_hours_adjustment , т.е. тези, които имат TRUE стойност в is_other_adjustment в adjustment маса. Таблицата съдържа следните атрибути:

  • id – Уникален идентификатор за всеки запис на сумата за корекция.
  • salary_payment_id – Препраща към salary_payment маса.
  • adjustment_id – Препраща към adjustment маса.
  • adjustment_amount – Сумата на всяка изчислена корекция.
  • adjustment_percentage - Процентната сума на корекцията. Ще се използва за исторически цели, тъй като процентът може да се променя с течение на времето.

Нека ви дам пример за това как таблиците working_hours_log , working_hours_adjustment , adjustment и adjustment_amount работят заедно за изчисляване на заплата. Всеки ден служителят записва кога пристига на работа и когато си тръгва. Тези данни могат да се видят в working_hours_log маса. Да приемем, че нашият служител е работил 10 часа извънреден труд за един месец и според политиката на компанията той или тя ще получава 20% повече на час за всеки час извънреден труд. Чрез препратка към adjustment таблица, ще можем да намерим необходимата корекция, т.е. извънреден труд, който ще има определен процент (20%). Ще имаме и is_working_hours_adjustment зададен на TRUE. Като използваме данни от тези две таблици, ще можем да изчислим корекцията и да я съхраним в working_hours_adjustment маса.

Сега можем да изчислим всички други корекции, които не зависи от отработените часове. Това ще бъде направено в adjustment_amount маса. Точно както направихме по-горе, ще се позоваваме на adjustment таблица и намерете корекциите, от които се нуждаем – напр. данъчни приспадания, социалноосигурителни вноски или вноски на работодателя – и съответните им проценти. is_other_adjustment флаг в adjustment таблицата ще бъде настроена на TRUE за тези корекции.

Въз основа на тези изчисления можем да съхраняваме данни за брутната и нетната заплата в salary_payment маса.

Преглеждайки този пример, ние покрихме всичко в нашия модел на данни!

Харесахте ли модела с данни за заплати?

Опитах се да създам модел, който може да се използва в почти всички ситуации. Невъзможно е обаче да се включат всички специфични параметри, които влияят върху изчисляването на заплатата в статия с тази дължина. Покривайки общи принципи, се опитах да направя този модел полезен като солидна основа за вашия модел на данни за заплати.

Какво мислите за модела на данни за заплати? Приложимо ли е като решение за вашите нужди от заплати? Измислихте ли нещо различно? Има ли конкретни проблеми, които сте открили, които биха променили значително модела на данни? Кажете своето мнение в секцията за коментари.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. OGG-01224 Адресът вече се използва

  2. Въведение в Azure без сървър

  3. Сравняване на обекти по стойност. Част 6:Прилагане на структурното равенство

  4. Какво е ключ-кандидат в дизайна на база данни?

  5. Интегриран модел на транспортни данни