= Креирање на база

== DDL Скрипта за креирање на табелите
[attachment:schema.sql DDL]


= Вметнување на податоци - DML =

== DML Скрипта за вметнување на податоци
[attachment:inserts.sql DML]


== Статички табели ==

=== Species, Breed ===
За разлика од останатите статички табели, овие '''не''' се внесени преку `INSERT INTO ... VALUES`, туку се вчитани од надворешни CSV-датотеки (`species.csv`, `breed.csv`). Мора да се вчитат пред `Pet` генерирањето, бидејќи `Pet` и `Breed` зависат од нив преку FK.

=== Supplier, Category, Room_Type, Service ===
Внесени директно преку `INSERT INTO ... VALUES` - по 5 добавувачи, 5 категории, 5 типови соби, 8 сервиси.

=== Enum lookup табели ===
Единаесет табели (`OrderStatus`, `ReservationStatus`, `ServiceReservationStatus`, `PaymentMethod`, `PaymentStatus`, `DeliveryStatus`, `DeliveryTimeSlot`, `PetDeliveryStatus`, `PetDeliveryDestination`, `MedicalRecordStatus`, `DateStatus`) - внесени преку `INSERT INTO ... VALUES`.

=== Hotel ===
10 хотели, внесени статички.

----

== Генерирани табели ==

=== Employee ===
300 записи (~30 по хотел). Имиња по случаен избор од привремени табели `first_names_male`/`first_names_female`/`last_names`. Улога, телефон и e-mail генерирани преку `random()`; датум на вработување во опсег до ~2000 дена наназад.

=== Room ===
2,500 записи (250 по хотел). Број на соба составен од хотелски id + буква (A/B/C) + бројка; тип на соба циклично распределен преку `Room_Type`.

=== Customer ===
150,000 записи. Истата шема на генерирање имиња како кај Employee; адреса избрана од привремена табела `addresses`; датум на регистрација до ~1500 дена наназад.

=== Product ===
500 записи. Име составено од фиксна листа производи + реден број; категорија мапирана според фиксен пар име->категорија; добавувач избран случајно преку `ORDER BY md5(...)`.

=== Pet ===
200,000 записи. Име избрано од фиксна листа од 30 имиња (циклично); вид и раса избрани случајно и меѓусебно усогласени (расата секогаш припаѓа на избраниот вид); сопственик поврзан случајно со постоечки клиент.

=== "Order" ===
45,000 записи. Датум, статус (id 1–4) и сума по случаен избор; клиент и хотел поврзани случајно.

=== OrderProduct ===
~23,000 записи (лимитирано на 23,000 нарачки). Количина и единечна цена по случаен избор.

----

== Batch-генерирани табели ==

=== Reservation ===
10,000,000 записи, 100 итерации × 100,000. Статусите се распределени преку фиксна тежинска табела (6/15 confirmed, 4/15 completed, 2/15 pending, 2/15 cancelled, 1/15 no-show). `reservation_date` е поставен на датумот на регистрација на клиентот + случаен офсет (7–507 дена), со цел да остане конзистентен со `RoomReservation.check_in_date`. Забелешки исто така се доделуваат преку фиксна листа со псевдослучаен избор.

=== RoomReservation ===
10,000,000 записи, 100 итерации × 100,000. Секоја резервација добива точно една соба (`UNIQUE(reservation_id)`); должина на престој 1–6 ноќи.

'''Проверка по вчитување:'''
{{{#!sql
SELECT COUNT(*) FROM RoomReservation; -- ~10,000,000
SELECT MIN(check_in_date), MAX(check_out_date) FROM RoomReservation; -- 2015–2028
}}}

=== Date ===
~11,870,000 записи, генерирани по опсег на `room_id` (batch од 100 соби). Два чекора по опсег:
 1. '''Occupied''' ноќи - извлечени директно од `RoomReservation` преку `generate_series` на секој опсег check_in–check_out.
 2. '''Available/Maintenance''' - пополнува ги преостанатите датуми (2015-01-01 до 2027-12-31) за секоја соба, со тежина 3:1 available:maintenance (`ON CONFLICT DO NOTHING`, за да не ги пребрише веќе внесените occupied редови).

=== ServiceReservation ===
~9,000,000 записи. 60% од резервациите со собa добиваат 0 сервиси, 35% 1 сервис, 18% 2 сервиси, 7% 3 сервиси (кумулативна распределба преку `random()`). `scheduled_date` паѓа во опсегот на самиот престој; `scheduled_time` избран од 9 фиксни термини (09:00–17:00). Сервисот по резервација е избран преку детерминистичка хеш-функција од `reservation_id`.

=== Payment ===
~6,000,000 записи, 100 итерации × 100,000. Генерирани '''само''' за резервации со `status_id IN (1, 2)` (confirmed/completed) - оттука бројот на плаќања е помал од вкупниот број резервации. Начин на плаќање и статус на плаќање избрани случајно (статусот со тежина: 4/6 completed, 1/6 refunded, 1/6 pending).

----

== Помошни/зависни табели ==

=== Employee_Service, Product_Service ===
Врски многу-кон-многу, генерирани преку `generate_series` + случаен избор со `DISTINCT` (дупликатите се отфрлаат преку `ON CONFLICT DO NOTHING`), па конечниот број редови може да е нешто помал од целната бројка во `generate_series`.

=== Review ===
150,000 записи. Оценката (1–10) е избрана случајно; коментарот се избира од една од 5 категории текст (во зависност од опсегот на оценката: 9–10, 7–8, 5–6, 3–4, 1–2), секоја со по 10 варијанти.

=== MedicalRecord ===
300,000 записи. Име на ветеринар составено од "Dr." + случајно презиме; статус, алергии, лекови, белешки и дијагноза избрани од фиксни листи (со можност за `NULL` кај алергии/лекови/белешки).

=== PetDelivery ===
80,000 записи (лимитирано на првите 80,000 резервации по случаен редослед). Време на достава во последните 365 дена; статус и дестинација избрани псевдослучајно.

=== Delivery ===
Генерирана за секој ред од `OrderProduct` (join кон `"Order"` за `hotel_id`) - термин и статус на достава избрани случајно.

----