Нормализација
Нормализација на Transaction
Првично: Transaction = {TransactionId, RequestId*, BorrowerId*, LenderId*, InventoryId*, BorrowDate, ReturnDate, BorrowDuration}
- RequestId референцира кон BookRequest(RequestId)
- BorrowerId референцира кон AppUser(UserId)
- LenderId референцира кон AppUser(UserId)
- InventoryId референцира кон Library(InventoryId)
TransactionId | RequestId | BorrowerId | LenderId | InventoryId | BorrowDate | ReturnDate | BorrowDuration |
---|---|---|---|---|---|---|---|
1 | 1 | 2 | 3 | 1 | 2024-04-15 | 2024-04-25 | 10 |
2 | 2 | 3 | 2 | 2 | 2024-06-23 | 2024-06-28 | 5 |
1НФ: Вредностите на атрибутите се атомични.
2НФ: Сите атрибути се функционално определени од примарниот клуч TransactionId кој е составен од само еден атрибут (не е композитен).
3НФ: Примарниот клуч TransactionId ги одредува сите атрибути.
Но, ако го знаеме RequestId, исто така ги знаеме и BorrowerId, LenderId, и InventoryId, и со тоа, следува функционалната зависност:
RequestId -> BorrowerId, LenderId, InventoryId.
Што пак води до транзитивност:
TransactionId -> RequestId -> BorrowerId
TransactionId -> RequestId -> LenderId
TransactionId -> RequestId -> InventoryId
Бидејќи RequestId не е супер-клуч, односно не ги одредува сите атрибути, ја нарушува 3НФ. За да го поправиме ова, може едноставно да се извадат BorrowerId, LenderId, и InventoryId од релацијата Transaction, кои можеме лесно да ги добиеме преку RequestId.
Така новата релација станува:
Transaction = {TransactionId, RequestId*, BorrowDate, ReturnDate, BorrowDuration}
БКНФ: Новата релација е во БКНФ, со тоа што единствената ФЗ тука е TransactionId -> RequestId, BorrowDate, ReturnDate, BorrowDuration со примарен клуч на левата страна.
Нормализација на BookRequest
Првично: BookRequest = {RequestId, RequesterId*, OwnerId*, BookId*, InventoryId*, RequestStatus, RequestDate}
- RequesterId референцира кон AppUser(UserId)
- OwnerId референцира кон AppUser(UserId)
- BookId референцира кон Book(BookId)
- InventoryId референцира кон Library(InventoryId)
RequestId | RequesterId | OwnerId | BookId | InventoryId | RequestStatus | RequestDate |
---|---|---|---|---|---|---|
1 | 1 | 2 | 1 | 1 | Approved | 2024-04-15 |
2 | 1 | 4 | 3 | 2 | Pending | 2024-06-23 |
1НФ: Вредностите на атрибутите се атомични.
2НФ: Сите атрибути се функционално определени од примарниот клуч RequestId кој е составен од само еден атрибут (не е композитен).
3НФ: Примарниот клуч RequestId ги одредува сите атрибути.
Но, ако ги погледнеме InventoryId и BookId, меѓу нив може да ја има функционалната зависност:
InventoryId -> BookId
Заради тоа што InventoryId ќе биде поврзано за специфична книга, поради појавата на транзитивност RequestId -> InventoryId -> BookId, и поради тоа што InventoryId не е супер-клуч, ова може да ја наруши 3НФ. Бидејќи веќе имаме релација ContainsLibraryBook(InventoryId*, BookId*), можеме безбедно да го извадиме атрибутот BookId од BookRequest, бидејќи преку InventoryId можеме лесно да стигнеме до BookId, и точно да одредиме за која книга се работи.
Па затоа можеме да ја смениме релацијата во: BookRequest= {RequestId, RequesterId*, OwnerId*, InventoryId*, RequestStatus, RequestDate}
И сега да ја исполнува 3НФ.
БКНФ: На левата страна од ФЗ има супер-клуч.
Нормализација на Notification
Првично: Notification(NotificationId, TransactionId*, MessageId*, FriendRequestId*, BookRequestId*, Type, NotifTime, NotifDate, Description, NotificationStatus)
- TransactionId референцира кон Transaction(TransactionId)
- MessageId референцира кон Transaction(MessageId)
- FriendRequestId референцира кон Transaction(FriendshipId)
- BookRequestId референцира кон Transaction(RequestId)
NotificationId | TransactionId | MessageId | FriendRequestId | BookRequestId | Type | NotifTime | NotifDate | Description | NotificationStatus |
---|---|---|---|---|---|---|---|---|---|
1 | 1 | NULL | NULL | NULL | Transaction | 14:34:54 | 2025-01-02 | Ongoing Transaction! | Unread |
3 | NULL | 2 | NULL | NULL | Message | 12:02:04 | 2025-03-04 | Anya sent you a message! | Dismissed |
1НФ: Вредностите на атрибутите се атомични.
2НФ: Сите атрибути се функционално определени од примарниот клуч NotificationId, кој е составен од само еден атрибут (не е композитен).
3НФ: Во случајов има транзитивни зависности:
NotificationId -> Type, Type -> TransactionId
NotificationId -> Type, Type -> MessageId
NotificationId -> Type, Type -> FriendRequestId
NotificationId -> Type, Type -> BookRequestId
Ова може да се реши со чување на главните податоци за известувањето во ентитетот Notification, и креирање на нови релации за секое од видовите известувања, со надворешен клуч од ентитетот Notification, и надворешен клуч од соодветниот ентитет кој го предизвикал известувањето:
Notification(NotificationId, Type, NotifTime, NotifDate, NotificationStatus)
TransactionNotification(TransactionId*, NotificationId*, Description)
-TransactionId референцира кон Transaction(TransactionId)
-NotificationId референцира кон Notification(NotificationId)
MessageNotification(MessageId*, NotificationId*, Description)
-MessageId референцира кон Message(MessageId)
-NotificationId референцира кон Notification(NotificationId)
FriendRequestNotification(FriendRequestId*, NotificationId*, Description)
-FriendRequestId референцира кон FriendRequest(FriendRequestId)
-NotificationId референцира кон Notification(NotificationId)
BookRequestNotification(BookRequestId*, NotificationId*, Description)
-BookRequestId референцира кон BookRequest(BookRequestId)
-NotificationId референцира кон Notification(NotificationId)
На овој начин релациите се во 3НФ.
БКНФ: Notification, како и TransactionNotification, MessageNotification, FriendRequestNotification, BookRequestNotification, се во БКНФ и на левата страна од функционите зависности имаат суперклуч.