Chapter 3

30
3 Chapter 3 Entity Relationship (E-R) Modeling Hachim Haddouti

description

Chapter 3. Entity Relationship (E-R) Modeling Hachim Haddouti. In this chapter, you will learn:. What a conceptual model is and what its purpose is The difference between internal and external models How internal and external models serve the database design process - PowerPoint PPT Presentation

Transcript of Chapter 3

Page 1: Chapter 3

3

Chapter 3

Entity Relationship (E-R) Modeling

Hachim Haddouti

Page 2: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 2

3

In this chapter, you will learn:• What a conceptual model is and what its purpose is

• The difference between internal and external models

• How internal and external models serve the database design process

• How relationships between entities are defined and refined, and how such relationships are incorporated into the database design process

• How ERD components affect database design and implementation

• How to interpret the modeling symbols for the four most popular E-R modeling tools

• That real-world database design often requires you to reconcile conflicting goals

Page 3: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 3

3

Why Data Modeling

• Database designers, programmers and end users have different views of the data

• Data modeling abstracts real-world complexities to facilitate communication between designers, programmers and end users

• A data model is a relatively simple, usually graphic representation of real-world data structures, their characteristics, constraints, relations and transformations

• It is necessary for good database design and, hence, good applications

Page 4: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 4

3Data Models: Degrees of Data

Abstraction

Page 5: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 5

3

Degrees of Abstraction

• Conceptual– Global view of data

– Basis for identification and description of main data items

– ERD used to represent conceptual data model

– Hardware and software independent

• Internal– Representation of database as seen by DBMS

– Adapts conceptual model to specific DBMS

– Software dependent

Page 6: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 6

3

Degrees of Abstraction (con’t.)• External

– Users’ views of data environment (functional modules)– Provides subsets of internal view (student registration,

class scheduling)– Makes application program development easier– Facilitates designers’ tasks– Ensures adequacy of conceptual model– Ensures security constraints in design

• Physical– Lowest level of abstraction– Software and hardware dependent– Requires definition of physical storage devices and

access methods

Page 7: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 7

3

The Entity Relationship (E-R) Model

• E-R Model: graphical data representation • Represents conceptual view• Main Components

– Entities (real world objects)• Corresponds to entire table, not row• Represented by rectangle• E.g. PERSON, PLACE, BOOK, CAR, EMPLOYEE

– An entity set is a set of entities of the same type that share the same properties. E.g: set of all persons, companies, trees, holidays

– Attributes– Relationships

• Complementary of Relational Model ( an entity corresponds to a relational table, an entity occurrence to a row)

Page 8: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 8

3

Attributes• Characteristics of entities• Domain is set of possible values, e.g. GPA(0,4)• Primary keys underlined

Page 9: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 9

3

Attributes (con’t.)• Simple

– Cannot be subdivided– Age, sex, marital status

• Composite– Can be subdivided into

additional attributes– Address into street, city,

zip• Single-valued

– Can have only a single value

– Person has one social security number

• Multi-valued– Can have many values– Person may have several

college degrees, phone numbers

– Implementation!!!

• Derived– Can be derived with

algorithm– Age can be derived from

date of birth

Page 10: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 10

3

Relationships

• Association between entities• Connected entities are called participants• Operate in both directions• Connectivity describes relationship classification

– 1:1, 1:M, M:N

• Cardinality– Expresses number of entity occurrences/instances

associated with one occurrence of related entity

Page 11: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 11

3Connectivity and Cardinality in an ERD

(business rules)

Page 12: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 12

3

Relationship Strength• Existence dependence

– Entity’s existence depends on existence of related entities

– EMPLOYEE claims DEPENDENT

• Weak relationship (non-identifying)

– One entity is existence-independent on another– PK of related entity doesn’t contain PK component of

parent entity

• Strong relationship (identifying)

– One entity is existence-dependent on another– PK of related entity contains PK component of parent

entity

Page 13: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 13

3Relationship Participation

• Optional– Entity occurrence does not require a corresponding

occurrence in related entity– Shown by drawing a small circle on side of optional

entity on ERD– E.g. INVOICE is optional to CUSTOMER, or INVOICE and

PRODUCT • Mandatory

– Entity occurrence requires corresponding occurrence in related entity

