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

1. Денормализација

• Комбинирање на сите атрибути во една табела R

R = {
  UserID, Name, Surname, Email, Password, PhoneNumber, DateJoined,
  DestinationID, DestinationName, Country, Description, PopularAttraction, BestTimeToVisit,
  AirportID, AirportName, City, AirportCountry, Code,
  FlightID, DepartureAirportID, ArrivalAirportID, DepartureTime, ArrivalTime, Price,
  BookingID, BookingDate, PaymentStatus, TotalCost, SeatNumber,
  ReviewID, ReviewComment, Rating, ReviewDate, ReviewTargetID,
  PaymentID, PaymentMethod, Amount, TransactionDate, PaymentStatus,
  NotificationID, Message, NotificationType, DateSent,
  WishlistID, WishlistTargetID, WishlistDateAdded,
  AdminID, AdminEmail,
  TicketID, Subject, TicketDescription, TicketStatus, DateCreated, DateResolved, AssignedTo
}

2. Functional Dependencies:

1. Users:

   UserID → Name, Surname, Email, Password, PhoneNumber, DateJoined
   Email → UserID
   PhoneNumber → UserID
   

2. Destinations:

   DestinationID → DestinationName, Country, Description, PopularAttraction, BestTimeToVisit
   

3. Airports

   AirportID → AirportName, City, AirportCountry, Code
   Code → AirportID
   

4. Flights

   FlightID → DepartureAirportID, ArrivalAirportID, DepartureTime, ArrivalTime, Price
   

5. Bookings

   BookingID → UserID, FlightID, BookingDate, PaymentStatus, TotalCost, SeatNumber
   

6. Reviews:

   ReviewID → UserID, ReviewTargetID, ReviewComment, Rating, ReviewDate
   

7. Payments

   PaymentID → BookingID, UserID, PaymentMethod, Amount, TransactionDate, PaymentStatus
   

8. Notifications

   NotificationID → UserID, Message, NotificationType, DateSent
   

9. Wishlist

   WishlistID → UserID, WishlistTargetID, WishlistDateAdded
   

10. Administrators

    AdminID → AdminEmail
    

11. SupportTickets

    TicketID → UserID, Subject, TicketDescription, TicketStatus, DateCreated, DateResolved, AssignedTo
    

3.Candidate Keys

• За големата табела R, суперклучот мора да ги вклучува сите ID-а за уникатна идентификација

Ова е огромен клуч, што ја оправдува потребата за декомпозиција

Candidate Key = {UserID, DestinationID, AirportID, FlightID, BookingID, ReviewID, PaymentID, NotificationID, WishlistID, AdminID, TicketID}

4. Decomposition into 1NF -> 2NF -> 3NF -> BCNF 4.1. 1NF - Atomic attributes Сите мулти вредносни атрибути се поделени. Секој атрибут е atomic. Табелата е сега во 1NF.

4.2. 2NF - Отстранување на делумни зависности Се отстрануваат атрибути кои зависат само од дел од композитен клуч Сите атрибути зависни од индивидуални ID-a се делумни зависности.

Декомпозиција по ентитет:

1. Users

   R_Users = {UserID, Name, Surname, Email, Password, PhoneNumber, DateJoined}
   

2. Destinations

   R_Destinations = {DestinationID, DestinationName, Country, Description, PopularAttraction, BestTimeToVisit}
   

3. Airports

   R_Airports = {AirportID, AirportName, City, AirportCountry, Code}
   

4. Bookings

   R_Bookings = {BookingID, UserID, FlightID, BookingDate, PaymentStatus, TotalCost, SeatNumber}
   

5. Reviews

   R_Reviews = {ReviewID, UserID, ReviewTargetID, ReviewComment, Rating, ReviewDate}
   

6. Flights

   R_Flights = {FlightID, DepartureAirportID, ArrivalAirportID, DepartureTime, ArrivalTime, Price}
   

7. Payments

   R_Payments = {PaymentID, BookingID, UserID, PaymentMethod, Amount, TransactionDate, PaymentStatus}
   

8. Notifications

   R_Notifications = {NotificationID, UserID, Message, NotificationType, DateSent}
   

9. Wishlist

   R_Wishlist = {WishlistID, UserID, WishlistTargetID, WishlistDateAdded}
   

10. Administrators

    R_Admins = {AdminID, AdminEmail}
    

11. SupportTikets

    R_Tickets = {TicketID, UserID, Subject, TicketDescription, TicketStatus, DateCreated, DateResolved, AssignedTo}
    

Сега секој атрибут зависи целосно од примарниот клуч -> 2NF задоволено.

4.3. 3NF - Отстранување на транзитивни зависности Проверка на зависности на не-клучни атрибути. Примери:

• Корисници Email -> UserID - може да се направи посебна табела за емаил.
• Аеродроми Code -> AirportID - може да се направи посебна табела за кодовите.

За повеќето нема транзитивни зависности -> 3NF задоволено.

4.4. BCNF - Секој детерминант е суперклуч Проверка: левата страна на FD е суперклуч? Примери:

• Email -> UserID -> Email е уникатен -> табела R_Email = {Email,UserID}
• PhoneNumber -> UserID -> табела R_Phone = {PhoneNumber, UserID}
• Code -> Airport -> табела R_AirportCode = {Code, AirportID}

Сега сите табели се во BCNF.

5. Крајна нормализирана структура

Table	Attributes	Note
Users	UserID, Name, Surname, Password, DateJoined	BCNF
Emails	Email, UserID	BCNF
Phones	PhoneNumber, UserID	BCNF
Destinations	DestinationID, DestinationName, Country, Description, PopularAttraction, BestTimeToVisit	BCNF
Airports	AirportID, AirportName, City, AirportCountry	BCNF
AirportCodes	Code,AirportID	BCNF
Flights	FlightID, DepartureAirportID, ArrivalAirportID, DepartureTime, ArrivalTime, Price	BCNF
Bookings	BookingID, UserID, FlightID, BookingDate, PaymentStatus, TotalCost, SeatNumber	BCNF
Reviews	ReviewID, UserID, ReviewTargetID, ReviewComment, Rating, ReviewDate	BCNF
Payments	PaymentID, BookingID, UserID, PaymentMethod, Amount, TransactionDate, PaymentStatus	BCNF
Notifications	NotificationID, UserID, Message, NotificationType, DateSent	BCNF
Wishlist	WishlistID, UserID, WishlistTargetID, WishlistDateAdded	BCNF
Admins	AdminID, AdminEmail	BCNF
Support Tickets	TicketID, UserID, Subject, TicketDescription, TicketStatus, DateCreated, DateResolved, AssignedTo	BCNF