Entity–relationship model
Entity–relationship modeling was developed for database and design by Peter Chen and published in a 1976 paper,[2] with variants of the idea existing previously.
An ER model usually results from systematic analysis to define and describe the data created and needed by processes in a business area.
Entities may be defined not only by relationships, but also by additional properties (attributes), which include identifiers called "primary keys".
The conceptual-logical-physical hierarchy below is used in other kinds of specification, and is different from the three schema approach to software engineering.
The data modeling technique can be used to describe any ontology (i.e. an overview and classifications of used terms and their relationships) for a certain area of interest.
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).
Another common extension to Chen's model is to "name" relationships and roles as verbs or phrases.
[clarification needed] Research by Merise, Elmasri & Navathe and others has shown there is a preference for same-side for roles and both minimum and maximum cardinalities,[10][11][12] and researchers (Feinerer, Dullea et al.) have shown that this is more coherent when applied to n-ary relationships of order greater than 2.
[13][14] Dullea et al. states: "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."
(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."
Attributes are drawn as ovals and connected with a line to exactly one entity or relationship set.
Crow's foot notation, the beginning of which dates back to an article by Gordon Everest (1976),[16] is used in Barker's notation, Structured Systems Analysis and Design Method (SSADM), and information technology engineering.
Many of the consultants at CACI (including Richard Barker) came from ICL and subsequently moved to Oracle UK, where they developed the early versions of Oracle's CASE tools, introducing the notation to a wider audience.
Users of a modeled database can encounter two well-known issues where the returned results differ from what the query author assumed.
Identifying and resolving these traps early in the design process helps avoid significant issues later, especially in complex databases intended for business intelligence or decision support.
This type of model resembles a star schema, which is a common design in data warehouses.
When attempting to calculate sums over aggregates using standard SQL queries based on the master table, the results can be unexpected and often incorrect due to the way relationships are structured.
Some database querying software designed for decision support includes built-in methods to detect and address fan traps.
However, if a Computer is temporarily not assigned to a Room (perhaps under repair or stored elsewhere), it won't be included in the query results.
This reflects a flaw in the model, as it fails to account for Computers that are in the Building but not in a Room.
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".
[24] Plato himself associates knowledge with the apprehension of unchanging Forms (namely, archetypes or abstract representations of the many types of things, and properties) and their relationships to one another.
