Changes between Initial Version and Version 1 of Normalization012

Timestamp:

09/04/25 12:27:06 (5 days ago)

Author:

201205

Comment:

--

Normalization012

@@ +1 @@
+== Нормализација ==
+
+**Почетна релација:**
+
+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 може да премине во една релација, а да биде потребна во неколку други. 
+
+Затоа, сметам дека тековната структура на базата во случајов е веќе резултат на декомпозиција и ги почитува правилата на БКНФ.