Many-to-Many Must Have at Least One Descriptive Attribute

[Eus Kevin]

Hi Ho!

One of my friends has a principle stating that a many-to-many relationship must have at least one descriptive attribute. But, I don't agree with him. So, I would like to know the right thing from you.

The problem is as follows:
Suppose there is a table named Book, a table named Language, and a table named Book_Language that shows in what languages a book has written. Because the relationship between Book and Language is many-to-many, the Book_Language has two attributes (i.e., book_id and lang_id).

I think the design is good because the real world process that are being modelled states that we do not need to note any other things (e.g., who wrote the book in a certain language).

But, my friend insists that, since the Book_Language is a many-to-many relationship and has only the primary keys of the participating entities, it is not normal and requires at least one descriptive attribute. So, his schema of Book_Language is {book_id, lang_id, date_published}. And, he said that it is a principle that every many-to-many relationship requires at least one descriptive attribute in order to be normal. Even though the real world process does not use the descriptive attribute, it still has to be added and given a default value for every insertion of data.

I do not believe that such a principle exists.

When I asked him why my design of Book_Language is not normal, he asked me to show the functional dependency rule for my design of Book_Language.
My answer was: book_id, lang_id -> book_id, lang_id
But, he said that it was wrong and wrote the correct one according to him as:
book_id, lang_id -> lang_id (Well, it could also be book_id, lang_id -> book_id)
After that, he said that I should reread my book on a chapter about dependencies and relation keys in subchapter of removing dependencies by examination.

I have read it, but I still do not get his idea and I still do not believe in his principle. Could you please help me with this matter?

Thank you very much.

Regards,
Eus