Changes between Initial Version and Version 1 of Normalization


Ignore:
Timestamp:
09/15/25 00:45:56 (3 weeks ago)
Author:
215010
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Normalization

    v1 v1  
     1== Определување функционални зависности
     2
     3R = {user_id, first_name, last_name, phone, email, password, reservation_id, start_date, end_date, reserv_date, status, building_id, address, city, floors, num_rooms, room_number, room_type, number_of_beds, price_per_night, available, service_id, service_type, service_date, service_status, p_id, p_method, amount, p_date}
     4
     5=== Функционални зависности
     6
     7Users
     8user_id → first_name, last_name, phone, email, password
     9
     10Customer (extends User)
     11user_id → {customer role}
     12
     13Manager (extends User)
     14user_id → {manager role}
     15
     16Staff (extends User)
     17user_id → {staff role}
     18
     19Hotel Building
     20building_id → address, city, floors, num_rooms
     21
     22Room (слаб ентитет)
     23(building_id, room_number) → room_type, number_of_beds, price_per_night, available
     24
     25Reservation
     26reservation_id → start_date, end_date, reserv_date, status, user_id (customer), manager_id, room_number, building_id
     27
     28Payment
     29p_id → p_method, amount, p_date, reservation_id, customer_id
     30
     31Service
     32service_id → service_type, service_date, service_status, staff_id, room_number, building_id
     33 
     34=== Класификација на атрибути
     35
     36Лево – атрибути кои одредуваат други \\
     37user_id, building_id, (building_id, room_number), reservation_id, service_id, p_id
     38
     39Лево и десно – атрибути кои се и детерминанти и зависни \\
     40room_number (во комбинација со building_id), manager_id, staff_id, customer_id
     41
     42Десно – атрибути кои се само зависни \\
     43first_name, last_name, phone, email, password, address, city, floors, num_rooms, room_type, number_of_beds, price_per_night, available, start_date, end_date, reserv_date, status, p_method, amount, p_date, service_type, service_date, service_status
     44
     45=== Покривачи на примарни клучеви
     46
     47User
     48user_id+ = {user_id, first_name, last_name, phone, email, password}
     49
     50Hotel Building
     51building_id+ = {building_id, address, city, floors, num_rooms}
     52
     53Room
     54(building_id, room_number)+ = {room_number, building_id, room_type, number_of_beds, price_per_night, available, address, city, floors, num_rooms}
     55
     56Reservation
     57reservation_id+ = {reservation_id, start_date, end_date, reserv_date, status, user_id (customer), manager_id, room_number, building_id}
     58
     59Payment
     60p_id+ = {p_id, p_method, amount, p_date, reservation_id, customer_id}
     61
     62Service
     63service_id+ = {service_id, service_type, service_date, service_status, staff_id, room_number, building_id}
     64
     65Следува дека { user_id, building_id, room_number, reservation_id, payment_id, service_id } е единствен кандидат клуч и го прогласуваме за примарен клуч.
     66
     67=== Анализа според покривачи
     68
     69Од анализата се забележуваат:
     70
     71room_number е уникатен само во комбинација со building_id → слаб ентитет.
     72
     73Во Reservation нема експлицитно модел на врска со Customer, Manager и Room → треба релации за интегритет.
     74
     75Во Payment, amount е транзитивно зависно од Reservation (amount = цена * број на ноќи).
     76
     77Во Service, моментално нема детална историја (само статус).
     78
     79=== Анализа на нормални форми
     801 НФ
     81
     82Тековниот дизајн е во 1NF: атомски атрибути, нема повеќевредносни атрибути складирани како едно поле.
     83
     842 НФ
     85
     86Нема парцијални зависности (освен кај Room, каде клуч е составен (building_id, room_number)).
     87
     883 НФ
     89
     90Проблеми:
     91
     92Reservation – amount (треба да се изведува од Room.price_per_night × број на ноќи → не треба да стои во Payment како атрибут).
     93
     94Reservation моментално чува и customer_id, и manager_id → транзитивна зависност преку User.
     95
     96Подобрувања за да се задоволи 3 НФ
     97Reservation – Order Cost
     98
     99Да не се чува amount во Payment, туку да се пресметува.
     100
     101
     102ALTER TABLE Payment DROP COLUMN amount;
     103
     104Да се додава VIEW:
     105
     106CREATE VIEW reservation_total AS
     107SELECT r.reservation_id,
     108       (EXTRACT(DAY FROM r.end_date - r.start_date) * rm.price_per_night) AS total_cost
     109FROM Reservation r
     110JOIN Room rm ON r.room_number = rm.room_number AND r.building_id = rm.building_id;
     111
     112Service – историја на статуси
     113
     114CREATE TABLE service_history (
     115    history_id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
     116    service_id BIGINT NOT NULL,
     117    status VARCHAR(70) NOT NULL,
     118    changed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
     119    FOREIGN KEY (service_id) REFERENCES Service(service_id)
     120);
     121
     122BCNF
     123Прекршоци
     124
     125email во Hotel_User треба да е уникатен → веќе има UNIQUE.
     126
     127phone исто така треба да е уникатен (еден број = еден корисник).
     128
     129Во Room, комбинацијата (building_id, room_number) е единствен идентификатор.
     130
     131ALTER TABLE Hotel_User ADD CONSTRAINT uq_phone UNIQUE(phone);
     132
     133ALTER TABLE Room ADD CONSTRAINT uq_room UNIQUE(building_id, room_number);