Релационен модел — СменоПланер

Релационен дијаграм

Прикачени датотеки: RelationalModel-SmenoPlaner.svg, Revised_27032026.vpp(Фајлот ми е 800кб)

Документација и дополнителен опис

Multi-tenant изолација по organization

Секој ентитет кој припаѓа на одредена организација (location, shift_presets, position, users, shift) содржи organization_id странски клуч кон табелата organization. Ова е свесна архитектурна одлука: наместо посебна база по тенант, сите организации споделуваат иста шема, а изолацијата се спроведува на апликациско ниво преку organization_id. Слагот (slug) на организацијата е уникатен и служи за URL-friendly идентификација.

UUID примарни клучеви (varchar 36)

Сите примарни клучеви се UUID вредности чувани како varchar(36), наместо auto-increment integer. Причина: UUID-а дозволуваат генерација на ID на страната на апликацијата (без round-trip до базата), погодни се за дистрибуирани системи и спречуваат откривање на бројот на записи преку секвенцијални ID-а.

position е scoped по организација

Табелата position содржи organization_id и уникатен индекс на (organization_id, name). Ова значи дека две различни организации можат да имаат позиција со исто име, но во рамки на иста организација имињата мора да бидат уникатни. Позициите се поврзани со корисници преку user_position (junction табела) и со шаблони преку shift_preset_position_requirement.

shift_preset_position_requirement — барања по позиција

Секој шаблон за смена (shift_presets) може да дефинира колку вработени од одредена позиција се потребни (required_count). CHECK ограничувањето required_count > 0 гарантира дека вредноста е секогаш позитивна. Уникатниот индекс на (shift_preset_id, position_id) спречува дупли барања за иста комбинација.

swap_request_users — junction табела за замена

Наместо колони requested_by и taken_by директно во swap_request, тие се изолирани во посебна табела swap_request_users. Причина: taken_by е nullable (вработен сè уште не ја прифатил замената), а оваа структура јасно ги разделува двете страни на процесот — кој побарал и кој прифатил. Примарен клуч е swap_request_id (1:1 врска), со три странски клучеви: кон swap_request, и двапати кон users.

CHECK ограничувања на статус полиња

leave_request.status и swap_request.status се ограничени на вредностите ('pending', 'approved', 'rejected') преку CHECK ограничувања. Ова го спречува внесот на невалидни статуси директно на ниво на базата, независно од апликациската логика.