Data Model Cardinality
Data Model Cardinality
LINK This is a 0:0
optional relationship basically stating that a person can occupy one parking space, that I don't
need a person to have a space and I don't need a space to have a person. Although the concept is
fairly simple, a database can't express it directly. You would need to nominate one entity to
become the dominant table and use triggers or programs to limit the number of related records
in the other table.
SubType This is a
1:0 relationship; optional only on one side. This would indicate that a person might
be a programmer, but a programmer must be a person. It is assumed that the mandatory
side of the relationship is the dominant. Again, triggers or programs must be used to control
the database.
Physical Segment
This is a 1:1 mandatory relationship and demonstrates a segmentation denormalization. A person
must have one and only one DNA pattern and that pattern must apply to one and only one person.
This is difficult to implement in a database, since declarative referential integrity will get
caught in a "Chicken and the Egg" situation. Basically, this is a single entity.
Possession
This is a 0:M (zero to many) optional relationship indicating that a person might have no phone, one phone or lots of
phones, and that a phone might be un-owned, but can only be owned by a maximum of one person.
This is implemented in a database as a nullable foreign key column in the phone table that
references the person table.
Child
This is a 1:M mandatory relationship, the most common one seen in databases. A person might be a member
or might not, but could be found multiple times (if the member entity represents membership in
multiple clubs, for instance). A member must be a person, no questions asked. The foreign key
in the member table would be mandatory, or not-null.
Characteristic
This is a 0:M relationship that is mandatory on the many side. It indicates that a person
must have at least one name, but possibly many names, and that a name might be assigned to
a person (might not) but at most to one person. In a database you would have the the name
table with a nullable foreign key to the person table and triggers or programs to force a
person to have at least one name.
Paradox
This is a 1:M relationship mandatory on both sides. As with the physical segment situation,
the "Chicken and the Egg" is involved since you have to have a person to have
citizenship, but citizenship to have a person.
Association
This is a M:M (many to many) optional relationship. Conceptually, it means that a person
might or might not work for an employer, but could certainly moonlight for multiple
companies. An employer might have no employees, but could have any number of them.
Again, not hard to visualize, but hard to implement. Most solutions of this situation
involve creating a third "Associative Entity" to resolve the M:M into two 0:M
relationships. This might be an entity called employee because it does link the person
to the employer the person works for.
Visitors on this page: [an error occurred while processing this directive]
Last Updated: [an error occurred while processing this directive]