Are these tables respect the 3NF Database Normalization?

Question

AUTHOR table

• Author_ID , PK
• First_Name
• Last_Name

TITLES table

• TITLE_ID , PK
• NAME
• Author_ID , FK

DOMAIN table

• DOMAIN_ID , PK
• NAME
• TITLE_ID , FK

READERS table

• READER_ID , PK
• First_Name
• Last_Name
• ADDRESS
• CITY_ID , FK
• PHONE

CITY table

• CITY_ID , PK
• NAME

BORROWING table

• BORROWING_ID ,pk
• READER_ID , fk
• TITLE_ID , fk
• DATE

HISTORY table

• READER_ID
• TITLE_ID
• DATE_OF_BORROWING

• DATE_OF_RETURNING

  1. Are these tables respect the 3NF Database Normalization?
  2. What if 2 authors work together for the same title?
  3. The column Addresss should have it's own table?
  4. When a reader borrows a book, I make an entry in BORROWING table. After he returns the book, I delete that entry and I make another one entry in HISTORY table. Is this a good idea? Do I brake any rule? Should I have instead one single BORROWING table with a DATE_OF_RETURNING column?

Answer 1

This looks a bit like a homework problem, but let me answer anyway:

1. No, the tables are not in 3NF; tables with surrogate keys rarely are. For example, the READERS table has two candidate primary keys: READER_ID and (First_Name, Last_Name). Of course, that depends on your problem domain: if you're willing to have two separate individuals with the same name, address and phone, then it's in 3NF. Also, in my experience, 3NF is usually more trouble than it's worth.
2. Again, that depends on your problem domain. You could create a many-to-many relation between AUTHORS and TITLES through an intermediate table.
3. See 1.
4. You could dispense with BORROWING and create a perfectly working application, as HISTORY contains all information you need. The less information you have to track, the better.

Answer 2

I would change the Titles to a MANY-TO-MANY, and leave the addresses.

TITLES table

• TITLE_ID , PK
• NAME

TitleAutors table

• TITLE_ID ,
• AUTHOR_ID

You could change the BORROWING table to have the status of the entry (OUT, IN, MISSING, UNKNOWN) and have a STATUS_DATE.

Answer 3

How do you expect anybody to seriously answer this question without any knowledge of your business domain ?

In order to answer this question earnestly, one needs to know the entire set of functional dependencies that govern your data, and you have not provided those.

For your scheme to be in 3NF, for example, it would require that domainID -> titleID, or, in other words, that there is only one title for each domain, and that knowing the domain implies that you can know the title. On the face of it, that seems curious, but the only one who can tell for sure whether or not this is an accurate representation of the business reality that you're dealing with, is you.

Answer 4

An additional thought that occurred to me after reading others comments is.

• Can a author be a reader? (And vis-versa)

If so you may have redundant first and last names entered into your system, and it would be susceptible to update anomalies. For example if Jane Smith was a reader and an author and got married and her Surname changed to Williams then the possibility for updating her Reader last name and not her author last name would exist.

You would fix this by perhaps creating a User table where you have two Foreign keys for a Authors and Readers Table. Just a thought... ;)