Changes between Version 3 and Version 4 of DatabaseCreation

Timestamp:

07/02/26 01:56:32 (4 days ago)

Author:

231024

Comment:

Додадена DML документација

DatabaseCreation

@@ -4 +4 @@
 [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`) - термин и статус на достава избрани случајно.
+
+----
+
+
+
+