27
1 The Entity Relationship (E-R) Model

Chapter 4 Database Systems PPT's

Embed Size (px)

DESCRIPTION

PPT's for Database Systems chapter 4

Citation preview

Page 1: Chapter 4 Database Systems PPT's

1

The Entity Relationship (E-R) Model

Page 2: Chapter 4 Database Systems PPT's

2

•  The E-R model is a data model that describes relationships (1:1, 1:M, M:M) among entities at the conceptual level with the help of E-R diagrams

•  E-R diagram is a diagram that shows the E-R model's entities, attributes, relationships, connectivities and cardinalities

Page 3: Chapter 4 Database Systems PPT's

3

•  There are mainly three different data models: •  The conceptual model: shows the entity sets

and the relationships among them. •  The internal model: is used to implement the

conceptual model such as hierarchical, network or relational model.

•  The physical model: here we define the way in which data is physically stored. It requires the definition of both the physical storage devices and the physical access methods to use the data.

Page 4: Chapter 4 Database Systems PPT's

4

•  The different components of the E-R model are •  the entities, •  the attributes and •  the relationships.

•  Entities

• An entity refers to the entity set which corresponds to the table in the relational database. An entity is represented by a rectangle containing the entity's name

Page 5: Chapter 4 Database Systems PPT's

5

•  Attributes: are represented by ovals containing the attribute names and connected to the entity by a line.

•  The key attributes (attributes that form the

primary key) are underlined.

