You are on page 1of 7

In this chapter, you will learn:

ER Diagrams Crow Feet & Chen Notations The main characteristics of entity relationship components Entity Attributes Primary keys Composite primary keys Composite and simple attributes Single-valued attributes Multivalued attributes Relationships 1:M relationship 1:1 relationship M:N relationship

Entity-Relationship Modelling Part 1

The Entity Relationship (ER) Model

ER model forms the basis of an ER diagrams (Crow Feet Notation & Chen Notation) ERD represents conceptual database as viewed by end user ERDs depict databases main components:
Entities Attributes Relationships

Refers to entity set and not to single entity occurrence Corresponds to table and not to row in relational environment In both Chen and Crows Foot models, entity is represented by rectangle containing entitys name Entity name, a noun, is usually written in capital letters

Characteristics of entities In Chen model, attributes are represented by ovals and are connected to entity rectangle with a line Each oval contains the name of attribute it represents In Crows Foot model, attributes are written in attribute box below entity rectangle

Composite and Simple Attributes

Composite attribute (NOT composite key) can be subdivided to yield additional attributes. an ADDRESS attribute can be subdivided into city, state and postcode NAME attribute can be subdivided into first_Name and Last_Name Simple attribute cannot be subdivided. Ex. AGE, MARITAL STATUS

Single-Valued Attributes
Single-value attribute can have only a single value

Multivalued Attributes

Multivalued Attributes (continued)

Not necessarily a simple attribute

Ex. IC_NUM => 780417-08-5284 is a composite attribute because it can be subdivided into birthdate (780417), place of birth (08), serial number (5284)

Multivalued attributes can have many values Ex. A car color may be subdivided into many colors (colors for the roof, body and trim) Chen Model, the multivalued attributes are shown by double line connecting the attribute to the entity.
7 8

Resolving Multivalued Attribute Problems

Although conceptual model can handle M:N relationships and multivalued attributes, you should not implement them in relational DBMS Option 1: Within original entity, create several new attributes, one for each of the original multivalued attributes components
Can lead to major structural problems in table

Resolving Multivalued Attribute Problems (continued)

Option 1: Within original entity, create several new attributes

Option 2: Create new entity composed of original multivalued attributes components


Resolving Multivalued Attribute Problems (continued)

Option 2: Create new entity composed of original multivalued attributes components

Derived Attributes
Attribute whose value may be calculated (derived) from other attributes.
Ex. EMP_AGE can be derived by computing the difference between the current date and the EMP_DOB

Need not be physically stored within database. Can be derived by using an algorithm. Chen Model, the derived attribute is connected to the entity using dashed line.



Derived Attributes (continued)

Advantages and Disadvantages of Storing Derived Attributes

Association between entities Participants are entities that participate in a relationship Relationships between entities always operate in both directions in order to classified whether the relationship is 1:1, 1:M or M;N Relationship classification is difficult to establish if only one side of the relationship is known



Relationships within the Relational Database

1:M relationship Relational modeling ideal Should be the norm in any relational database design 1:1 relationship Should be rare in any relational database design M:N relationships Cannot be implemented as such in the relational model M:N relationships can be changed into two 1:M relationships

The 1:M Relationship (continued)



The 1:M Relationship (continued)

The 1:1 Relationship

One entity can be related to only one other entity, and vice versa Sometimes means that entity components were not defined properly As rare as 1:1 relationships should be, certain conditions absolutely require their use



The 1:1 Relationship (continued)

The M:N Relationship

Can be implemented by breaking it up to produce a set of 1:M relationships Can avoid problems inherent to M:N relationship by creating a composite entity or bridge entity



The M:N Relationship (continued)

The M:N Relationship (continued)

Implementation of a composite entity Yields required M:N to 1:M conversion Composite entity table must contain at least the primary keys of original tables Also known as bridge entities Composed of primary keys of each of the entities to be connected May also contain additional attributes that play no role in connective process Linking table contains multiple occurrences of the foreign key values Additional attributes may be assigned as needed
21 22

The M:N Relationship (continued)

Changing the M:N relationship to two 1:M relationships

The M:N Relationship (continued)

Bridge entity / composite entity

23 24

Connectivity and Cardinality

Connectivity Used to describe the relationship classification; 1:1. 1:M, M:N Cardinality Expresses minimum and maximum number of entity occurrences associated with one occurrence of related entity In the ERD, it is indicated by placing the appropriate numbers beside the entity using the format (x,y) Established by very concise statements known as business rules Ex. A professor can only teach up to 4 classes

Connectivity and Cardinality (continued)


Existence Dependence/ Existence Independence

Existence dependence Exist in database only when it is associated with another related entity occurrence Ex. EMPLOYEE has DEPENDANT. DEPENDANT cant exist apart from EMPLOYEE Existence independence Entity can exist apart from one or more related entities Sometimes refers to such an entity as strong or regular entity Ex. PART is supplied by VENDOR. Some parts are not supplied by vendor because theyre produced in-house

Relationship Strength
Weak (non-identifying) relationships
Exists if PK of related entity does not contain PK component of parent entity

Strong (Identifying) Relationships

Exists when PK of related entity contains PK component of parent entity



Weak Entities
Weak entity meets two conditions Existence-dependent
Cannot exist without entity with which it has a relationship

Weak Entities (continued)

Has primary key that is partially or totally derived from parent entity in relationship Database designer usually determines whether an entity can be described as weak based on business rules



Relationship Participation
Optional participation
One entity occurrence does not require corresponding entity occurrence in particular relationship

Relationship Participation (continued)

Mandatory participation
One entity occurrence requires corresponding entity occurrence in particular relationship



Relationship Participation (continued)

Relationship Degree
Indicates number of entities or participants associated with a relationship Unary relationship
Association is maintained within single entity

Binary relationship
Two entities are associated

Ternary relationship
Three entities are associated



The implementation of ternary Relationship

Relationship Degree (continued)



Recursive Relationships
Relationship type where same entity type participates more than once in different

Recursive Relationships


Relationship can exist between occurrences of the same entity set Naturally found within unary relationship



Recursive Relationships (continued)

Recursive Relationships (continued)



Now you should be able to explain: ER Diagrams Crow Feet & Chen Notations The main characteristics of entity relationship components Entity Attributes Relationships - 1:M relationship , 1:1 relationship and M:N

Database systems: design, implementation, and management, by Peter Rob, Carlos Coronel

Strong and weak identfying relationship Relationship participation Relationship degree Recursive relationship
41 42