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

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

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

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

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 може да премине во една релација, а да биде потребна во неколку други.

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