Entity Relationship ModelingChapter 11

Objectives

•ER Model•Entity type•Relationship type•Attribute•Cardinality and modality•Symbols•Examples

ER Model• It is a semantic data model that is used for the

graphical representation of the conceptual database design.

• An ER Model is a detailed, logical representation of the data for an organization or for a business area.

• It is expressed in terms of entities in the business environment, the relationships (or associations) among those entities, and the attributes of both the entities and their relationships.

• An ER model is normally expressed as an entity-relationship diagram which is graphical representation of an ER model.

Concepts of the ER Model

•Entity types•Relationship types•Attributes

Entity Types

•Entity type▫Group of objects with same properties, identified

by enterprise as having an independent existence.

•Entity occurrence▫Uniquely identifiable object of an entity type.

Example of Entity Type

Relationship Types

•Relationship type▫Set of meaningful associations among entity types.

•Relationship occurrence▫Uniquely identifiable association, which includes

one occurrence from each participating entity type.

Attributes

•Attribute▫Property of an entity or a relationship type.

•Attribute Domain▫Set of allowable values for one or more attributes.

Symbols

Example

Attribute Types

•Simple Attribute▫Attribute composed of a single component with an

independent existence.▫E.g. salary attribute of Staff entity.

•Composite Attribute▫Attribute composed of multiple components, each

with an independent existence.▫E.g. address attribute of Branch entity can be

subdivided into city, street and postcode attributes.

Composite Attribute Representation

Attribute Types (Contd.)•Single-valued Attribute

▫Attribute that holds a single value for each occurrence of an entity type.

▫E.g. each occurrence of the Branch entity type has a single value for the branchNo attribute.

•Multi-valued Attribute▫Attribute that holds multiple values for each

occurrence of an entity type. ▫Each occurrence of the Branch entity type can have

multiple values for telNo attribute.

Attribute Types (Contd.)•Derived Attribute

▫Attribute that represents a value that is derivable from value of a related attribute, or set of attributes, not necessarily in the same entity type.

▫E.g. age attribute of Staff entity type can be calculated from dateOfBirth attribute.

Symbols (Attribute Types)

Entity Type•Strong Entity Type

▫Entity type that is not existence-dependent on some other entity type.

▫Instances of a strong entity type always have a unique characteristic (called identifier)

▫E.g. Student, Employee, Course etc

•Weak Entity Type▫Entity type that is existence-dependent on some

other entity type.

Entity types

Entity Type• Employee is a strong entity type with identifier

employee_id (denoted by underline). • Dependent is a weak entity type, indicated by

double-lined rectangle.• The relationship between a weak entity type

and its owner is called an identifying relationship. (indicated by double lined diamond symbol)

• The attribute dependent_name serves as partial identifier (indicated by double undderline).

• During a later design stage, dependent_name will be combined with employee_id to form a full identifier for Dependent.

Cardinality and Modality• Cardinality is the specification of the number

of occurrences of one [object] that can be related to the number of occurrences of another [object]. Cardinality is usually expressed as simply 'one' or 'many.'

• Cardinality defines “the maximum number of objects that can participate in a relationship”.

• The modality of a relationship is 0 if there is no explicit need for the relationship to occur or the relationship is optional. The modality is 1 if an occurrence ofthe relationship is mandatory.

Symbols

Example

Degree of relationship•The number of entity types that

participate in a relationship.•3 typesUnary: Relationship between instances of

a single entity typeBinary: Relationship between instances of

two entity typesTernary: A simultaneous relationship

among instances of three entity types

Types of relationships

• One-to-one (l:l)—An occurrence of [object] 'A' can relate to one and only one occurrence of [object] 'B,' and an occurrence of 'B' can relate to only one occurrence of 'A.'

• One-to-many (l:N)—One occurrence of [object] 'A' can relate to one or many occurrences of [object] 'B,' but an occurrence of 'B' can relate to only one occurrence of 'A.’

• Many-to-many (M:N)—An occurrence of [object] 'A' can relate to one or more occurrences of 'B,' while an occurrence of 'B' can relate to one or more occurrences of 'A.’

Relationship types and Examples

One-to-many

Relationship types and Examples

Many-to-many

