Entity-relationship model

The entity-relationship (E-R) data model was developed to facilitate database design
by allowing specification of an enterprise schema that represents the overall logical
structure of a database. The E-R model is very useful in mapping the meanings and
interactions of real-world enterprises onto a conceptual schema. The E-R data model
employs three basic concepts: entity sets, relationship sets, and attributes. The E-R
model also has an associated diagrammatic representation, the E-R diagram to
pictorially represent the database.
Entity
An entity is a “thing” or “object” in the real world that is distinguishable from all other
objects. For example, each person in a university is an entity. An entity has a set of
properties, and the values for some set of properties may uniquely identify an entity.
For instance, a person may have a person id property whose value uniquely identifies
that person.
Entity Set
An entity set is a set of entities of the same type that share the same properties, or
attributes. The set of all people who are instructors at a given university, for example,
can be defined as the entity set instructor. Similarly, the entity set student might
represent the set of all students in the university.
Relationships
A relationship is an association among several entities. For example, we can define a
relationship advisor that associates instructor Katz with student Shankar. This
relationship specifies that Katz is an advisor to student Shankar.
Relationship set
A relationship set is a set of relationships of the same type. Formally, it is a
mathematical relation on n ≥ 2 (possibly non-distinct) entity sets.
If E1, E2, ..., En are entity sets, then a relationship set R is a subset of
{(e1, e2, ..., en) | e1 ∈ E1, e2 ∈ E2, ..., en ∈ En} where (e1, e2, ..., en) is a relationship.
The association between entity sets is referred to as participation; that is, the entity
sets E1, E2, ..., En participate in relationship set R. A relationship instance in an E-R
schema represents an association between the named entities in the real-world
enterprise that is being modelled.
The function that an entity plays in a relationship is called that entity’s role. Since entity
sets participating in a relationship set are generally distinct, roles are implicit and are
not usually specified.
The relationship sets advisor and dept advisor provide examples of a binary
relationship set— that is, one that involves two entity sets. Most of the relationship
sets in a database system are binary. Occasionally, however, relationship sets involve
more than two entity sets.
The number of entities sets that participate in a relationship set is the degree of the
relationship set. A binary relationship set is of degree 2; a ternary relationship set is of
degree 3.
A relationship may also have attributes called descriptive attributes.
Attributes
An entity is represented by a set of attributes. Attributes are descriptive properties
possessed by each member of an entity set. The designation of an attribute for an
entity set expresses that the database stores similar information concerning each
entity in the entity set; however, each entity may have its own value for each attribute.
Each entity has a value for each of its attributes.
For each attribute, there is a set of permitted values, called the domain, or value set,
of that attribute. The domain of attribute course id might be the set of all text strings of
a certain length. Similarly, the domain of attribute semester might be strings from the
set {Fall, Winter, Spring, Summer}.
An attribute, as used in the E-R model, can be characterized by the following attribute
types.
Simple and composite attributes. In our examples thus far, the attributes have been
simple; that is, they have not been divided into subparts. Composite attributes, on the
other hand, can be divided into subparts (that is, other attributes). For example, an
attribute name could be structured as a composite attribute consisting of first name,
middle initial, and last name. Composite attributes help us to group together related
attributes, making the modelling cleaner. Note also that a composite attribute may
appear as a hierarchy.
Single-valued and multivalued attributes. The attributes in our examples all have a
single value for a particular entity. For instance, the student ID attribute for a specific
student entity refers to only one student ID. Such attributes are said to be single
valued. Suppose we add to the instructor entity set a phone number attribute. An
instructor may have zero, one, or several phone numbers, and different instructors
may have different numbers of phones. This type of attribute is said to be multivalued.
To denote that an attribute is multivalued, we enclose it in braces, for example {phone
number} or {dependent name}. Where appropriate, upper and lower bounds may be
placed on the number of values in a multivalued attribute.
Derived attribute and stored attributes. The value for this type of attribute can be
derived from the values of other related attributes or entities. For instance, let us say
that the instructor entity set has an attribute students advised, which represents how
many students an instructor advises. We can derive the value for this attribute by
counting the number of student entities associated with that instructor. In a DBMS,
stored attributes are the data that remain constant and fixed for an entity instance.
These values help in deriving the derived attributes. For example: consider a customer
entity in a bank. The customer's name, age, and address would be stored attributes.
Complex attribute in DBMS involves both multivalued and composite attributes. For
example, someone might have more than one house, and each house can be
composite. The address is then considered a complex attribute.