Changes between Version 5 and Version 6 of Normalization

Timestamp:

09/19/25 12:06:32 (17 hours ago)

Author:

215010

Comment:

--

Normalization

@@ -65 +65 @@
 === Анализа според покривачи
 
-Од анализата се забележуваат:
-
-room_number е уникатен само во комбинација со building_id → слаб ентитет.
-
-Во Reservation нема експлицитно модел на врска со Customer, Manager и Room → треба релации за интегритет.
-
-Во Payment, amount е транзитивно зависно од Reservation (amount = цена * број на ноќи).
-
-Во Service, моментално нема детална историја (само статус).
+Од функционалните зависности и шемата, можеме да идентификуваме дека релацијата R вклучува различни ентитети кои се поврзани преку надворешни клучеви и делумни зависности. За да го идентификуваме кандидатскиот примарен клуч за целата релација
+R, мора да се осигураме дека: сите не-примарни атрибути се функционално зависни од кандидатскиот примарен клуч и кандидатскиот клуч мора да биде уникатен низ целата релација.
+
+Гледајќи ги функционалните зависности и врски, кандидатскиот примарен клуч за целата релација R може да се заклучи како:
+
+**{reservation_id, p_id, service_id, room_number, building_id}**
+
+- reservation_id: Уникатно идентификува резервација.
+
+- p_id: Уникатно идентификува плаќање.
+
+- service_id: Уникатно идентификува услуга.
+
+- room_number и building_id: Заедно, тие идентификуваат одредена соба во одредена зграда.
+
+Овој сет на атрибути треба да може уникатно да го идентификува секој запис во релацијата R, осигурувајќи дека нема редундантност и нема двосмисленост.
 
 === Анализа на нормални форми
 ==== 1 НФ
 
-Тековниот дизајн е во 1NF: атомски атрибути, нема повеќевредносни атрибути складирани како едно поле.
+За да постигнеме 1NF, мора да се осигураме дека сите атрибути во секоја торка се атомски, што значи дека не постојат повеќевредносни атрибути или композитни атрибути.
+
+===== Проблем во тековната шема:
+
+Композитни атрибути како address (кои може да имаат повеќе компоненти како што се улица, град итн.).
+
+===== Решение:
+
+Разделување на повеќевредносните атрибути во посебни колони.
+
+===== Применето 1NF:
+
+Адресата во Hotel_Building треба да се подели на атомски компоненти: улица, град и поштенски код.
+
+Табела Hotel_Building:
+
+building_id, street, city, zip_code, floors, num_rooms
+
+Сите атрибути во секоја табела ќе бидат атомски, што значи дека нема да постојат дополнителни сложени или повеќевредносни атрибути.
 
 ==== 2 НФ
 
-Нема парцијални зависности (освен кај Room, каде клуч е составен (building_id, room_number)).
+За да постигнеме 2NF, треба да отстраниме делумни зависности. Атрибутот што не е примарен мора да биде целосно функционално зависен од целиот примарен клуч, а не само од негов дел.
+
+===== Проблем во тековната шема:
+
+Во Reservation, атрибутите како user_id, manager_id и room_number се делумно зависни само од дел од примарниот клуч (т.е. reservation_id), а не од целиот примарен клуч.
+
+===== Решение:
+
+Преместување на атрибутите што зависат од дел од примарниот клуч во посебни табели за да ги елиминирате делумните зависности.
+
+===== Применето 2NF:
+
+Креирање табела Customer со user_id како примарен клуч и атрибути поврзани со клиентот.
+
+Креирање табела Manager со user_id како примарен клуч и атрибути поврзани со менаџерот.
+
+Изменување на Reservation за да ги чува само атрибутите што зависат од reservation_id и преместување на user_id (клиент) и manager_id во нивните соодветни табели.
+
+По 2NF:
+
+Customer: user_id, first_name, last_name, phone, email, password
+
+Manager: user_id, first_name, last_name, phone, email, password
+
+Reservation: reservation_id, start_date, end_date, reserv_date, status, room_number, building_id, customer_id, manager_id
 
 ==== 3 НФ
 