One-to-one

Relationship types and Examples

Examples

Exercise

Make ERD for a “has” relationship between patient and patient history entity types.

Make ERD for “is_assigned_to” relationship between employee and project entity types.

Associative EntityAn associative entity is an entity type that associates the instances or more entity types and contains attributes that are peculiar to the relationship between those entity instances.

Symbol:

When to convert relationship to an associative entity type?

Following are four conditions that should exist:

All of the relationships for the participating entity types are “many” relationships.

The resulting associative entity type has independent meaning to end users, and preferably can be identified with a single-attribute identifier.

The associative entity has one or more attributes, in addition to the identifier.

The associative entity participates in one or more relationships independent of the entities related in the associated relationship.

Associative Entity-Example

Multiple RelationshipsIn some situations, an organization may wish to model more than one relationship between the same entity types.

Examples-Multiple Relationships

Enhanced E-R Model

The model that has resulted from extending the original E-R model with new modeling constructs.

The most important modeling construct incorporated in the EER model is super-type/subtype relationships. This facility enables us to model a general entity type (called the supertype) and then subdivide it into several specialized entity types (called subtypes).

For example the entity type CAR can be modeled as a supertype, with subtypes SEDAN, SPORTS CAR, COUPE, and so on.

Each subtype inherits attributes from its supertype and in addition may have special attributes and be involved in relationships of its own.

Representing supertypes and subtypes

Subtype: A subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings.

Supertype: A generic entity type that has a relationship with one or more subtypes.

Basic Concepts and NotationThe supertype is connected with a line to a circle, which in turn is connected by a line to each subtype that has been defined.

The U-shaped symbol on each line connecting a subtype to the circle emphasizes that the subtype is a subset of the supertype. It also indicates the direction of the subtype/supertype relationship.

Basic Concepts and Notation (Contd.)

ExampleSuppose that an organization has three basic types of employees: hourly employees, salaried employees, and contract consultants. Some of the important attributes for each of these types of employees are the following:

Hourly employees: Emp_Number, Emp_Name, Address, Date_Hired, Hourly_Rate

Salaried employees: Employee_Number, Employee_Name, Address, Date_Hired, Annual_Salary, Stock_Option

Contract consultants: Employee_Number, Employee_Name, Address, Date_Hired, Contract_Number, BiI1ing_Rate

Notice that all of the employee types have several attributes in common: Employee_Number, Employee_Name, Address, and Date_Hired. In addition, each type has one or more attributes distinct from the attributes of other types (e.g., Hourly_Rate is unique to hourly employees).

Employee supertype with three subtypes

When to Use Supertype/Subtype RelationshipsWhether to use supertype/subtype relationships is a decision that the data modeler must make in each situation. You should consider using subtypes when either (or both) of the following conditions are present:

1. There are attributes that apply to some (but not all) instances of an entity type.

2. The instances of a subtype participate in a relationship unique to that subtype.

Supertype/subtype relationships in a hospital

Representing Specialization and GeneralizationGeneralization: The process of defining a more general entity type from a set of more specialized entity types.

Specialization: The process of defining one or more subtypes of the supertype and forming supertype/subtype relationships.

Example of generalization

Example of generalization (Contd.)

Example of Specialization

Example of Specialization (Contd.)

Specifying constraints in supertype/subtype relationshipsCompleteness constraint: A type of constraint that addresses the question whether an instance of a supertype must also be a member of at least one subtype.

Total specialization rule: Specifies that each entity instance of the supertype must be a member of some subtype in the relationship.

Partial specialization rule: Specifies that an entity instance of the supertype is allowed not to belong to any subtype.

Examples of completeness constraints

Examples of completeness constraints (Contd.)

Specifying constraints in supertype/subtype relationships (Contd.)Disjointncss constraint: A constraint that addresses the question whether an instance of a supertype may simultaneously be a member of two (or more) subtypes.

Disjoint rule: Specifies that if an entity instance (of a supertype) is a member of one subtype, it cannot simultaneously be a member of any other subtype.

Overlap rule: Specifies that an entity instance can simultaneously be a member of two (or more) subtypes.

Examples of disjointness constraints

Examples of disjointness constraints (Contd.)

The End