Presentation Contents

• An Introduction• Entities & Relationships• Cardinality, Degree, Existence of Relationships• Attributes and Identifiers• Building an Entity-Relationship model

History of

E-R Model

An Introduction

• E-R Model was proposed by Dr. Peter Chen (currently professor at Louisiana State University)

• Chen’s original paper on E-R Model is the 35th most sited paper in computer science

• Chen has written papers interconnecting E-R model and linguistics

Database Life Cycle

An Introduction

Requirements• specification of customer/user needs/desiresDesign• specification of potential solution or solution approachImplementation• providing the solutionTest Results• evaluations, inferences, reports, documentationModifications• changes/additions to solution

An Introduction

The three schema approach to software engineering uses three levels of ER models that was developed.

Conceptual data modelLogical data modelPhysical data model

The Conceptual Model• Conceptual model captures the global/institutional view of the data semantics.• It investigates and enumerates the various entities that participate in the

business environment being modelled

Conceptual Data Model

Features of E-R Model

An Introduction

1. Diagrammatic.2. Simple but expressive.3. Easy to map into traditional DBMS models.4. Extensions > Extended ER Model > Entity Category Relationship Model > Enhanced ER Model

E-R Modeling

Entities & Relationships

Entity-Relationship (E-R) Modeling is aconceptual modeling tool.

perceives the business environment in terms ofparticipating “entities” and the “relationship”between them.e.g. many employees work for a department

E-R Modeling

Entities & Relationships

Entityis a “data object”models some object/entity in the real-world;entity type represents the set of all similarobjects.identified by the nouns in the requirementsspecification.must have a name that is unique across theentire model and has a consistent meaningacross the modelling team and the end users.

EMPLOYEE

E-R Modeling

Entities & Relationships

Attributescharacteristics/properties of an entity, thatprovide descriptive details of it.every attribute must be given a name that isunique across the entity (distinct entities mayhave attributes with the same name).attribute names are also subject to the samerules that govern entity names (consistentmeaning, documentation, etc..)

EMPLOYEE

EMP ID

Name Address

Types of Attributes

Entities & Relationships

1.Simple and composite

2.Single-valued and multivalued

3.Null

4.Derived

Entities & Relationships

Relationship• ER models in the real-world association between two

or more entities (binary, ternary relationship).• A relationship can be optional or mandatory

“degree” is the number of entity sets involved in• the relationship. typically 2 (binary); other

common degrees are 1 (recursive) and 3 (ternary).

Attributes and Identifiers

Simple and Composite Attributes

Simple Attribute: An attribute composed of asingle component with an independentexistence. E.g position and salary of the Staffentity.

Composite Attribute: An attribute composedof multiple components, each with anindependent existence. E.g adress attribute ofthe branch entity that can be subdivided intostreet, city and postcode attributes

Single-Valued and Multi-Valued Attributes

Single-Valued Attribute: An attribute thatholds a single value for each occurrence of anentity type. E.g branch No.

Multi-Valued Attributes: An attribute thatholds multiple values for each occurrence ofan entity type. E.g telephone No.

Attributes and Identifiers

Derived Attributes

Derived Attributes: An attribute thatrepresents a value that is derivable from thevalue of a related attribute or set ofattributes, not necessarily in the same entitytype.

E.g attribute duration which value isderived from the rent Start and rent Finishattributes.

Attributes and Identifiers

Cardinality, Degree, Existence of Relationship

Cardinality• “Cardinality” indicates the entity occurrences (instances) participating

in a relationship.• takes values as “one” or “many”. e.g. a one: many relationship

indicates that for• Every occurrence of one entity, there are many related instances of the

other entity.

Employee DepartmentWorks

for

Cardinality, Degree, Existence of Relationship

One-to-One (1:1)

Cardinality, Degree, Existence of Relationship

One-to-Many (1:*)

Cardinality, Degree, Existence of Relationship

Many-to-Many (*:*)

Building the ER Model

• the requirements specification is the first step to any design; it captures the ‘what’ of the business environment.• also documents the “business rules” - i.e., the

constraints that will apply to your database. e.g. every department must have a manager; and only one manager.• the ER model must capture the participating

entities as well as these business rules.

Building the ER Model

Entity : Categorization

• Fundamental/strong entityan entity that is capable of its “own existence” - i.e. an entity whose instances exist notwithstanding the existence of other entities.

• Weak Entities• Associative Entities

Building the ER Model

Weak Entity

• an entity that is not capable of “its own existence”.

• characterised by the need to have at least one external identifier (of another entity) as part of its own identifier. e.g. consider “ payment” and “ pmt_items” “ pmt_items” cannot exist without a corresponding “ payment” instance. “pmt_id” of “ payment” will be part of the identifier of “ pmt_items”.

Building the ER Model

Associative Entity

• a relationship translates into migration of a key many:many relationship implies the keys migrating many times, both ways.

• such migration leads to redundancy and many:many relationships must therefore be resolved.

• “Associative entity” is an entity that is used to resolve a many:many relationship.