Entity Relationship Model

Structured data is stored in databases. Along with various other constraints, this data’s structure can be designed using entity relationship modeling, with the end result being an entity relationship diagram. Data modeling entails the usage of a notation for the representation of data models. An entity relationship diagram can be thought of as a type of semantic data model, or a conceptual one.

Entity relationship models are used during the first stage of information system design in order to elucidate types of info that are needed to be stored in the database during the phase of requirements analysis. Any ontology can be described via the data modeling technique for a specific area of interest. If the information system being designed is based on a database, then the conceptual data model will later be mapped on to a logical data model, which in turn will be mapped on to a physical model during the physical design process. (Sometimes both of these phases are referred to as “physical design.”)

Numerous conventions exist for entity relationship diagrams. Conceptual modeling is based largely on classical notation. Other notations, mostly used in physical and logical database design, include ICAM Definition Language, dimensional modeling, and information engineering.

An entity can be thought of as the representation of a discrete object. They are also nouns. So, for example, a song is an entity, as is an employee, a computer, a mathematical theorem, etc.

Relationships capture how entities relate to one another. Relationships are also verbs. “Supervises” might designate the relationship between an overseer and a department, “performs” serves to describe the relationship between an actor and a role, etc.

Whereas relationships are drawn as diamonds, entities are represented in the form of rectangles.

Attributes are unique qualities that can be possessed by both relationships and entities. Attributes are represented by ovals, which are connected to the entity sets that possess them by a line. With the exception of weak entities, all entities have to have a minimum amount of attributes. These make up the primary key of the entity.

Rather than displaying single instances of relations or lone entities, entity relationship diagrams display sets of entities and relationships. So, one song on a database is an entity, whereas a collection of songs on the database is the entity set.

Lines connect sets of entities to the sets of relationships with which they are involved. A thick line, known as a participation constraint, will be drawn in those instances when all the entities in a particular set are involved with the relationship set. If it is possible for every entity in an entity set to participate in at most one relation in the set of relationships, an arrow, known as a key constraint, will be drawn connecting the set of entities to the set of relationships. A thick arrow represents that every entity in a set of entities is involved in one relationship.

A couple of other useful definitions:

Associative entities are often used to solve the conflict of a couple of entities with many-to-many relationships.

Unary relationships are those relationships between the rows of a single table.

Weak entities cannot be identified with the help of its own attributes. It is thus necessary to use these entities’ primary keys, as well as the primary key of an entity that is related to it.

In an entity relationship model, attributes can be composite, derived, or multi-valued. Multi-valued attributes might have more than one value in one or more instances of its entity. These attributes are denoted with a two line ellipse. So, if a piece of software happens to run on more than one operating system, it could have the attribute “platform”; this is a multi-valued attribute. Composite attributes, on the other hand, are those attributes that might contain two or more attributes.

A composite attribute will have contributing attributes of its own. An example of a composite attribute is an address, as it is composed of attributes that include street address, city, state/region, country, etc. Finally, there are derived attributes. The value of these attributes is dependent wholly on another attribute. Derived attributes are denoted with dashed ellipses. So, in a database of employees that has an age attribute, the age attribute would have to be derived from an atttribute of birth dates.