= Релационен модел

== ER Дијаграм

[[Image(PaP_19_04_2026.png, width=100%)]]

== Дополнителен опис

Табелите `Category`, `Room_Type`, `Species` и `Breed` служат за дефинирање на статични (lookup) податоци во системот. Овие ентитети се издвоени во посебни табели со цел да се постигне нормализација и да се избегне повторување на податоци. На пример, `Category` овозможува централизирано управување со типовите на производи, што го олеснува нивното менување и проширување без потреба од измени во повеќе записи. Слично, `Room_Type` овозможува флексибилно дефинирање на типови на соби и нивните цени, што е подобро отколку цената да се чува директно во `Room`, бидејќи повеќе соби можат да делат ист тип.

`Species` и `Breed` се моделирани како посебни табели со релација 1:N со цел да се избегне повторување на текстуални вредности и да се овозможи конзистентност при внес на податоци. Ова исто така овозможува лесно додавање нови видови и раси без влијание врз постоечките записи.

Табелата `Product` содржи информации за производите и е поврзана со `Category` и `Supplier`. `Supplier` ги содржи сите информации за добавувачите, што спречува повторување доколку повеќе производи доаѓаат од ист добавувач. Ваквиот дизајн го олеснува и ажурирањето на податоците за добавувачите.

Табелата `Order` претставува нарачка направена од хотелот. Таа е моделирана како посебен ентитет за да се овозможи следење на историјата на набавки, статуси на нарачки и нивна обработка независно од самите производи.

Во табелата `OrderProduct` имаме M:N врска помеѓу `Order` и `Product`, која е разрешена преку посебна табела. Во неа се чуваат количината и единечната цена на производ во дадена нарачка. Овој пристап е избран бидејќи една нарачка може да содржи повеќе производи и еден производ може да се појави во повеќе нарачки. Дополнително, чувањето на `unit_price` во оваа табела овозможува историска конзистентност, односно цената во моментот на нарачка да остане непроменета дури и ако се промени основната цена во `Product`.

Табелата `Delivery` ги поврзува нарачките со хотелот и го следи процесот на испорака. Таа е издвоена од `Order` за да се овозможи флексибилност. Една нарачка може да има различни состојби на испорака, или во иднина да се поддржат повеќе испораки по една нарачка. Табелата е во релација со `OrderProduct` за да овозможи пратење на статусот и датумот на испорака на секој поединечен производ.

Табелата `Reservation` претставува агрегат кој ги поврзува `Customer`, `Pet` и `Employee`. Овој дизајн овозможува:
* следење кој клиент направил резервација
* за кое милениче се однесува
* кој вработен е одговорен
Табелата содржи и статус, цена и белешки, што ја прави главен извор на информации за престојот.

`RoomReservation` ги чува датумите на пријавување и одјавување и ја поврзува резервацијата со соба.

`ServiceReservation` ги чува закажаните услуги. Оваа табела е потребна бидејќи една резервација може да вклучува повеќе услуги во различни термини.

`PetDelivery` ги чува информациите за транспорт на миленичето. Оваа функционалност е издвоена бидејќи не секоја резервација вклучува достава, па со тоа се избегнуваат null вредности во `Reservation`.

Табелата `Payment` е поврзана директно со `Reservation`. Секоја резервација може да има повеќе уплати за кои се чува датум, износ, метод на плаќање и статус.

Табелата `Employee_Service` е резултат на M:N релација помеѓу `Employee` и `Service`. Еден вработен може да врши повеќе услуги, а една услуга може да ја вршат повеќе вработени.

`Product_Service` дефинира кои производи се потребни за одредена услуга. Табелата се користи за пресметка на трошоци и анализа на потрошувачка.

Табелата `MedicalRecord` ги чува медицинските записи за секое милениче и е поврзана со `Pet` во 1:N релација. Овој дизајн овозможува секое милениче да има повеќе записи низ времето, што е важно за следење на историјата и обезбедување на соодветна грижа.

Табелата `Review` овозможува клиентите да оставаат рецензии за хотелот.

Табелата `Date` служи за следење на достапноста на собите по датум. Овој пристап е избран наместо динамичко пресметување со цел:
* побрзо пребарување
* поедноставна логика за проверка на достапност
* можност за предгенерирање на календар на достапност


Линк до vpp на дијаграмот: [attachment:RelationalModel-PaP.vpp RelationalModel-PaP.vpp]