wiki:Нормализација и подобрувања на дизајнот

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

Нормализација на 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, се во БКНФ и на левата страна од функционите зависности имаат суперклуч.

Last modified 10 days ago Last modified on 07/07/25 12:16:04
Note: See TracWiki for help on using the wiki.