== Нормализација ==

**Почетна релација:**

R(!UserId, !FirstName, !LastName, Email, Username, Password, City, Neighborhood, Bio, Quote,  !BookId, Title, Author, Language, !ImageURL,  !BookISBNId, ISBN,  !GenreId, Genre,  !InventoryId, Availability, Condition,    !WishId, Priority,  !RequestId, !RequestStatus, !RequestDate,  !TransactionId,  !BorrowDate, !ReturnDate, !BorrowDuration,  !SwapId,  !ReviewId, Rating, !ReviewerComment, !ReviewDate,  !MessageId,  !MsgTime, !MsgDate, !MessageContent,  !FriendshipId,  !DateCreated, !FriendshipStatus,  !ReportId, !ReportType, !ReportDate, Details, !ReportStatus, !ReportedEntity,  !NotificationId, Type, !NotifTime, !NotifDate, !NotificationStatus, !TN_Description, !MN_Description, !FR_Description, !BR_Description)


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

!UserId -> !FirstName, !LastName, Email, Username, Password, City, Neighborhood, Bio, Quote
Email -> !UserId, !FirstName, !LastName, Username, Password, City, Neighborhood, Bio, Quote
Username -> !UserId, !FirstName, !LastName, Email, Password, City, Neighborhood, Bio, Quote

!BookId -> Title, Author, Language, !ImageURL

!BookISBNId -> !BookId, ISBN

!GenreId -> !BookId, Genre

!InventoryId-> !UserId, Availability, Condition, !BookId

!WishId -> !UserId, Priority, !BookId

!RequestId -> !UserId, !InventoryId, !RequestStatus, !RequestDate

!TransactionId -> !RequestId, !BorrowDate, !ReturnDate, !BorrowDuration

!SwapId -> !TransactionId

!ReviewId -> !TransactionId, !UserId, Rating, !ReviewerComment, !ReviewDate

!MessageId -> !UserId, !MsgTime, !MsgDate, !MessageContent

!FriendshipId -> !UserId, !DateCreated, !FriendshipStatus

!ReportId -> !UserId, !ReportType, !ReportDate, Details, !ReportStatus, !ReportedEntity

!NotificationId -> Type, !NotifTime, !NotifDate, !NotificationStatus

!TransactionId -> !NotificationId, !TN_Description

!MessageId -> !NotificationId, !MN_Description

!FriendshipId -> !NotificationId, !FR_Description

!RequestId -> !NotificationId, !BR_Description



=== ===

**Лево:** !BookISBNId,!GenreId, !WishId, !SwapId, !ReviewId, !ReportId 

**Десно:** FirstName, LastName, Password, City, Neighborhood, Bio, Quote,Title, Author, Language, ImageURL,  ISBN,  Genre, Availability, Condition, Priority, RequestStatus, RequestDate, BorrowDate, ReturnDate, BorrowDuration, Rating, ReviewerComment, ReviewDate, MsgTime, MsgDate, MessageContent,DateCreated, FriendshipStatus

**Од двете страни:** !UserId, Email, Username, !BookId, !InventoryId, !RequestId, !TransactionId, !MessageId, !FriendshipId, !NotificationId, !TransactionId, !MessageId, !FriendRequestId, !BookRequestId 

=== ===


1НФ: Вредностите на атрибутите се атомични.

2НФ: Сите атрибути се функционално определени од примарните клучеви кои се составени од само еден атрибут (не се композитни).

3НФ: Примарните клучеви ги одредуваат сите атрибути.

**БКНФ:**


Според дефиницијата за БКНФ, секоја нетривијална функционална зависност X → A мора да има X како суперклуч во релацијата.

Ако ја третираме целата шема како една релација R, тогаш многу од функционалните зависности (на пр. UserId = {!FirstName, !LastName, Email, Username, Password, City, Neighborhood, Bio, Quote}) ја нарушуваат БКНФ бидејќи UserId не е суперклуч на целата релација.

Но во мојот случај, функционалните зависности веќе се распоредени по релации каде што левата страна е суперклуч. 

На пример: ReviewId = {TransactionId, UserId, Rating, ReviewerComment, ReviewDate} е веќе претставена како релација Review(ReviewId, TransactionId, UserId, Rating, ReviewerComment, ReviewDate), каде ReviewId е суперклуч.

Ако продолжиме со декомпозиција на целосната релација според секоја функционална зависност, ќе изгубиме атрибути кои се потребни за другите зависности. 
На пример, атрибутот UserId е присутен во функционалните зависности:

InventoryId-> UserId, Availability, Condition, BookId

WishId -> UserId, Priority, BookId

RequestId -> UserId, InventoryId, RequestStatus, RequestDate

ReviewId -> TransactionId, UserId, Rating, ReviewerComment, ReviewDate

И многу други, и доколку тргнеме по традиционалната постапка на декомпозиција, UserId може да премине во една релација, а да биде потребна во неколку други. 

Затоа, сметам дека тековната структура на базата во случајов е веќе резултат на декомпозиција и ги почитува правилата на БКНФ.