•  Instead of an E-R diagram, a table structure can be used: COURSE(Course#, name, credit).

COURSE

name creditcourse#

Page 6: Chapter 4 Database Systems PPT's

6

•  An attribute can be simple or composite. •  A composite attribute is an attribute that can

be further subdivided into additional. attributes such as phone number and address.

•  A simple attribute can not be subdivided.

Page 7: Chapter 4 Database Systems PPT's

7

•  An attribute can be single-valued or multivalued •  A single-valued attribute is an attribute that

can have only one single value in a row. •  A multivalued attribute is an attribute that can

have many values in a row. For example, a plant may have many phone numbers, one for each division. A multivalued attribute is connected to the entity by a double line.

Plant Phone

Page 8: Chapter 4 Database Systems PPT's

8

•  Since the relational DBMS does not support multivalued attributes, these attributes should be decomposed into simple attributes. One way to do this is to create several new attributes, one for each of the multivalued attribute components

•  Example:

•  Another way to deal with a multivalued attribute is to create a new entity for it

PLANT

div1Phone# div2Phone# div3Phone#

PHONE

Plant# Section# Phone#

Page 9: Chapter 4 Database Systems PPT's

9

•  An attribute can also be classified as derived. A derived attribute is an attribute whose definition, not the attribute itself, is physically stored. For example, AGE can be derived as (current date - date of birth). A derived attribute is connected to the entity by a dotted line.

Page 10: Chapter 4 Database Systems PPT's

10

Relationships •  A relationship is a linking (association) between

relations (called also participants). Each relationship is named and represented by a diamond-shaped symbol. The degree of a relationship is the number of associated relations.

•  Connectivity of a relationship is either 1:1, 1:M or M:M .

COURSE PROFESSOR teaches1 M

Page 11: Chapter 4 Database Systems PPT's

11

•  The Cardinality in a relationship is the number of entity occurrences (or instances) related to a single occurrence of the related entity.

•  The cardinality is usually a function of organizational policy.

•  The cardinality in an E-R diagram is indicated by placing the numbers besides the entities.

COURSE PROFESSOR teaches1 M

(0,3) (1,1)

Page 12: Chapter 4 Database Systems PPT's

12

Existence dependency •  An entity is said to be existence-dependent if the

entity existence depends on the existence of one or more other entities.

•  Example: an instance policy may cover an employee and its dependents EMPLOYEE(emp#, name, address, ...) DEPENDENT(dependent#, emp#, name, ...)

Page 13: Chapter 4 Database Systems PPT's

13

Relationship participation •  An entity participating in a relationship is either

optional or mondatory. It is optional if one entity occurrence does not require a corresponding entity occurrence in the relationship. It is mondatory if each entity occurrence require a corresponding entity occurrence in the relationship.

•  For example: In a given quarter, a professor may be doing research but not teaching. Therefore, COURSE is optional. But PROFESSOR is mondatory since an offered course requires a professor.

COURSE PROFESSOR teaches1 M

(0,3) (1,1)

Page 14: Chapter 4 Database Systems PPT's

14

Weak entities •  A weak entity is one that

. is existence-dependent; that is it can not exist without the other associated entity and

. has key attributes obtained from the "parent" entity in the relationship

•  A weak entity in an E-R diagram is represented with a double rectangle.

• EMPLOYEE(emp#, name, address) • DEPENDENT(dep#, emp#,name)

1 M

(0,N) (1,1)EMPLOYEE Has DEPENDENT

Page 15: Chapter 4 Database Systems PPT's

15

Recursive entities A recursive relation is one which is related to itself. A 1:M recursive entity relationship is implemented by using

one single table EMPLOYEE(emp#, name, dept, mgr, ...) A M:M recursive entity relationship is implemented by

using two tables COURSE(course#, name, credit, ...) PREREQ(course#, pre)

EMPLOYEE supervises

1

M

COURSE requires

M

M

Page 16: Chapter 4 Database Systems PPT's

16

Recall that: A M:M relationship involving two entities is

implemented using three tables, one for the relationship and one for each entity.

Example:

STRUDENT(S#, name, address) COURSE(course#, name, credit, ...) ENROLL(course#, S#, grade, ...)

Note that ENROLL is a bridge entity

COURSE STUDENT ENROLLM M

Page 17: Chapter 4 Database Systems PPT's

17

Entity supertypes and subtypes A subtype entity is an entity that contains the

unique characteristics (attributes) of an entity whose general characteristics are found in another more broadly defined entity known as a supertype.the subtype entity inherits the supertype entity (parent)

EMPLOYEE

DOCTOR TECHNICIEN NURSE

GG

G

Page 18: Chapter 4 Database Systems PPT's

18

Developing an E-R diagram The development of an E-R diagram is an iterative

process that involves designers and end users. It is based on interviews, reports, business forms, ...

Example:We want to develop an E-R diagram for a

"typical" university. 1. The university is divided into different schools,

each one has a dean

1 1SCHOOL DEAN(1,1) (1,1)

runs

Page 19: Chapter 4 Database Systems PPT's

19

2. Each school is composed of several departments 3. Each department offers several courses 4. A course may have several sections

1 MSCHOOL DEPT

(1,M) (1,1)belongs to

1 MDEPT COURSE

(1,N) (1,1)offers

1 MCOURSE SECTION

(1,N) (1,1)has

Page 20: Chapter 4 Database Systems PPT's

20

5. Each department employs several professors, but each professor belongs to a single department. Each department is chaired by a chair, who is also a professor.!

!! 6. Each professor may teach up to 4

sections.

DEPT

PROFESSOR

employs

chairs

M

1

1 (1,1)

(0,1)

(1,1)

(0,N)

1

1 MPROFESSOR SECTION

(0,4) (1,1)teaches

Page 21: Chapter 4 Database Systems PPT's

21

7.  Each student can take up to 6 courses. Each section has a capacity of 35 students.

The relationship ENROLL between SECTION and STUDENT is M:M, therefore, we need a bridge entity.

1 MSECTION STUDENT

(1,35) (1,6)ENROLL

Page 22: Chapter 4 Database Systems PPT's

22

8. Each department has several student majoring in that department. But each student has one major.

9. Each student is advised by one professor,

but a professor can advise many students.

1 MDEPT STUDENT

(1,N) (1,1)has

1 MPROFESSOR STUDENT

(0,N) (1,1)advises

Page 23: Chapter 4 Database Systems PPT's

23

The database for the university includes 7 entities: SCHOOL, DEAN, DEPARTMENT, PROFESSOR, COURSE, SECTION, and STUDENT

It includes also 10 relationships: Relationship Relation1 Relation2 belongs to school department runs dean school employs department professor offers department course has department student contains course section teaches professor section advises professor student chairs professor department enrolls student section

Page 24: Chapter 4 Database Systems PPT's

24

1DEAN runs SCHOOL

1

M

DEPT

(1,M)

belongs to

1

M

COURSE

offers

M

SECTION

has

M

1

MSTUDENThas

1

PROFESSOR

employs

chairs

M 1

1

1

teaches

1

M

ENROLL

M

M

advises

M

1

Page 25: Chapter 4 Database Systems PPT's

25

E-R diagram for the University database The conceptual schema (E-R model represented in the

form of table structure) for the university is SCHOOL(scode, sname,saddress,deanID,sphone)

primary key (scode) foreign key (deanID) references DEAN (deanID)

DEAN(deanID,deanName, deanPhone) primary key (deanID)

DEPT(dept#,scode, chair, deptPhone,deptAddress) primary key (dept#) foreign key (scode) references SCHOOL (scode) foreign key (chair) references PROF (facID)

chair is the facID of the chairperson of the department

Page 26: Chapter 4 Database Systems PPT's

26

E-R diagram for the University database (cont.) PROF(facID,SSN,name, address, phone, salary,dept#)

primary key (facID) foreign key (dept#) references DEPT (dept#)

COURSE(course#, courseName,credit,dept#) primary key (course#) foreign key (dept#) references DEPT (dept#)

SECTION(call#,course#,facID, days,time,location) primary key (call#) foreign key (course#) references COURSE (course#) foreign key (facID) references PROF (facID)

Page 27: Chapter 4 Database Systems PPT's

27

E-R diagram for the University database (cont.) STUDENT(S#,SSN,name,address,major,dept#,advisor)

primary key (S#) foreign key (dept#) references DEPT (dept#) foreign key (advisor) references facID

note:advisor is facID of the professor advising the students

ENROLL(S#,call#,grade) primary key (S#,call#) foreign key (S#) references STUDENT (S#) foreign key (call#) references SECTION (call#)