ER DIAGRAMS

SUMMARY OF ER-DIAGRAM NOTATION FOR ER SCHEMAS

Symbol

Meaning ENTITY/STRONG ENTITY WEAK ENTITY TYPE RELATIONSHIP TYPE IDENTIFYING RELATIONSHIP TYPE ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE

E1

R N

E2

TOTAL PARTICIPATION OF E2 IN R
2

In ER Diagram we will identify the following:

1) Identification of entities and their respective attributes 2) Identification of Relationship

Relationships
One-to-One Relationship
Department 1 has 1 Manager

One-to Many Relationship

1 Professor M

teaches

Class

Many-to-Many Relationship
M Student Entrolls in N Class
4

ENTITY RELATIONSHIP(ER) DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM

1) Identification of entities and their respective attributes:

Book Book_id, Title, Category, Price Student Student_id, name, semester, contact_no, address, fine Author author_id, name, contact_no, address Publisher pub_id, name, contact_no, address
5

2) Identification of Relationship
Book : Author (M:N)
Book : Student (M:N) Publisher : Book (1:N)

Contact_n o

Library ER Diagram
Book_id Author_id title category price

Name

N
Author
Writes

Book

N
Address City State Zip Published_by Issue

M
Issue_dat e

Name

Pub_id

N 1
Student

Student_id Name

Publisher

Semester

Address

Contact_n o
City Zip

fine Address State Zip

Contact_n o

City

State

 Company Database Example

EXERCISES
A company database needs to store information about employees (identified by ssn, with salary and phone as attributes), departments (identified by dno, with dname and budget as attributes), and children of employees (with name and age as attributes).

Employees work in departments; each department is managed by an employee; a child must be identified uniquely by name when the parent (who is an employee; assume that only one parent works for the company) is known. We are not interested in information about a child once the parent leaves the company.

ER Diagram
Ssn

Salary

Phone

Dno

Dname
Budget

M
Employees

Manage s

N 1

Departments

Dependen t

M
Works_in

Child

Name

Age

ENTITY RELATIONSHIP(ER) DIAGRAM FOR UNIVERSITY

1) Identification of entities and their respective attributes:

College College_id, College_name, Contact_no, Address Department dept_id, dept_name, contact_no, hod_id Courses course_id, course_title, year Faculty fac_id, fac_name, designation, address Student Student_id, student_name, year, admission_date
11

2) Identification of Relationship
College : Department (1:N)
Department: Faculty (1:N) Faculty : Courses (M:N) Department:Student (1:N)
12

Assumptions
1). A college can have more than one contact number.

2). A Lecturer can teach more than one courses and also a course can be taught by more than one lecturer.

13

University ER Diagram
Course_title

Contact_no
Name Dept_id

Contact_no Course_id Hod_id

year

College_id 1 Name College 1 has N 1 Address 1 N type Department offers N Courses

City

State

Zip
Admission_date entroll Name Stu_id N M N Student Fac_id Address Name Contact_no City State Zip City State Zip Address Faculty Qualification Designation has teaches

14

ER Diagram

15

EXERCISES
The company is organized into departments. Each department has a unique name, a unique number, and a particular employee who manages the department. We keep track of the start date when that employee began managing the department. A department may have several locations. A department controls a number of projects, each of which has a unique name, a unique number, and a single location.

We store each employees name, social security number, address, salary, and birth date. An employee is assigned to one department, but may work on several projects, which are not necessarily controlled by the same department. We keep track of the number of hours per week that an employee works on each project. We also keep track of the direct supervisor of each employee. We want to keep track of the dependents of each employee for insurance purposes. We keep each dependents first name, birth date, and relationship to the employee.

16

ER DIAGRAM Entity Types are:

EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

17

1. An entity type DEPARTMENT with attributes Name, Number, Locations, Manager, and Manager_start_date. Location is the only multivalued attribute. We can specify that both name and Number are (separate) key attributes because each was specified to be unique.
2. An entity type PROJECT with attributes Name, Number, Location, and Controlling_department. Both Name nad Number are (separate) Key attributes.
18

3.

An entity type PMPLOYEE with attributes Name, Ssn, Sex, Address, Salary, Birth_date, Department, and Supervisor. Both Name and Address may be composite attributes; however, this was not specified in the requirements, we must go back to the users to see if any of them will refer to the individual components of Name-First_name, Middle_initial, Last_name-or of Address.

4. An entity type DEPENDENT with attributes Employee, Dependent_name, Sex, Birth_dat, and Relationship (to the employee).
19

 MANAGES, a 1:1 relationship type between EMPLOYEE and DEPARTMENT. EMPLOYEE participation is partial. DEPARTMENT participation is not clear from the requirements. We question the users, who say that a department must have a manager at all times, which implies total participation. The attribute Start_date is assigned to this relationship type. WORKS_FOR, a 1:N relationship type between DEPARTMENT and EMPLOYEE. Both participations are total.
20

 CONTROLS, a 1:N relationship type between DEPARTEMENT and PROJECT. The participation of project is total, whereas that of DEPARTMENT is determined to be partial, after consultation with the users indicates that some departments may control no projects.

