Cardinality

How to Find

Relationships should be classified in terms of Cardinality

• Number of occurrences in one Entity which are associated with the number of occurrences in another

• There are three basic cardinalities (degrees of relationship):

  • One-to-one (1:1), one-to-many (1:M), and many-to-many (M:N)

• Also need to consider constraints:

  • At least one, exactly one. “mandatory”

• e.g., “An employee has a name and salary and must be assigned to a project.” -> 1: (mandatory)

• “A project has a name and deadline and can have employees working on it.” -> :M (not mandatory)

• 1:M

One-to-One Relationship

• One-to-one relationships are normally implemented through embedding one side of the relationship into the other, in a single subdocument

• Possible reasons not to:

  • Both sides accessed/updated independently

  • Either side is very large

  • Security and access control

• Which entity should be embedded into the other?

  • Which is the parent entity?

  • Which will exist independently?

One-to-Many Relationships

First need to establish how big the many is, as this will influence how we represent the relationship

• One-to-few (<100):

  • User – Playlist

  • Album – Song

• One-to-many (100s):

  • Artist – Album

• One-to-loads (1000s +):

  • User – Play

  • Song – Play

One-to-Few

• Typical example of modelling one-to-few would be addresses of a person:

  • Put the addresses in an array, inside of person document

  • One query to get addresses of a person

  • Cannot access addresses easily independently

• Need to establish if the few side needs to stand alone

Embed

• User may create many playlists, playlist exists only in context of user (not public or independent)

• Store array of playlist subdocuments in user

Reference

• Could embed songs array in Album, but:

  • Songs need to be accessed independently,

  • and can exist without an Album

• Could store array of song references in Album

One-to-Many (100s)

• Could embed albums array in Artist, but:

  • Albums need to be accessed outside of artist context.

  • Up to 100s of albums subdocuments (each with own songs subdocuments), could be large documents.

• Could store array of album references in Artist:

  • Is list of albums needed for Artist?

  • Album does need to know Artist…

• Store artist reference in Album. Store reference on N side

One-to-Loads (1000s+)

• Embed all plays in array in User / Song?

  • Too big, unbounded array

• Array of references to plays in User / Song?

  • Still too big, unbounded array

• Must store User and Song references in Play (N side reference)

Many-to-Many Relationships

• Establish size of many:

  • Song – Artist: many-to-few

  • Playlist – Song: many-to-few?

    • Could cap playlist size

• Where is information needed?

  • Song needs to list Artists

  • No need to view full list of artist’s songs

  • Playlist must list songs

  • No need to know which playlists a song is in