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

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	restaurant_id	reservation_date	time_from	time_to	number_of_people
1	101	11	201	2025-05-01	18:00	20:00	4
2	102	12	202	2025-05-02	19:30	21:00	2
3	103	13	203	2025-05-03	17:00	18:30	3

Во оваа релација, 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_history_id	user_id	table_id	restaurant_id	reservation_date	time_from	time_to	number_of_people
1	101	11	201	2025-05-01	18:00	20:00	4
2	102	12	202	2025-05-02	19:30	21:00	2
3	103	13	203	2025-05-03	17:00	18:30	3

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

---

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

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

• table_id → restaurant_id

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

• reservation_history_id

• table_id

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

• restaurant_id, user_id, date, time, duration

---

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

---

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

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

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

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

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

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

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

reservation_history_id → table_id → restaurant_id

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

---

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

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

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

• R2(table_id, restaurant_id)

---

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

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

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