4

I understand what cardinality is, so please don't explain that ;-)

I would like to know, what the purpose of doing cardinality is in data modeling, and why i should care.

Example: In an ER model you make relations and ad the cardinality to the relations. When am i going to use the cardinality further in the development process? Why should i care about the cardinality?

How, when and where do i use the cardinalities after i finish an ER model for example.

Thanks :-)

5 Answers5

2

Cardinalities tell you something important about table design. A 1:m relationship requires a foreign key column in the child table pointing back to the parent primary key column. A many-to-many relationship means a JOIN table with foreign keys pointing back to the two participants.

duffymo
  • 305,152
  • 44
  • 369
  • 561
1

How, when and where do i use the cardinalities after i finish an ER model for example.

When physically creating the database, the direction, NULL-ability and number of FKs depends on the cardinalities on both endpoints of the relationship in the ER diagram. It may even "add" or "remove" some tables and keys.

For example:

  • A "1:N" relationship is represented as a NOT NULL FK from the "N" table to "1" table. You cannot do it in the opposite direction and retain the same meaning.
  • A "0..1:N" relationship is represented as a NULL-able FK from "N" to "0..1" table.
  • A "1:1" relationship is represented by two NOT NULL FKs (that are also keys) forming a circular reference1 or by merging two entities into a single physical table.
  • A "0..1:1" relationship is represented by two FKs, one of which is NULL-able (also under keys).
  • A "0..1:0..1" relationship is represented by two FKs, both NULL-able and under keys, or by a junction table with specially crafted keys.
  • An "M:N" relationship requires an additional (so called "junction" or "link") table. A key of that table is a combination of migrated keys from child tables.

Not all cardinalities can be (easily) represented declaratively in the physical database, but fortunately those that can tend to be most useful...

1 Which presents a chicken-and-egg problem when inserting new data, which is typically resolved by deferring constraint checking to the end of the transaction.

Branko Dimitrijevic
  • 50,809
  • 10
  • 93
  • 167
0

Cardinality is a vital piece of information of a relation between two entites. You need them for later models when the actual table architecture is being modelled. Without knowing the relationship cardinality, one cannot model the tables and key restriction between them.

For example, a car must have exactly 4 wheels and those wheels must be attached to exactly one car. Without cardinality, you could have a car with 3, 1, 0, 12, etc... wheels, which moreover could be shared among other cars. Of course, depending on the context, this can make sense, but it usually doesn't.

Jakub Zaverka
  • 8,816
  • 3
  • 32
  • 48
0

A data model is a set of constraints; without constraints, anything would be possible. Cardinality is a (special kind of) constraint. In most cultures, a marriage is a relation between exactly two persons. (In some cultures these persons must have different gender.)

The problem with data modelling is that you have to specify the constraints you wish to impose on the data. Some constraints (unique, foreign key) are more important, and less dependent on the problem domain as others ("salary < 100000"). In most cases Cardinality will be somewhere in between crucial and bogus.

wildplasser
  • 43,142
  • 8
  • 66
  • 109
0

If you are creating the data layer of an application and you decided to use an ORM, maybe it's entity framework.

There's a point when you need to create your models and your model maps. At that point you would be able to pull out your ERD, review the cardinality you put on your diagram and create the correct relationships so your data layer shape matched your database shape.

greyalien007
  • 510
  • 4
  • 13