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

=== Нормализација на 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 референцира кон User(!UserId)
    • !OwnerId референцира кон User(!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НФ.

**БКНФ**: На левата страна од ФЗ има супер-клуч.