– If no optionality symbol is shown on ERD, it is mandatory

Page 14: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 14

3Example of Optional Entitites

Page 15: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 15

3

Weak Entity• Existence-dependent on another entity• Has primary key that is partially or totally

derived from parent entity

Page 16: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 16

3

Relationship Degree

• Indicates number of associated entities• Unary

– Single entity

– Recursive

– Exists between occurrences of same entity set

• Binary

– Two entities associated

• Ternary– Three entities associated

Page 17: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 17

3

Three Types of Relationships

Page 18: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 18

3

Composite Entities

• Used to ‘bridge’ between M:N relationships• Bridge entities composed of primary keys of each

entity needing connection

Page 19: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 19

3Bridge Entity

Page 20: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 20

3

Entity Supertypes and Subtypes

• Generalization hierarchy – Depicts relationships between higher-level

supertype and lower-level subtype entities

– Supertype has shared attributes

– Subtypes have unique attributes

– Disjoint relationships• Unique subtypes• Non-overlapping• Indicated with a ‘G’

– Overlapping subtypes use ‘Gs’ Symbol

Page 21: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 21

3

Generalization Hierarchy with Overlapping Subtypes

Page 22: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 22

3

Comparison of E-R Modeling Symbols• Alternate styles developed to enable easier use of

CASE tools• Chen

– Moved conceptual design into practical database design arena

• Crow’s Foot– Cannot detail all cardinalities

• Rein85– Similar to Crow’s Foot – Operates at higher level of abstraction

• IDEF1X– Derivative of ICAM studies in the late 1970’s– Uses fewer symbols

Page 23: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 23

3

Comparison of E-R Modeling Symbols

Page 24: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 24

3

Challenge of Database Design: Conflicting Goals

• Database must be designed to conform to design standards

• High-speed processing may require design compromises

• Quest for timely information may be the focus of database design

• Other concerns– Security– Performance– Shared access– Integrity

Page 25: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 25

3

Entity-Relationship Model

Example of schema in the entity-relationship model

Page 26: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 26

3

A Sample Relational Database

A Sample Relational DatabaseA Sample Relational Database

Page 27: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 27

3

E-R Diagram for Insurance

Page 28: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 28

3

Draw ERD for Ifrane School

The Ifrane School (IS) has contacted you to create a conceptual model whose application will meet the expected database requirements for its training program. Those are their business rules:

• IS has 12 instructors and can handle up to 30 trainees per class. • IS offers five "advanced technology" courses, each of which may

generate several classes. If a class has fewer than 10 trainees in it, it will be canceled. It is, therefore, possible for a course not to generate any classes during a session.

• Each class is taught by one instructor. • Each instructor may teach up to two classes or may be assigned

to do research. • Each trainee may take up to two classes per session.

Page 29: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 29

3Interpretation of IS biz Rules

• Basically, 3 sets of relationships exist: – A COURSE may generate one or more CLASSes, – an INSTRUCTOR teaches up to two CLASSes, – and a TRAINEE may enroll in up to two CLASSes.

• A trainee can take more than one class, and each class contains many (10 or more) trainees, so there is a M:N relationship between TRAINEE and CLASS.

• A class is taught by only one instructor, but an instructor can teach up to two classes. Therefore, there is a 1:M relationship between INSTRUCTOR and CLASS.

• Finally, a COURSE may generate more than one CLASS, while each CLASS is based on one COURSE, so there is a 1:M relationship between COURSE and CLASS.

• Note the optional and mandatory relationships: – a CLASS must have TRAINEEs enrolled in it, but TRAINEEs do not necessarily take

CLASSes. (Some may take "on the job training.") – An INSTRUCTOR may not be teaching any CLASSes, doing research instead, but each

CLASS must have an INSTRUCTOR. If not enough people sign up for a CLASS, a COURSE may not generate any CLASSes, but each CLASS must represent a COURSE.

Page 30: Chapter 3

Hachim Haddouti, CH3, see also Rob & Coronel 30

3

ERD for Ifrane School

INSTRUCTOR

teaches

generates

CLASS

TRAINEE

COURSE

ENROLL

1 1

M

M

M M

1

(0,2)

(1,1)

(1,1)(1,1)(10,30)

(1,1)

(0,2)

(0,N)

1