Chapter 4 Database Systems PPT's

Post on 08-Apr-2016

47 views 1 download

description

PPT's for Database Systems chapter 4

Transcript of Chapter 4 Database Systems PPT's

1

The Entity Relationship (E-R) Model

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

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.

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

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#

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.

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

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#

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.

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

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)

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, ...)

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)

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

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

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

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

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

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

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

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

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

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

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

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

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)

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#)