How do you deal with m..n relationships in a relational database?

Question

Let\'s look at an example - books. A book can have 1..n authors. An author can have 1..m books. What is a good way to represent all of the authors of a book?

I came

Answer 1

Add another table called BookAuthors with columns for BookID, AuthorID, and NameUsed. A NULL value for NameUsed would mean to pull it from the Author's table instead. This is called an Intersection table.

Answer 2

The first thing that comes to mind is to have a link table, perhaps called AuthorOf to link books with their authors.

The columns would be AuthorID, BookID and perhaps CreditAs, so you can differentiate between Dr. Bob and Bob, PhD. (As well as pen names like Stephen King and Richard Bachman).

And you can still uniquely identify the author.

Answer 3

I think you're pretty much there. You need a Books table, an Authors table, and then a "authors_of_books" table with the primary key of the book, the primary key of the author, and a "cited as" text field showing how that particular author was cited on that book.

Answer 4

Given that Dr. Bob and Dr. Robert and Bob, PhD are all the same person, they would link to the same row in the authors table.

However, I think what you need is a person table that authors links to. You could also link your interesting person table to it. That way Author Bob and Author Robert as well as Interesting Bob link to Person Bob. Hope that makes sense.

Answer 5

It really looks like you are wanting to create a series of custom join tables, that are used to associate items from one entity to another.

I would start at the most granular level, person and say that ANY author must be a person. I would simplify that process.

Create a person table with person information and a PersonId, put the information in there.

THen create a BookAuthors table, with 3 columns BookId, PersonId, TitledName. THis way you can use a different name if needed, if not, you can use COALESE or something similar to get the default name if TitledName is null.

Just an idea..

Answer 6

For 1..n relationship (author has many books, author has many aliases):

1. Put a foreign key author_id in Books pointing at author.
2. Create a new table, author_aliases, to hold the aliases information.
3. Put a foreign key alias_id in Books pointing at alias (nullable if author details are defaul).
4. Put author_id foreign key in author_aliases.

If you wish, you can use intermediary tables to link authors and books, but with a 1..n mapping I don't think this is necessary.

For an n..m relationship (author has many books, book has many authors):

You would have to use an intermediary join table (author_id, alias_id, book_id) instead of foreign keys in the book table. You will want to keep the foreign key from aliases to author (for easy lookup of author aliases without having to go via all their books).

You can argue that in terms of scalability in the future this is a better way to start off as well, even if the initial specification says something is a 1..n relationship. You will find that specifications (or question) as given often are inadequate, so you will want to design in the general manner for when the specifications change or are clarified.