The Entity Relationship (E-R) Model

! 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

! 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.
3

! 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
4

! Attributes: are represented by ovals containing the attribute names and connected to the entity by a line.
course# name credit

COURSE

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

! 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.

! 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

! 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: div1Phone# div2Phone# div3Phone#
PLANT

! Another way to deal with a multivalued attribute is to create a new entity for it
Plant# Section# Phone#

PHONE

! 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.

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.
PROFESSOR 1 teaches M COURSE

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

10

! 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.
PROFESSOR 1
(0,3)

teaches

M
(1,1)

COURSE

11

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

12

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.
PROFESSOR 1
(0,3)

M teaches
(1,1)

COURSE

13

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

1
(0,N)

M
Has (1,1) DEPENDENT

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

14

Recursive entities A recursive relation is one which is related to itself.

1 supervises M
M

EMPLOYEE

COURSE

requires M

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

Recall that: A M:M relationship involving two entities is implemented using three tables, one for the relationship and one for each entity. Example:
STUDENT M ENROLL M

COURSE

STRUDENT(S#, name, address) COURSE(course#, name, credit, ...) ENROLL(course#, S#, grade, ...) Note that ENROLL is a bridge entity
16

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 G DOCTOR G TECHNICIEN G NURSE
17

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
SCHOOL

1
(1,1)

runs

1
(1,1)

DEAN

18

2. Each school is composed of several departments

SCHOOL

1
(1,M)

belongs to

M
(1,1)

DEPT

3. Each department offers several courses

DEPT

1
(1,N)

offers

M
(1,1)

COURSE

4. A course may have several sections

COURSE

1
(1,N)

has

M
(1,1)

SECTION

19

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.! 1 ! employs DEPT (0,N) 1 (1,1) !
M (1,1) 1 (0,1) chairs

PROFESSOR

6. Each professor may teach up to 4 sections.

PROFESSOR

(0,4)

teaches

(1,1)

SECTION

20

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

1
(1,35)

ENROLL

M
(1,6)

STUDENT

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

21

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

1
(1,N)

has

M
(1,1)

STUDENT

9. Each student is advised by one professor, but a professor can advise many students.
PROFESSOR

(0,N)

advises

(1,1)

STUDENT

22

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
23

DEAN

runs

SCHOOL

(1,M)

belongs to

M
employs 1 1 1 DEPT has

M
M

STUDENT M

M
chairs M 1 offers

M COURSE 1 1 has M M SECTION M ENROLL

PROFESSOR 1

teaches

advises

24

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
25

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)

26

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