-Проблеми:
-
-Reservation – amount (треба да се изведува од Room.price_per_night × број на ноќи → не треба да стои во Payment како атрибут).
-
-Reservation моментално чува и customer_id, и manager_id → транзитивна зависност преку User.
-
-Подобрувања за да се задоволи 3 НФ
-Reservation – Order Cost
-
-Да не се чува amount во Payment, туку да се пресметува.
-
-{{{#!sql
-ALTER TABLE Payment DROP COLUMN amount;
-}}}
-Да се додава VIEW:
-{{{#!sql
-CREATE VIEW reservation_total AS
-SELECT r.reservation_id,
-       (EXTRACT(DAY FROM r.end_date - r.start_date) * rm.price_per_night) AS total_cost
-FROM Reservation r
-JOIN Room rm ON r.room_number = rm.room_number AND r.building_id = rm.building_id;
-}}}
-Service – историја на статуси
-{{{#!sql
-CREATE TABLE service_history (
-    history_id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
-    service_id BIGINT NOT NULL,
-    status VARCHAR(70) NOT NULL,
-    changed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
-    FOREIGN KEY (service_id) REFERENCES Service(service_id)
-);
-}}}
+За да постигнеме 3NF, мора да ги отстраниме транзитивните зависности. Непримарниот атрибут не смее да зависи од друг непримарен атрибут.
+
+===== Проблеми во тековната шема:
+
+Во Payment, user_id индиректно одредува атрибути како first_name и last_name, создавајќи транзитивна зависност.
+
+===== Решение:
+
+Отстранување на транзитивните зависности со креирање посебни табели за User (веќе направено во 2NF) и осигурувајќи се дека секоја табела ги складира само атрибутите што директно зависат од примарниот клуч.
+
+===== Применето 3NF:
+
+Во табелата Payment, складираме само p_id, p_method, amount, p_date и reservation_id. До user_id може да се пристапи преку reservation_id, па затоа не треба да се чува во табелата Payment.
+
+===== По 3NF:
+
+Payment: p_id, p_method, amount, p_date, reservation_id
+
 ==== BCNF
-Прекршоци
-
-email во Hotel_User треба да е уникатен → веќе има UNIQUE.
-
-phone исто така треба да е уникатен (еден број = еден корисник).
-
-Во Room, комбинацијата (building_id, room_number) е единствен идентификатор.
-{{{#!sql
-ALTER TABLE Hotel_User ADD CONSTRAINT uq_phone UNIQUE(phone);
-
-ALTER TABLE Room ADD CONSTRAINT uq_room UNIQUE(building_id, room_number);
-}}}
+
+За да се постигне BCNF, мора да се осигураме дека секоја детерминанта во релацијата е клуч-кандидат, односно За секоја функционална зависност: A→B, A мора да биде клуч-кандидат.
+
+===== Проблем во тековната шема:
+
+Во табелата Service, функционалната зависност:
+
+service_id → service_type, service_date, service_status, staff_id, room_number, building_id
+
+Оваа функционална зависност покажува дека service_id ги одредува service_type, service_date и service_status, но room_number и building_id не се дел од клучот-кандидат. Така, room_number и building_id се не-примарни атрибути кои зависат од service_id, создавајќи потенцијално прекршување на BCNF.
+
+===== Решение за BCNF:
+
+
+За да го решиме ова прекршување, треба да се осигураме дека секоја детерминанта е клуч-кандидат.
+
+room_number и building_id се одредени од композитниот клуч (room_number, building_id) во табелата Room, што е клуч-кандидат.
+
+Треба да ја отстраниме зависноста од room_number и building_id од табелата Service бидејќи овие атрибути се веќе одредени од табелата Room.
+
+===== По примена на BCNF:
+
+Табелата Service ќе ги чува само:
+
+service_id, service_type, service_date, service_status и staff_id.
+
+Табелата Room ќе продолжи да ги чува деталите поврзани со собата, вклучувајќи го room_number и building_id.
+
+Со ова, сите не-примарни атрибути во табелата Service зависат единствено од клучот-кандидат service_id.
+
+===== Конечни табели во BCNF:
+
+По примената на BCNF и решавањето на сите проблеми, конечната шема за засегнатите табели изгледа вака:
+
+Hotel_Bidling: building_id, street, city, zip_code, floors, num_rooms
+
+Room: room_number, building_id, room_type, number_of_beds, price_per_night, available
+
+Customer: user_id, first_name, last_name, phone, e-mail, password
+
+Manager: user_id, first_name, last_name, phone, e-mail, password
+
+Reservation: reservation_id, start_date, end_date, reserv_date, status, customer_id, manager_id, room_number, building_id
+
+Payment: p_id, p_method, amount, p_date, reservation_id
+
+Service: service_id, service_type, service_date, service_status, staff_id