Functional dependency and many-to-many relationships - database

Question

I have these fields:
A book_id
B book_title
C book_isbn
D book_year
G reader_id
H reader_name
I reader_birthday
L reader_phone
M reader_email
N reader_registration_date
O loan_id
P loan_date_issued
S loan_date_for_return
T loan_date_returned
U author_id
V author_name
W category_id
X category_name
and these dependencies:
A->BCD
G->HILMN
O->AGPST
U->AV
W->AX
After all calculations I get this:
R1 = ABCD k1 = {A} Books
R2 = GHILMN k2 = {G} Readers
R3 = AGOPST k3 = {O} Loans
R4 = AUV k4 = {U} Authors
R5 = AWX k5 = {W} Category
R6 = OUW k6 = {OUW} {Don’t know}
But this is not good because table Book has a many to many relationship with table Category, and so do the Book and Author tables.
I'm stuck. I think I'm doing something wrong from the start and after that all goes wrong. Maybe you have some example for this.

Answer 1

Let's treat "category" as "cover" of a "book"-as-object or "copy" of a "book"-as-text, where a "book" is associated with some O values unique to it. Then W -> A makes more intuitive sense. (Other FDs seem unintuitive too.)
Universal relations
Every table (base or query result) has a predicate (statement template) that a row makes either into a true statement (and goes in the table) or a false statement (and stays out). We say the table represents the business relationship/association characterized by the predicate. A guess at a predicate here is:
book A titled B with isbn C published in year D
was borrowed by a reader G named H born on date I
with phone# L and email address M registered on date N
in loan O issued on date P due on date S
and either it was returned on date T or it is not yet returned and T=NULL
and it was written by author U named V
and the library has A in cover/copy W named X
You seem to be using the "universal relation" decomposition design/normalization technique. But this is only applicable if your one table satisfies the "universal relation assumption". Which is that all your situations can be described via the one predicate and its one table.
Eg: Suppose you can have books that have not been loaned or users that haven't borrowed. Then the example predicate/table above could not record them. So a decomposition wouldn't be able to record them. So you would instead start with a different predicate/table. (Typically multiple ones.)
Eg: If the last line was and A was borrowed in cover/copy W named X then the table could hold a different value in a given situation than before. But depending on the borrowing policy the table could satisfy the same set of FDs.
What is the predicate for this table? If it's not what you guessed, your expectations might not be met.
Your decomposition
Let's ignore the properties of entities.
-- O is G borrowing A by U with W
A book_id
G reader_id
O loan_id
U author_id
W cover/copy_id
O->AG
U->A
W->A
The only CK is OUW. Here is an obvious decomposition to BCNF. It agrees with your version.
-- O is G borrowing A by someone with some cover/copy
-- O is G borrowing A
Loan(O,G,A)
-- some loan is somebody borrowing A by U with some cover/copy
-- the book of U is A
The_book_of_author(U,A)
-- some loan is somebody borrowing A by someone with W
-- the book of W is A
The_book_of_cover/copy(W,A)
-- O is somebody borrowing some book by U with W
-- O is the borrowing of the book of U and W
Author_and_cover/copy(O,U,W)
The original relation is the join of the components:
-- O is G borrowing A
and the book of U is A
and the book of W is A
and O is the borrowing of the book of U and W
-- O is G borrowing A by U with W
Loan JOIN The_book_of_author JOIN The_book_of_cover/copy JOIN Author_and_cover/copy
this is not good because table Book has a many to many relationship with table Category, and so do the Book and Author tables
Unfortunately this is unintelligible. So I can't address what you mean to say is wrong.
Database design
If you generated this design yourself, you should be using some reference information modeling method. This will guide you to determine reasonable predicates/tables to record all the situations that can arise according to your business rules.
Predicates applied to what situations can arise determine what states can arise. Those valid states are described by constraints--FDs (functional dependencies), JDs (join dependencies), CKs (candidate keys), FKs (foreign keys) (aka "relationships" in a different sense than above), etc.
Part of a method is normalizing provisional tables to others. This uses FDs & JDs to decompose to an appropriate NF (normal form) via an appropriate algorithm. A good method always normalizes to 5NF. (Even if you denormalize it later for implementation reasons.)