Editing Entity–relationship model (section)

== Components ==
[[Image:Erd-entity-relationship-example1.svg|frame|Two related entities]]
[[Image:Erd-entity-with-attribute.svg|thumb|An entity with an attribute]]
[[Image:erd-relationship-with-attribute.svg|thumb|A relationship with an attribute]]
[[Image:Erd-id-as-primary-key.svg|frame|[[Primary key]]]]

An [[wikt:entity|''entity'']] may be defined as a thing that is capable of an independent existence that can be uniquely identified, and is capable of storing data.{{sfn | Bagui | Earp | 2022 | loc=§4.3 | p=73-74}} An entity is an abstraction from the complexities of a domain. When we speak of an entity, we normally speak of some aspect of the real world that can be distinguished from other aspects of the real world.<ref>{{cite book |last=Beynon-Davies |first=Paul |date=2004 |title=Database Systems |location=Basingstoke, UK: Palgrave |publisher=Houndmills |isbn=978-1403916013}}</ref>

An entity is a thing that exists either physically or logically. An entity may be a physical object such as a house or a car (they exist physically), an event such as a house sale or a car service, or a concept such as a customer transaction or order (they exist logically—as a concept). Although the term entity is the one most commonly used, following Chen, entities and entity-types should be distinguished. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym.

Entities can be thought of as [[noun]]s.{{sfn | Bagui | Earp | 2022 | loc=§5.5 | p=112-116}} Examples include a computer, an employee, a song, or a mathematical theorem.

A ''relationship'' captures how entities are related to one another. Relationships can be thought of as [[verb]]s, linking two or more nouns.{{sfn | Bagui | Earp | 2022 | loc=§5.5 | p=112-116}} Examples include an ''owns'' relationship between a company and a computer, a ''supervises'' relationship between an employee and a department, a ''performs'' relationship between an artist and a song, and a ''proves'' relationship between a mathematician and a conjecture.

The model's linguistic aspect described above is used in the [[declarative programming language|declarative]] database [[query language]] ERROL, which mimics [[natural language]] constructs. ERROL's [[semantics]] and implementation are based on reshaped relational algebra (RRA), a [[relational algebra]] that is adapted to the entity–relationship model and captures its linguistic aspect.

Entities and relationships can both have attributes. For example, an ''employee'' entity might have a ''Social Security Number'' (SSN) attribute, while a ''proved'' relationship may have a ''date'' attribute.

All entities except [[weak entity|weak entities]] must have a minimal set of uniquely identifying attributes that may be used as a [[unique key|unique]]/[[primary key|primary]] key.

Entity-relationship diagrams (ERDs) do not show single entities or single instances of relations. Rather, they show entity sets (all entities of the same entity type) and relationship sets (all relationships of the same relationship type). For example, a particular ''song'' is an entity, the collection of all songs in a database is an entity set, the ''eaten'' relationship between a child and his lunch is a single relationship, and the set of all such child-lunch relationships in a database is a relationship set.
In other words, a relationship set corresponds to a [[relation (mathematics)|relation in mathematics]], while a relationship corresponds to a member of the relation.

Certain [[cardinality (data modeling)|cardinality constraint]]s on relationship sets may be indicated as well.

