Функционални карактеристики и нормализација

Поделба на доменот според типот на евиденција

Поради комплексноста на моделот на базата, речиси е невозможно сите податоци да се стават во една табела. Затоа проблемот на нормализација ќе го поделиме на повеќе делови. Логичната поделба на табелите се заснова на улогите и процесите во системот: корисници, резервации, ресторани и мени производи.

Корисниците имаат директна интеракција со табелата reservations, а потоа може да се поврзат со tables и restaurants за да се добијат информации за ресторанот и масата што ја резервирале. Со тоа се формира агрегирана табела која може да ја наречеме: Резервации со корисници и маси

1. Oпределување на важечките функциски зависности

Тргнуваме од список во кој сите атрибути имаат различни имиња. За таа цел атрибутите кои што имаат исти имиња ги преименувавме. Во продолжение е списокот на атрибути кои што се преименувани.

• id (Кај ентитетот pre_ordered_items) -> preorderedItemId

• name (Кај ентитетот pre_ordered_items) -> preorderedItemName

• status (Кај ентитетот reservations) -> reservationStatus

• id (Кај ентитетот reservations) -> reservationHistoryId

• status (Кај ентитетот reservation_history) -> reservationStatus

• id (Кај ентиетот menu_tags) -> menuTagId

• id (Кај ентитетот users) -> userId

• category (Кај ентитетот menus) -> menuCategory

• location (Кај ентитетот tables) -> tableLocation

2. Резервации со корисници и маси

reservation_id	user_id	table_id	reservation_date	check_in_from	check_in_to	number_of_people	restaurant_id
1	101	11	2025-05-01	18:00	20:00	4	201
2	102	12	2025-05-02	19:30	21:00	2	202
3	103	13	2025-05-03	17:00	18:30	3	203

Во оваа релација, restaurant_id се повторува иако е функционски зависен од table_id, бидејќи секоја маса припаѓа на еден ресторан.

---

Функциски зависности:

• reservation_id → user_id, table_id, restaurant_id, date, time, duration

• table_id → restaurant_id

Анализа на зависности: Само лево (детерминанти):

• reservation_id

• table_id

Само десно (зависни атрибути):

• restaurant_id, user_id, date, time, duration

---

Канонична покривка: Од reservation_id може да се добијат сите атрибути, затоа е кандидат клуч.

---

Анализа на нормализација:

Прва нормална форма (1НФ):

Сите атрибути се атомски, нема листи или вложени структури. Задоволена.

Втора нормална форма (2НФ):

Клучот е едноставен (reservation_id), па нема парцијални зависности. Задоволена.

Трета нормална форма (3НФ):

Се појавува транзитивна зависност:

reservation_id → table_id → restaurant_id

Значи, restaurant_id е транзитивно зависен од примарниот клуч (reservation_id), и релацијата не е во 3НФ.

---

R1: Reservation (без дупликација на restaurant_id)

• R1(reservation_id, user_id, table_id, date, time, duration)

R2: Table (со поврзаност со ресторан)

• R2(table_id, restaurant_id)

---

Финална анализа

• Нема дуплицирање.

• restaurant_id може да се добие преку JOIN со Table.

3. Резервации со корисници и маси

reservation_id	reservation_date	time_from	time_to	number_of_people	user_id	user_name	table_id	table_number	restaurant_id	restaurant_name	restaurant_location
1	2025-05-01	18:00	20:00	4	101	Ana	11	1	201	Gino’s	Skopje, Centar
2	2025-05-02	19:30	21:00	2	102	Marko	12	2	202	Sushico	Skopje, Karposh
3	2025-05-03	17:00	18:30	3	103	Elena	13	3	203	Bella Italia	Skopje, Aerodrom

R = { reservation_id, reservation_date, time_from, time_to, number_of_people,

user_id, user_name,

table_id, table_number,

restaurant_id, restaurant_name, restaurant_location

}

Функциски зависности:

reservation_id → reservation_date, time_from, time_to, number_of_people, user_id, table_id

user_id → user_name

table_id → table_number, restaurant_id

restaurant_id → restaurant_name, restaurant_location

лево:

reservation_id, user_id, table_id, restaurant_id

Само десно (зависни атрибути):

user_name, restaurant_name, restaurant_location, reservation_date, time_from, time_to, number_of_people, table_number