SUPERVISION, a 1:N relationship type between EMPLOYEE (in the supervisor role) and EMPLOYEE (in the supervisee role). Both participations are determined to be partial, after the users indicate that not every employee is a supervisor and not every employee has a supervisor.
21

 WORKS_ON, determined to be an m:N relationship type with attribute Hours, after the users indicate that a project can have several employees working on it. Both participations are determined to be total.

DEPENDENTS_of, a 1:N relationship type between EMPLOYEE and DEPENDENT, which is also the identifying relationship for the weak entity type DEPENDENT. The participation of EMPLOYEE is partial, whereas that of DEPENDENT is total.
22

Designing an ER Diagram
Consider the following set of requirements for a University database. Design an ER diagram for this application: The university keeps track of each student's name, student number, social security number, current address and phone number, permanent address and phone number, birthdate, sex, class (freshman, graduate), major department, minor department (if any), degree program (B.A., B.S., ... Ph.D.). Some user applications need to refer to the city, state, and zip code of the student's permanent address and to the student's last name. Both social security number and student number are unique for each student. All students will have at least a major department. Each department is described by a name, department code, office number, office phone, and college. Both the name and code have unique values for each department. Each course has a course name, description, course number, number of credits, level and offering department. The course number is unique for each course. Each section has an instructor, semester, year, course, and section number. The section number distinguishes sections of the same course that are taught during the same semester/year; its value is an integer (1, 2, 3, ... up to the number of sections taught during each semester). A grade report must be generated for each student that lists the section, letter grade, and numeric grade (0,1,2,3, or 4) for each student and 23 calculates his or her average GPA.

University ER Diagram
Degree Name Birth date Sex StudentID SSN Major In DName DCode OfficeNumber OfficePhone College

Student
Minor In

Department

Class
Address City State Zip

Offer

CName Grade_Report Letter Grade GPA Credits Numeric Grade Instructor Year CourseDesc

Course
CNumber

Section

Belong_To

SectionNumber

Semester

24

ER DIAGRAM FOR A BANK DATABASE

The Benjamin/Cummings Publishing Company, Inc. 1994, Elmasri/Navathe, Fundamentals of Database Systems, Second Edition

25

FIGURE 3.17 An ER diagram for an AIRLINE database schema.

26

Overview
concepts
Entities Relationships Attributes Specialization/Generalization Aggregation

turning E-R diagrams to tables

27

Specialization
eg., students: part time (#credithours) and full time (major)
name

ssn

STUDENT IS-A

major

FT-STUDENT

PT-STUDENT #credits

28

Observations
Generalization: exact reverse of specialization attribute inheritance could have many levels of an IS-A hierarchy

29

Aggregation
treat a relationship as an entity rarely used
N CPU M HD MAKER

30

Overview
concepts
Entities Relationships Attributes Specialization/Generalization Aggregation

turning E-R diagrams to tables

31

STUDENT N

grade

takes M

c-id

s-id

SECTION N

has

1 COURSE

teaches 1 INSTRUCTOR
32

Strong entities
just list the attributes, and underline the primary key, eg. STUDENT(ssn, name, address)

33

Multivalued attributes
Eg., EMPLOYEE with many dependents: a new table, with (ssn, dependent-name)

34

Relationships
get primary keys all involved entities primary key - depends on cardinality
1 to 1: either eg EMPLOYEE( ssn, empno, name, ...) 1 to N: the key of the N part eg.
TEACHES( issn, c-id, s-id)

N to M: both keys - eg
TAKES( ssn, c-id, s-id, grade)

35

Relationships
1 to N: no need for separate table - eg.,
SECTION( issn, room-num, c-id, s-id) instead of SECTION1(c-id, s-id, room-num) TEACHES(issn, c-id, s-id)

for rel. between strong and corresponding weak entity, no need for table, at all!
36

Generalization/Spec.
Two solutions: - one table for each or - no table for super-entity (pros and cons?)

37

Generalization/Special.
Eg.,
STUDENT(ssn, name, address) PT-STUDENT( FT-STUDENT(

38

Generalization/Special.
Eg.,
STUDENT(ssn, name, address) PT-STUDENT( ssn, num-credits) FT-STUDENT( ssn, major)

39

Generalization/Special.
no super-entity:
[STUDENT(ssn, name, address)] PT-STUDENT( ssn, num-credits FT-STUDENT( ssn, major

40

Generalization/Special.
no super-entity:
[STUDENT(ssn, name, address)] PT-STUDENT( ssn, num-credits, name, address) FT-STUDENT( ssn, major, name, address)

41

Aggregation
make table, with primary keys of all involved entities

42

Overview
concepts
Entities Relationships Attributes Specialization/Generalization Aggregation

turning E-R diagrams to tables

43

Summary
E-R Diagrams: a powerful, user-friendly tool for data modeling:
Entities (strong, weak) Attributes (primary keys, discriminators, derived, multivalued) Relationships (1:1, 1:N, N:M; multi-way) Generalization/Specialization; Aggregation
44

Summary - contd
(strong) entity set
weak entity set

attribute
multivalued attribute

relationship set

derived attribute

identifying rel. set for weak entity

45

Conclusions
E-R Diagrams: a powerful, user-friendly tool for data modeling.

46