{|class="wikitable"
|+ Guiding rules for mapping natural language descriptions into ER diagrams<ref>[http://bit.csc.lsu.edu/~chen/pdf/ER_C.pdf "English, Chinese and ER diagrams"] by Peter Chen</ref>
|-
! English grammar structure !! ER structure
|-
| [[Common noun]] || Entity type
|-
| [[Proper noun]] || Entity
|-
| [[Transitive verb]] || Relationship type
|-
| [[Intransitive verb]] || Attribute type
|-
| [[Adjective]] || Attribute for entity 
|-
| [[Adverb]] || Attribute for relationship
|}

Physical views show how data is actually stored.

===Relationships, roles, and cardinalities===
Chen's original paper gives an example of a relationship and its roles. He describes a relationship "marriage" and its two roles, "husband" and "wife".

A person plays the role of husband in a marriage (relationship) and another person plays the role of wife in the (same) marriage. These words are nouns.

Chen's terminology has also been applied to earlier ideas. The lines, arrows, and crow's feet of some diagrams owes more to the earlier [[Data structure diagram|Bachman diagrams]] than to Chen's relationship diagrams.

Another common extension to Chen's model is to "name" relationships and roles as verbs or phrases.

===Role naming===
It has also become prevalent to name roles with phrases such as ''is the owner of'' and ''is owned by''. Correct nouns in this case are ''owner'' and ''possession''. Thus, ''person plays the role of owner'' and ''car plays the role of possession'' rather than ''person plays the role of'', ''is the owner of'', etc.

Using nouns has direct benefit when generating physical implementations from semantic models. When a ''person'' has two relationships with ''car'' it is possible to generate names such as ''owner_person'' and ''driver_person'', which are immediately meaningful.<ref>{{Cite web|url=http://pangrammaticon.blogspot.com/2013/01/emotion-and-society.html|title=The Pangrammaticon: Emotion and Society|date=January 3, 2013}}</ref>

===Cardinalities===
Modifications to the original specification can be beneficial. Chen described [[look-across cardinality|look-across cardinalities]]. As an aside, the [[Barker's notation|Barker–Ellis]] notation, used in Oracle Designer, uses same-side for minimum cardinality (analogous to optionality) and role, but look-across for maximum cardinality (the crow's foot).{{clarify|This whole section is almost incomprehensible!  Please define 'cardinalities', 'look-across', etc.|date=April 2012}}

Research by [[Merise]], Elmasri & Navathe and others has shown there is a preference for same-side for roles and both minimum and maximum cardinalities,<ref>Hubert Tardieu, Arnold Rochfeld and René Colletti La methode MERISE: Principes et outils (Paperback - 1983)</ref><ref>Elmasri, Ramez, B. Shamkant, Navathe, Fundamentals of Database Systems, third ed., Addison-Wesley, Menlo Park, CA, USA, 2000.</ref><ref>{{Cite book |last1=Atzeni |first1=Paolo |url=https://books.google.com/books?id=odZK99osY1EC&q=genova&pg=PA52 |title=ER 2004 : 23rd International Conference on Conceptual Modeling, Shanghai, China, November 8-12, 2004 |last2=Chu |first2=Wesley |last3=Lu |first3=Hongjun |last4=Ling |first4=Tok Wang |last5=Zhou |first5=Shuigeng |date=2004-10-27 |isbn=9783540237235}}</ref> and researchers (Feinerer, Dullea et al.) have shown that this is more coherent when applied to n-ary relationships of order greater than&nbsp;2.<ref>{{Cite web |title=A Formal Treatment of UML Class Diagrams as an Efficient Method for Configuration Management 2007 |url=http://publik.tuwien.ac.at/files/pub-inf_4582.pdf}}</ref><ref>{{Cite web |title=James Dullea, Il-Yeol Song, Ioanna Lamprou - An analysis of structural validity in entity-relationship modeling 2002 |url=http://www.ischool.drexel.edu/faculty/song/publications/p_DKE_03_Validity.pdf |archive-url=https://web.archive.org/web/20090424030434/http://www.ischool.drexel.edu/faculty/song/publications/p_DKE_03_Validity.pdf |url-status=dead |archive-date=April 24, 2009 }}</ref>

Dullea et al. states: "A 'look across' notation such as used in the [[Unified Modelling Language|UML]] does not effectively represent the semantics of participation constraints imposed on relationships where the degree is higher than binary."

Feinerer says: "Problems arise if we operate under the look-across semantics as used for UML associations. Hartmann<ref>Hartmann, Sven. "[http://crpit.com/confpapers/CRPITV17Hartmann.pdf Reasoning about participation constraints and Chen's constraints] {{Webarchive|url=https://web.archive.org/web/20130510031920/http://crpit.com/confpapers/CRPITV17Hartmann.pdf |date=2013-05-10 }}". Proceedings of the 14th Australasian database conference-Volume 17. Australian Computer Society, Inc., 2003.</ref> investigates this situation and shows how and why different transformations fail." ''(Although the "reduction" mentioned is spurious as the two diagrams 3.4 and 3.5 are in fact the same)'' and also "As we will see on the next few pages, the look-across interpretation introduces several difficulties that prevent the extension of simple mechanisms from binary to n-ary associations."

[[File:ERD Representation.svg|thumb|320px|Various methods of representing the same one to many relationship. In each case, the diagram shows the relationship between a person and a place of birth: each person must have been born at one, and only one, location, but each location may have had zero or more people born at it.]]
[[Image:ERD-artist-performs-song.svg|thumb|320px|Two related entities shown using Crow's Foot notation. In this example, an optional relationship is shown between Artist and Song; the symbol composed of branching lines, closest to the song entity represents "zero, one, or many", whereas a song has "one and only one" Artist, emphasized by the symbol composed of parallel lines. The former is therefore read as, an Artist (can) perform(s) "zero, one, or many" song(s).]] Chen's notation for entity–relationship modeling uses rectangles to represent entity sets, and diamonds to represent relationships appropriate for [[first-class object]]s: they can have attributes and relationships of their own. If an entity set participates in a relationship set, they are connected with a line.

Attributes are drawn as ovals and connected with a line to exactly one entity or relationship set.

Cardinality constraints are expressed as follows:
* a double line indicates a ''participation constraint'', [[total relation|totality]], or [[surjective function|surjectivity]]: all entities in the entity set must participate in ''at least one'' relationship in the relationship set;
* an arrow from an entity set to a relationship set indicates a [[unique key|key constraint]], i.e. [[injective relation|injectivity]]: each entity of the entity set can participate in ''at most one'' relationship in the relationship set;
* a thick line indicates both, i.e. [[bijection|bijectivity]]: each entity in the entity set is involved in ''exactly one'' relationship.
* an underlined name of an attribute indicates that it is a [[unique key|key]]: two different entities or relationships with this attribute always have different values for this attribute.

Attributes are often omitted as they can clutter up a diagram. Other diagram techniques often list entity attributes within the rectangles drawn for entity sets.