This model was introduced and formalized by Chen in 1976. It is one of the most popular data models for data conceptual modeling. It has three building blocks.
Entity types: They are similar to record types in the hierarchical or CODASYL model. The basic object that the ER model represents is an entity, which is a thing in the real world with an independent existence. An entity may be an object with a physical existence
(Ex: a particular person, car, house, or employee) or it may be an object with a conceptual existence
(Ex: a company, a job, or a university course. In other words, it represents a business concept with an unambiguous meaning to a particular set of users.Ex: A student, a product, a supplier, an employee
An entity type defines a collection of entities that have the same attributes and represent similar business concepts. Entities are said to be instances of that particular entity type.
Attribute types: Each entity has attributes, the particular properties that describe it. Ex: an EMPLOYEE entity may be described by the employee’s name, age, address, salary, and job. A particular entity will have a value for each of its attributes. The attribute values that describe each entity become a major part of the data stored in the database.
An attribute type defines a collection of similar attribute values. Attribute values are said to be instances of that particular attribute type.
Several types of attributes occur in the ER model :
Composite attributes can be divided into smaller subparts, which represent more basic attributes with independent meanings. For instance, the address attribute of the EMPLOYEE entity can be subdivided into street address, city, state, and Zip. Composite attributes can form a hierarchy; Ex: Street_address can be further subdivided into three simple component attributes: Number, Street, and apart he value of a composite attribute is the concatenation of the values of its component simple attributes.
Attributes that are not divisible are called simple or atomic attributes.
Most attributes have a single value for a particular entity; such attributes are called single-valued. Ex: age is a single-valued attribute of a person.
In some cases an attribute can have a set of values for the same entity. Ex: Colors attribute for a car. Cars with one color have a single value; whereas two-tone cars have two color values. Similarly, one person may not have a college degree, another person may have one, and a third person may have two or more degrees. Such attributes are called multivalued. A multivalued attribute may have lower and upper bounds to constrain the number of values allowed for each individual entity.
Derived attributes: in some cases, two or more attribute value are related, for example, the Age and Birth_date attributes of a person. For a particular person entity, the value of Age can be determined from the current date and the value of that person’s Birth date. Hence, the age attribute is called a derived attribute and is said to be derivable from the Birth date attribute which is called a stored attribute.
Stored attributes: in the previous example, the birth date attribute is called a stored attribute.
A key attribute type is an attribute type whose values are distinct for each individual entity. In other words, it can be used to uniquely identify each entity. Ex: SUPNR, which is unique for each supplier, PRODNUR, which is unique for each product, the SSN, which is unique for each employee. The key attribute type can also be a combination of attribute types. Ex: a flight identified by a flight number. But this number is represented each day for a particular flight. Therefore, the departure date is needed to identify the entities.= uniqueness constraint.
We have an entity type supplier. Entity types are represented as rectangles in ER models. Attribute types are represented using ellipses. Address is modeled as a composite attribute type consisting of Street, number, zip, city and country. SUPNR is underlined since it is the key attribute type. The dubble lined indicate that email is multivalued. The dash lined indicate that age it is a derived attirbute type calculated base on birth-date.
Relationship types : A relationship represents an association between two or more entities. Ex: a supplier supplying a set of products. A relationship type defines a set of relationships among instances of 1, 2 or more entity types.
Relationship types are represented using a rumble symbol in the ER model. Basically the rhombus can be represented with two adjacent arrows pointing to each of the entity types.
The degree corresponds to the number of entity types participating in the relationship type.
- A relationship type of degree one is called unary.
- A relationship type of degree two is called binary.
- A relationship type of degree three is called ternary.
The roles of a relationship type indicate the various directions of interpreting a relationship type.Ex: adding in an arrow “Supervises” and “supervised by”.
Cardinality ratios specify the minimum/maximum number of relationship instances that an entity can participate in.
The minimum cardinality can either be zero or one. If it is zero it implies that an entity can occur without being connected to another entity. This can be referred to as partial participation. In case the minimum cardinality is one, the entity must always be connected to at least one other entity. This is referred to as total participation or existence dependency since the existence of this entity depends on the existence of another.
The maximum cardinality can either be one or n. In case it is one, an entity can be connected to at most one other entity. In case the maximum is N, an entity can be connected to at most N entities. Relationships types are often characterized by means of their maximum cardinalities.
For binary relationships, there are 4 options :
- 1:1
- 1:N
- N:1
- M: N
Relationship types can also have attribute types, similar to those of entity types. These can be migrated to one of the participating entity types. Attribute types belonging to M:N relationship types cannot be determined by a single entity type. They can only be specified as a relationship attribute type.
Weak entity types are a special class of entity types. These are entity types that do not have key attribute types of their own. Entities belonging to a weak entity type are identified being related to specific entities from another entity type (the owner entity type) in combination with some of their own attributes (called partial keys). A weak entity type is always existence depend from this owner entity type. An existence depend entity type does not imply a weak entity type.
Ex: A hotel administration. Hotel has an HNR and Hotel name. Every hotel has a unique hotel number. Hence HNR is the key attribute. A room is identified by a room number and a number of beds. Within a particular hotel, each room has a unique room number but a room number can appear for multiple rooms being in different hotels. Hence RNR does not suffice the key attribute. The entity type room is therefore a weak entity type since it cannot produce its own attribute type. It needs to borrow HNR from hotel to come up with a key attribute type which is now a combination of RNR and HNR.
In contrast, regular entity types that do have a key attribute are called strong entity types.
The ER model has an attractive and user-friendly graphical notation. Hence, it has the ideal properties to build a conceptual scheme or model.
A domain specifies the set of values that may be assigned to an attribute for each individual entity. A domain gender can be specified as having only two values: male and female. A date domain allows finding dates as days, followed by months, followed by years. By convention, domains are not displayed in ER diagrams. A domain can also contain Null values, which means the value is not applicable, not relevant or not known. It is thus not the same as the value zero. Ex: domain email address which allows for null values in case the email address is not known.