Cardinality (data modeling)

Short description: Numerical relationship among rows in different tables

Within data modelling, cardinality is the numerical relationship between rows of one table and rows in another. Common cardinalities include one-to-one, one-to-many, and many-to-many. Cardinality can be used to define data models as well as analyze entities within datasets.

## Contents

* 1 Relationships
* 2 Modeling
* 3 Types of Models
* 4 Database modeling techniques
* 5 Application program modeling approaches
* 6 See also
* 7 References
* 8 External links

## Relationships

For example, consider a database of electronic health records. Such a database could contain tables like the following:

* A `doctor` table with information about physicians.
* A `patient` table for medical subjects undergoing treatment.
* An `encounter` table with an entry for each hospital visit.[citation needed]

Natural relationships exist between these entities, such as an encounter involving many doctors. There is a many-to-many relationship between records in `doctor` and records in `patient` because doctors have many patients and patients can see many doctors. There is a one-to-many relationship between records in `patient` and records in `encounter` because patients can have many encounters and each encounter involves only one patient.[1]

A "one-to-one" relationship is mostly used to split a table in two in order to provide information concisely and make it more understandable. In the hospital example, such a relationship could be used to keep apart doctors' own unique professional information from administrative details.[citation needed]

## Modeling

In data modeling, collections of data elements are grouped into "data tables" which contain groups of data field names called "database attributes". Tables are linked by "key fields". A "primary key" assigns a field to its "special order table". For example, the "Doctor Last Name" field might be assigned as a primary key of the Doctor table with all people having same last name organized alphabetically according to the first three letters of their first name. A table can also have a foreign key which indicates that field is linked to the primary key of another table.[2]

## Types of Models

A complex data model can involve hundreds of related tables. Computer scientist Edgar F. Codd created a systematic method to decompose and organize relational databases.[3] Codd's steps for organizing database tables and their keys is called database normalization, which avoids certain hidden database design errors (delete anomalies or update anomalies). In real life the process of database normalization ends up breaking tables into a larger number of smaller tables.[3]

Two related entities shown using Crow's Foot notation. In this example, the three lines next to the song entity indicate that an artist can have many songs. The two vertical lines next to the artist entity indicate songs can only have one performer.

In the real world, data modeling is critical because as the data grows voluminous, tables linked by keys must be used to speed up programmed retrieval of data. If a data model is poorly crafted, even a computer applications system with just a million records will give the end-users unacceptable response time delays. For this reason, data modeling is a keystone in the skills needed by a modern software developer.[citation needed]

## Database modeling techniques

The entity–relationship model proposes a technique that produces entity–relationship diagrams (ERDs), which can be employed to capture information about data model entity types, relationships and cardinality. A Crow's foot shows a one-to-many relationship. Alternatively a single line represents a one-to-one relationship.[4]

## Application program modeling approaches

In the object-oriented application programming paradigm, which is related to database structure design, UML class diagrams may be used for object modeling. In that case, object relationships are modeled using UML associations, and multiplicity is used on those associations to denote cardinality. Here are some examples:[5]

Relationship | Example | Left | Right  | Narrative

|
|
|
|

One-to-one | person ←→ birth certificate | 1 | 1 | A person must have their own birth certificate, it is specific to that person by its Id number.
One-to-one (optional on one side) | person ←→ driving license | 1 | 0..1 or ? | A person may have a driving license, it is specific to that person by its Id number.
One-to-many | order ←→ line item | 1 | 1..* or + | An order contains at least one item
Many-to-one | person ←→ birthplace | 1..* or + | 1 | Many people can be born in the same place, but 1 person can only be born in 1 birthplace
Many-to-many | course ←→ student | 1..* or + | 1..* or + | Students follow various courses
Many-to-many (optional on both sides) | person ←→ book | 0..* or * | 0..* or * | A person may own many books(copies), and a book may be owned by many people(readers).

## See also

* Arity
* Entity-relationship model
* Unified modeling language

## References

1. ↑ Clarke, Alex; Hasnani, Aleen; Al-Ahasan, Abdullah; Islam, Nazmul (7 September 2022). "Data Modeling and Entity Relationship Diagram (ERD)". https://www.cs.uregina.ca/Links/class-info/215/erd/.
2. ↑ "Entity Relationship Mapping". Oracle Corporation. https://docs.oracle.com/cd/A97688_16/generic.903/a97677/ormap.htm.
3. ↑ 3.0 3.1 Codd, E. F. (1990). The relational model for database management : version 2. Reading, Mass.: Addison-Wesley. ISBN 0-201-14192-2. OCLC 19590880. https://www.worldcat.org/oclc/19590880.
4. ↑ "Crow’s Foot Notation". University of Regina. http://www2.cs.uregina.ca/~bernatja/crowsfoot.html.
5. ↑ "Cardinality". datacadamia. 7 September 2022. https://datacadamia.com/data/type/relation/modeling/cardinality.

## External links

* UML multiplicity as data model cardinality \- http://www.agiledata.org
* Cardinality in Data Modeling \- Adam Alalouf, Temple University
* Cardinality on Techopedia
* Cardinality on Geeksforgeeks
* Database Cardinality on SQL World

* v
* t
* e

Database

Main|

* Requirements
* Theory
* Models
* Database management system
* Machine
* Server
* Application
* Connection
* datasource
* DSN
* Administrator
* Lock
* Types
* Tools

Languages|

* Data definition
* Data manipulation
* Query
* information retrieval

Security|

* Activity monitoring
* Audit
* Forensics
* Negative database

Design|

* Entities and relationships (and Enhanced notation)
* Normalization
* Refactoring
* Cardinality

Programming|

* Abstraction layer
* Object-relational mapping

Management|

* Virtualization
* Tuning
* caching
* Migration
* Preservation
* Integrity

See also|

* Database-centric architecture
* Intelligent database
* Two-phase locking
* Locks with ordered sharing
* Load file
* Publishing
* Halloween Problem
* Log shipping

* Book
* Category
* WikiProject

de:Kardinalität (Datenbanken) pt:Cardinalidade (modelagem de dados)

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/Cardinality (data modeling). Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Cardinality_(data_modeling)&oldid=205571"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template