Entity–relationship model


An entity–relationship model describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types and specifies relationships that can exist between .
using Chen's notation.
In software engineering, an ER model is commonly formed to represent things a business needs to remember in order to perform business processes. Consequently, the ER model becomes an abstract data model, that defines a data or information structure which can be implemented in a database, typically a relational database.
Entity–relationship modeling was developed for database and design by Peter Chen and published in a 1976 paper, with variants of the idea existing previously. Some ER models show super and subtype entities connected by generalization-specialization relationships, and an ER model can be used also in the specification of domain-specific ontologies.

Introduction

An E-R model is usually the result of systematic analysis to define and describe what is important to processes in an area of a business. It does not define the business processes; it only presents a business data schema in graphical form. It is usually drawn in a graphical form as boxes that are connected by lines which express the associations and dependencies between entities. An ER model can also be expressed in a verbal form, for example: one building may be divided into zero or more apartments, but one apartment can only be located in one building.
Entities may be characterized not only by relationships, but also by additional properties, which include identifiers called "primary keys". Diagrams created to represent attributes as well as entities and relationships may be called entity-attribute-relationship diagrams, rather than entity–relationship models.
An ER model is typically implemented as a database. In a simple relational database implementation, each row of a table represents one instance of an entity type, and each field in a table represents an attribute type. In a relational database a relationship between entities is implemented by storing the primary key of one entity as a pointer or "foreign key" in the table of another entity.
There is a tradition for ER/data models to be built at two or three levels of abstraction. Note that the conceptual-logical-physical hierarchy below is used in other kinds of specification, and is different from the three schema approach to software engineering.
;Conceptual data model
;Logical data model
;Physical data model
The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. The data modeling technique can be used to describe any ontology for a certain area of interest. In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage, mapped to a logical data model, such as the relational model; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases are referred to as "physical design."

Entity–relationship model

An may be defined as a thing capable of an independent existence that can be uniquely identified. 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.
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, an event such as a house sale or a car service, or a concept such as a customer transaction or order. Although the term entity is the one most commonly used, following Chen we should really distinguish between an entity and an entity-type. 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 for this term
Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem, etc.
A relationship captures how entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: 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, a proves relationship between a mathematician and a conjecture, etc.
The model's linguistic aspect described above is utilized in the declarative database query language ERROL, which mimics natural language constructs. ERROL's semantics and implementation are based on reshaped relational algebra, a relational algebra that is adapted to the entity–relationship model and captures its linguistic aspect.
Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number attribute, while a proved relationship may have a date attribute.
Every entity must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.
Entity–relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Examples: 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; 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 in mathematics, while a relationship corresponds to a member of the relation.
Certain cardinality constraints on relationship sets may be indicated as well.

Mapping natural language

Chen proposed the following "rules of thumb" for mapping natural language descriptions into ER diagrams: by Peter Chen.
English grammar structureER structure
Common nounEntity type
Proper nounEntity
Transitive verbRelationship type
Intransitive verbAttribute type
AdjectiveAttribute for entity
AdverbAttribute for relationship

Physical view show how data is actually stored.

Relationships, roles and cardinalities

In Chen's original paper he 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 and another person plays the role of wife in the marriage. These words are nouns. That is no surprise; naming things requires a noun.
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 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.
The use of nouns has direct benefit when generating physical implementations from semantic models. When a person has two relationships with car then it is possible to generate names such as owner_person and driver_person, which are immediately meaningful.

Cardinalities

Modifications to the original specification can be beneficial. Chen described look-across cardinalities. As an aside, the Barker–Ellis notation, used in Oracle Designer, uses same-side for minimum cardinality and role, but look-across for maximum cardinality.
In Merise, Elmasri & Navathe and others there is a preference for same-side for roles and both minimum and maximum cardinalities. Recent researchers have shown that this is more coherent when applied to n-ary relationships of order greater than 2.
In Dullea et al. one reads "A 'look across' notation such as used in the UML does not effectively represent the semantics of participation constraints imposed on relationships where the degree is higher than binary."
In Feinerer it says "Problems arise if we operate under the look-across semantics as used for UML associations. Hartmann investigates this situation and shows how and why different transformations fail." 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."
Chen's notation for entity–relationship modeling uses rectangles to represent entity sets, and diamonds to represent relationships appropriate for first-class objects: 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 are connected with a line to exactly one entity or relationship set.
Cardinality constraints are expressed as follows:
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.
Related diagramming convention techniques:
Crow's foot notation, the beginning of which dates back to an article by Gordon Everest, is used in Barker's notation, Structured Systems Analysis and Design Method and information technology engineering. Crow's foot diagrams represent entities as boxes, and relationships as lines between the boxes. Different shapes at the ends of these lines represent the relative cardinality of the relationship.
Crow's foot notation was used in the consultancy practice CACI. Many of the consultants at CACI subsequently moved to Oracle UK, where they developed the early versions of Oracle's CASE tools, introducing the notation to a wider audience.
With this notation, relationships cannot have attributes. Where necessary, relationships are promoted to entities in their own right: for example, if it is necessary to capture where and when an artist performed a song, a new entity "performance" is introduced, and the relationship of an artist to a song becomes an indirect relationship via the performance.
Three symbols are used to represent cardinality:
These symbols are used in pairs to represent the four types of cardinality that an entity may have in a relationship. The inner component of the notation represents the minimum, and the outer component represents the maximum.
In using a modeled database, users can encounter two well known issues where the returned results mean something other than the results assumed by the query author.
The first is the 'fan trap'. It occurs with a table that links to multiple tables in a one-to-many relationship. The issue derives its name from the way the model looks when it's drawn in an entity–relationship diagram: the linked tables 'fan out' from the master table. This type of model looks similar to a star schema, a type of model used in data warehouses. When trying to calculate sums over aggregates using standard SQL over the master table, unexpected results may occur. The solution is to either adjust the model or the SQL. This issue occurs mostly in databases for decision support systems, and software that queries such systems sometimes includes specific methods for handling this issue.
The second issue is a 'chasm trap'. A chasm trap occurs when a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences. For example, a Building has one-or-more Rooms, that hold zero-or-more Computers. One would expect to be able to query the model to see all the Computers in the Building. However, Computers not currently assigned to a Room are not shown on the list. Another relation between Building and Computers is needed to capture all the computers in the building. This last modelling issue is the result of a failure to capture all the relationships that exist in the real world in the model. See for details.

Entity–relationships and semantic modeling

Semantic model

A semantic model is a model of concepts, it is sometimes called a "platform independent model". It is an intensional model. At the latest since Carnap, it is well known that:

Extension model

An extensional model is one that maps to the elements of a particular methodology or technology, and is thus a "platform specific model". The UML specification explicitly states that associations in class models are extensional and this is in fact self-evident by considering the extensive array of additional "adornments" provided by the specification over and above those provided by any of the prior candidate "semantic modelling languages".

Entity–relationship origins

Peter Chen, the father of ER modeling said in his seminal paper:
In his original 1976 article Chen explicitly contrasts entity–relationship diagrams with record modelling techniques:
Several other authors also support Chen's program:

Philosophical alignment

Chen is in accord with philosophical traditions from the time of the Ancient Greek philosophers: Plato and Aristotle. Plato himself associates knowledge with the apprehension of unchanging Forms and their relationships to one another.

Limitations