Search code examples
database-designdata-modelingrdbmserdconceptual-model

Conceptual data modelling: How to read a recursive many to many relationship


I understand that a simple binary relationship like the one below would read from left to right: a user "may" have one or more pictures. Also if you read it from right to left is would be... an image "must" belong to one and only one user. enter image description here

However, where I get a little confused is when I see the following. Could anyone tell me how you read this type of relationship? Also, in the image following the one right below are they saying the same thing just differently? enter image description here

enter image description here

and finally, in this recursive relationship where a user can be a friend of another user does it make sense that both ends are specified as an optional many, or should one be a must and many?

The way I see it is if a user can have zero or many friends than on the other end it should have one or many friends because if user A is friends with user B then user B no longer has an option to have zero friends. Is this assumption correct or am I wrong?

Any thoughts would help I am just reading through a book on conceptual data modelling and really want to understand this before I move on and practice on real tables.


Solution

  • Yes, the two diagrams are showing the same thing.

    Some people choose to leave many-to-many relationships unresolved in conceptual diagram. Some text describing the relationship might be helpful (I'd suggest something like "is friends with"). I'd then read this as something like "a User may be friends with other Users."

    The second diagram shows what you'd draw if you instead decided to resolve the many-to-many relationship. Some people leave this until logical modelling, and you'll come across the same construct when you read about it (which I would recommend as the next step after learning about conceptual modelling). I would read the relationships between User and Friendship as something like "a User may have Friendships."

    These relationships are always optional because you're modelling the big picture, not one specific instance. Showing it as non-optional on the right-hand side would be saying every User must have at least one entry in the second column of the Friendship table in the database you'd eventually make from this model - and that's not true.

    By the way, I think it's really commendable that you're reading up on this (far too many people build databases without ever trying to grasp conceptual or logical modelling!). I wouldn't worry about waiting until you feel like you understand it fully before trying out what you're learning, though; some of the ideas may make more sense once you're putting them into practice on real data that you already know. Try sketching out conceptual diagrams based on your own data while you learn, if you haven't yet.