Many-to-Many relationships needing an associate table

Question

In many database design tutorials/articles, they always bring up the fact that if two tables share a many-to-many relationship, then a third table should be created to act as an

Answer 1

Let's understand it with an example. If you have two tables one for apples and other for persons and they have a many to many relationship; meaning one person can have multiple apple and one apple can be eaten by multiple person by sharing.

So if we add a foreign key to apple table in the person table then this gives the relationship that one apple can be eaten by multiple person but we have not specified the relationship for the other way around. See this table

Similarly, if we add a foreign key to person table in the apple table then this gives the relationship that one person can eat multiple apples but not the other relationship along with it.See this table

So here comes the association table. Association table are used for many to many relationship between two objects. They consists of at least 2 foreign keys, each of which reference one of the two objects and the primary key in an Association table is made up of at least the 2 foreign keys. See this table

Reference: https://openclassrooms.com/en/courses/2071486-retrieve-data-using-sql/5758019-create-an-association-table

Answer 2

It would not flexible if DB-Server could create 3rd table for you. If there will be a solution like that, you wouldn't have much influence to

• change relation behavour

• store other association information in assoc. table

• performance enhancements

• storage enhancements

Answer 3

You can't make many to many relations any other way using relational databases. Ie, if you have a table called "person", you can't create a column "friends" and expect to put many friends' user ids in there. You have to make a separate table to hold the relation itself.

Answer 4

In relational databases all relationships are represented in only one way: as relations (relations correspond to tables in SQL). A relation with two attributes, such as R{A,B}, represents a binary relationship between A and B. That relationship could be one-to-many or many-to-many for example.

If the relationship represented by R{A,B} is many-to-many that implies that neither A or B are candidate keys (because if either was unique then obviously only ONE tuple for each value of that attribute would be permitted). That means that the principle of Third Normal Form requires any attributes dependent on A or B to go in other tables. The reason for this is that non-key dependencies (attributes dependent on A or B) are a form of redundancy and can cause anomalies and incorrect results.

So it's not that "many-to-many relationships" are represented any differently to other relationships. It's just that normalization often leads to a common pattern with tables with compound keys and no other non-key attributes. Some people like to call that pattern an Association table - although personally I don't find that terminology very helpful.

Answer 5

Wikipedia describes it too. Just take a look: http://en.wikipedia.org/wiki/Many-to-many_(data_model)

If you still don't believe that many-to-many do realy need a third table, just try the Authors/Books examble (as described in the wikipedia article) with only two normalized tables.

Answer 6

If you don't create a third table, there is simply nowhere to store the relations.

With a one-to-one or one-to-many relation, you can store the relation in one of the tables. With a many-to-many relation you have to store the relations separately. (Well, theoretically you could store it as a comma separated list of identities in both tables, but that would be a nightmare to use and to maintain.)