Course Summary….

§ Relational Data Model

CS 2451 § Formal query languages
Database Systems: • Relational algebra and Relational Calculus
§ SQL
Entity-Relationship (ER) • DDL to define schema and constraints
• Query component…basic SQL + non-RA operators (GroupBy etc.)
Model § Experience working with commercial DBMS and developing
DB applications
http://www.seas.gwu.edu/~bhagiweb/cs2541 • MySQL, PHP
Spring 2020 § Next - Database schema design: how to design a “good”
Instructor: Dr. Bhagi Narahari schema, how to measure “good”?
• Normal Forms (3NF, BCNF)
§ Detour (this class): Conceptual Level Database design
• Entity-Relationship (ER) Model
Based on slides © Ramakrishnan&Gerhke, ElMasri & Navathe, Dr R. Lawrence, UBC

1 2

Database Design The Importance of Database Design

§ The ability to design databases and associated applications
is critical to the success of the modern enterprise. § Just as proper design is critical for developing large
applications, success of database projects is determined by the
effectiveness of database design.
§ Database design requires understanding both the
§ Some statistics on software projects:
operational and business requirements of an organization
• 80 - 90% do not meet their performance goals
as well as the ability to model and realize those
• 80% delivered late and over budget
requirements in a database.
• 40% fail or abandoned
• 10 - 20% meet all their criteria for success
§ Developing database and information systems is performed • Have you been on a project that failed? Yes ? No ?
using a development lifecycle, which consists of a series
of steps. § The primary reasons for failure are improper requirements
specifications, development methodologies, and design
techniques.

3 4

1
 How Does One Build a Database? Building Database Applications: Steps
§ Requirements Analysis: what data, apps, critical 1. Start with a conceptual model
operations • “On paper” using certain techniques
E-R Model
§ Get from “client”
• ignore low-level details – focus on logical representation
• Typically expressed in some natural language
• “step-wise refinement” of design with client input
§ May require going back to the client for resolving 2. Design & implement schema
questions • Design and codify (in SQL) the relations/tables
• Refine the schema – normalization
§ Query and app development depends on client • Do physical layout – indexes, etc.
3. Import the data
specifications
4. Write applications using DBMS and other tools
• Many of the hard problems are taken care of by other people
(DBMS, API writers, library authors, web server, etc.)
• DBMS takes care of Query Optimization, Efficiency, etc.
5. Test!!

5 6

Conceptual Model- Why ? Conceptual Database Design

§ Conceptual database design involves modeling the
§ Convey database design and properties in simple but collected information at a high-level of abstraction without
precise manner using a particular data model or DBMS.
• Interpreted by any type of user
Does not need to know anything about CS § Since conceptual database design occurs independently
• Capture the business rules of the application
from a particular DBMS or data model, we need high-level
modeling languages to perform conceptual design.
§ Picture is worth a thousand words
§ The entity-relationship (ER) model was originally proposed
by Peter Chen in 1976 for conceptual design.
• Can also do ER modeling using Unified Modeling Language (UML)
syntax.

7 8

2
 An Example: “mini” banner Example: ER Design for mini-banner:
§ Database containing information about
• Students
• Faculty
fid PROFESSOR name
• Courses
§ Students take courses “Who’s taking what, and what grade do they
§ Faculty teach courses expect?”
Teaches
§ How to ‘define’ student/faculty/course ?
• What data is needed ?
STUDENT Takes COURSE

sid name exp-grade cid subj semester

One picture provides info on what your system stores and models

9 10

Entity-Relationship Modeling Entity Relationship Model

§ Entity-relationship modeling is a top-down approach to § Based on collection of real world objects or concept called
database design that models the data as entities, attributes, entities; ex: employee, student
and relationships. • attribute represents properties of entity; s.s.num
§ The ER model refines entities and relationships by including § relationship represents interaction between entities
properties of entities and relationships called attributes, and § overall logical structure represented by ER diagram
by defining constraints on entities, relationships, and representing entity sets, relationships, attributes
attributes. § Conceptual design:
• What are the entities and relationships in the enterprise?
§ The ER model conveys knowledge at a high-level • What information about these entities and relationships should we
(conceptual level) which is suitable for interaction with store in the database?
technical and non-technical users. • What are the integrity constraints or business rules that hold?

§ Since the ER model is data model independent, it can later § Can map an ER diagram into a relational schema.
be converted into the desired logical model (e.g. relational
model).

11 12

3
 ER Model Definitions ER Model Basics (Contd.)
§ Entity: Real-world object distinguishable from other
objects. § Relationship: Association among two or more entities.
• An entity is described (in DB) using a set of attributes. E.g., Dan takes Database Course; Attishoo works in
§ Entity Set: A collection of similar entities. E.g., all Pharmacy department.
employees.
• Relationship can also have attributes (that appear only for this
• All entities in an entity set have the same set of attributes. (Until
we consider ISA hierarchies, anyway!) relationship set)
• Each entity set has a key. § Representation/Syntax: a Diamond symbol
• Each attribute has a domain.
• Attributes represented by Oval (same as before)
§ An entity instance is a particular example or occurrence
of an entity type…eg: Employee John Doe § Relationship Set: Collection of similar relationships.
§ Representation/Syntax: • An n-ary relationship set R relates n entity sets E1 ... En; each
relationship in R involves entities e1 ∈ E1, ..., en ∈ En
• Entity set represented by rectangle
• Attribute represented by Oval Same entity set could participate in different relationship sets,
Key attribute underlined or in different “roles” in same set.
Composite Attribute: when it has multiple fields (ex: address)

13 14

Conceptual Design Process Student Entity

§ What are the entities being represented? STUDENTS

§ What are the relationships? Takes

name
§ What info (attributes) do we store about each?
sid name
exp-grade sid
§ What keys & integrity constraints do we have?
Student

15 16

4
 Example of a composite attribute Connectivity in the E-R Diagram?

§ Attributes can only be connected to entities or

relationships
§ Entities can only be connected via relationships
§ As for the edges, let’s consider kinds of relationships
and integrity constraints…

PROFESSORS Teaches COURSES

(warning: different ER implementations have

slightly different notation here!)

17 18

Entity-Relationship Diagram Roles: Labeled Edges

for the Example
Underlined attributes are keys Sometimes a relationship connects the same entity, and
the entity has more than one role:
fid PROFESSORS name
TA course
entity set relationship set
Teaches semester Student TA

id
STUDENTS Takes COURSES Student
name
(Nadala, Roxana)
sid name serno subj cid
exp-grade
This often indicates the need for recursive queries
attributes (recall these have domains)

19 20

5
 Roles vs. Separate Entities Weak Entity Sets
§ A weak entity can be identified uniquely only by
considering the primary key of another (owner) entity.
id TA IsTAfor Student id • Owner entity set and weak entity set must participate in a one-
to-many relationship set (one owner, many weak entities).
• Weak entity set must have total participation in this identifying
name name relationship set.
• If Student is deleted, then we MUST delete the Parent

What is the difference TA • Syntax: Bold face rectangles, Double lined rectangles,…
between these two Student TA
representations?
id
Person
name

21 22

NOTATION for ER diagrams UML class diagrams

§ Represent classes (similar to entity types) as large rounded
boxes with three sections:
• Top section includes entity type (class) name
• Second section includes attributes
• Third section includes class operations (operations are not in
basic ER model)
§ Relationships (called associations) represented as lines
connecting the classes
• Other UML terminology also differs from ER terminology
§ Used in database design and object-oriented software
design
§ UML has many other types of diagrams for software design

23 24

6
 UML Diagrams – Alternate Syntax for ER
Defining Constraints in ER Model
Diagrams
§ Unified Modeling Language (UML) § Contraints capture properties of the relationship and entities
§ Read on your own • Convey the business rules of the application

§ You’ve seen an example on the lab slides! § Every entity set has a key attribute..similar to Rel. Model
• No two elements can have the same value on this attribute
Example: Student ID
§ How many elements in entity set are associated with
another entity in the relationship ?
• Can a student take more than one course ?
§ Does every element in the entity set appear/participate in
the relationship ?
• Must every student take a course ?
§ Define constraints based on properties of the
mapping/relation between entity sets

25 26

Properties of relations Example: the Teaches relationship

§ Binary relationships can be classified as one-to-one, § Want to model the info that each course is taught by one
many-to-one, one-to-many, many-to-many faculty.
§ What is the type of mapping/relation • Type of mapping ???
• 1-to-1
Note: This is a Mapping and not a function!
§ A student can take more than one course
• 1 to Many
§ Every course must have an instructor
• Each element in the Course entity set must participate/appear in the
Teaches relationship
§ A faculty may teach zero or more courses
1-to-1 1-to Many Many-to-1 Many-to-Many

27 28

7
 Example: the Takes Course Relationship
Mapping Cardinality, Participation
Constraints, Structural constraints
§ Student can be enrolled in many courses and each Course
can have many students § Type of mapping (cardinality)
• Type of mapping: • 1-1, 1-many, many-many, many-1
Many to Many • Provides some information on relationship sets
§ Want to model the condition that every student must take at § Participation constraints
least one course • Total vs Partial
• Each student must appear in Takes relationship Total: Every student sid must appear in Takes relationship
Partial: All faculty need not appear in Teaches relationship
§ How many courses can a student take ?
• Do we want to specify a limit ?
§ Structural constraints:
• Minimum and maximum times they can appear in relationship
§ How many students must be enrolled in a course ? • Syntax ??
• Is there a minimum size for a class ?

29 30

The (min,max) notation for relationship

COMPANY ER Schema Diagram using
constraints (min, max) notation

Read the min,max numbers next to the entity

type and looking away from the entity type

31 32

8
 Conceptual Design Using the ER Summary of Conceptual Design
Model
§ Design choices: § Conceptual design follows requirements analysis,
• Should a concept be modeled as an entity or an attribute? • Yields a high-level description of data to be stored
• Should a concept be modeled as an entity or a relationship? • Visual language – the diagram is the syntax!
• Identifying relationships: constraints, type, participation § ER model popular for conceptual design
§ Constraints in the ER Model: • Constructs are expressive, close to the way people think about their
• A lot of data semantics can (and should) be captured. applications.
• But some constraints cannot be captured in ER diagrams. • There are additional constructs in a “real” ER model based tools.
§ Can automate mapping of ER model to relational tables!

33 34

Initial Conceptual Design of Entity Types

A detailed example: The Company Database
for the COMPANY Database Schema
§ COMPANY database keeps track of Employees and § Based on the requirements, we can identify four initial entity
Departments types in the COMPANY database:
• Employees identified by SSN, Name, Location • DEPARTMENT
• Department specified byDepartment ID (did), Name, Budget
• PROJECT
§ Each department has a unique manager • EMPLOYEE
• Database must keep track of starting date
• DEPENDENT
§ Each employee works in a department
§ Their initial conceptual design is shown on the following
• Database must keep track of starting date
slide
§ The initial attributes shown are derived from the
requirements description

35 36

9
 Initial Design of Entity Types: Refining the initial design by introducing
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT relationships
§ The initial design is typically not complete
§ Some aspects in the requirements will be represented as
relationships
§ ER model has three main concepts:
• Entities (and their entity types and entity sets)
• Attributes (simple, composite, multivalued)
• Relationships (and their relationship types and relationship sets)
§ We introduce relationship concepts next

37 38

Relationships and Relationship Types (1) Relationship type vs. relationship set
§ A relationship relates two or more distinct entities with a § Relationship Type:
specific meaning. • Is the schema description of a relationship
• For example, EMPLOYEE John Smith works on the ProductX
PROJECT, or EMPLOYEE Franklin Wong manages the Research • Identifies the relationship name and the participating entity types
DEPARTMENT. • Also identifies certain relationship constraints
§ Relationships of the same type are grouped or typed into a § Relationship Set:
relationship type.
• For example, the WORKS_ON relationship type in which • The current set of relationship instances represented in the database
EMPLOYEEs and PROJECTs participate, or the MANAGES • The current state of a relationship type
relationship type in which EMPLOYEEs and DEPARTMENTs
participate.
§ The degree of a relationship type is the number of
participating entity types.
• Both MANAGES and WORKS_ON are binary relationships.

39 40

10
 Relationship instances of the WORKS_FOR N:1
Relationship instances of the M:N WORKS_ON
relationship between EMPLOYEE and
relationship between EMPLOYEE and PROJECT
DEPARTMENT

41 42

Refining the COMPANY database schema

Relationship type vs. relationship set (2)
by introducing relationships
§ Previous figures displayed the relationship sets § By examining the requirements, six relationship types are
§ Each instance in the set relates individual participating identified
entities – one from each participating entity type § All are binary relationships( degree 2)
§ In ER diagrams, we represent the relationship type as § Listed below with their participating entity types:
follows: • WORKS_FOR (between EMPLOYEE, DEPARTMENT)
• Diamond-shaped box is used to display a relationship type • MANAGES (also between EMPLOYEE, DEPARTMENT)
• Connected to the participating entity types via straight • CONTROLS (between DEPARTMENT, PROJECT)
lines • WORKS_ON (between EMPLOYEE, PROJECT)
• Note that the relationship type is not shown with an arrow. • SUPERVISION (between EMPLOYEE (as subordinate),
The name should be typically be readable from left to right EMPLOYEE (as supervisor))
and top to bottom. • DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)

43 44

11
 ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
Discussion on Relationship Types
§ In the refined design, some attributes from the initial entity
types are refined into relationships:
• Manager of DEPARTMENT -> MANAGES
• Works_on of EMPLOYEE -> WORKS_ON
• Department of EMPLOYEE -> WORKS_FOR
• etc
§ In general, more than one relationship type can exist
between the same participating entity types
• MANAGES and WORKS_FOR are distinct relationship types
between EMPLOYEE and DEPARTMENT
• Different meanings and different relationship instances.

45 46

Constraints on Relationships One-to-One Relationships

§ Constraints on Relationship Types § In a one-to-one relationship, each instance of an entity class
• (Also known as ratio constraints) E1 can be associated with at most one instance of another
• Cardinality Ratio (specifies maximum participation) entity class E2 and vice versa.
One-to-one (1:1)
One-to-many (1:N) or Many-to-one (N:1) § Example: A department may have only one manager, and a
Many-to-many (M:N) manager may manage only one department.
• Existence Dependency Constraint (specifies minimum
participation) (also called participation constraint) Employee Department
Manages 4
zero (optional participation, not existence-dependent)
0..1 0..1
one or more (mandatory participation, existence-dependent)
Each department Each employee manages
may have a manager. zero or one department.

47 48

12
 Many-to-one (N:1) Relationship
One-to-One Relationship Example

Employee Manages Department

E1 D1
E2

E3 D2

E4
D3
E5 r1

E6 D4
r2
E7
r3
E8

Relationship explanation: A department may have only one manager. A

manager (employee) may manage only one department.
49 50

One-to-Many Relationships One-to-Many Relationship Example

§ In a one-to-many relationship, each instance of an entity
class E1 can be associated with more than one instance of Project Has Department
another entity class E2. However, E2 can only be
P1
associated with at most one instance of entity class E1. r1 D1

P2
§ Example: A department may have multiple projects, but a r2 D2
project may have only one department.
P3
r3
D3
Project Department
Has 4 P4 r4
0..* 0..1 D4
Each department has Each project has P5 r5
zero or more projects. zero or one departments.

Relationship: One-to-many relationship between department and

project.
51 52

13
 Many-to-Many Relationships Many-to-many (M:N) Relationship
§ In a many-to-many relationship, each instance of an entity
class E1 can be associated with more than one instance of
another entity class E2 and vice versa.

§ Example: An employee may work on multiple projects, and

a project may have multiple employees working on it.

Employee Project
WorksOn 4
0..* 0..*
Each project has Each employee works on
zero or more employees. zero or more projects.

53 54

Recursive Relationship Type Displaying a recursive relationship

§ A relationship type between the same participating entity § In a recursive relationship type.
type in distinct roles • Both participations are same entity type in
§ Also called a self-referencing relationship type. different roles.
§ Example: the SUPERVISION relationship • For example, SUPERVISION relationships
between EMPLOYEE (in role of supervisor or
§ EMPLOYEE participates twice in two distinct roles: boss) and (another) EMPLOYEE (in role of
• supervisor (or boss) role subordinate or worker).
• supervisee (or subordinate) role § In following figure, first role participation labeled with 1 and
§ Each relationship instance relates two distinct EMPLOYEE second role participation labeled with 2.
entities: § In ER diagram, need to display role names to distinguish
participations.
• One employee in supervisor role
• One employee in supervisee role

55 56

14
 A Recursive Relationship Supervision` Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

57 58

Weak Entity Types Attributes of Relationship types

§ An entity that does not have a key attribute and that is identification- § A relationship type can have attributes:
dependent on another entity type. • For example, HoursPerWeek of WORKS_ON
§ A weak entity must participate in an identifying relationship type with an
• Its value for each relationship instance describes the number of hours
owner or identifying entity type
per week that an EMPLOYEE works on a PROJECT.
§ Entities are identified by the combination of: A value of HoursPerWeek depends on a particular (employee,
• A partial key of the weak entity type project) combination
• The particular entity they are related to in the identifying relationship • Most relationship attributes are used with M:N relationships
type In 1:N relationships, they can be transferred to the entity type on the
§ Example: N-side of the relationship
• A DEPENDENT entity is identified by the dependent’s first name, and
the specific EMPLOYEE with whom the dependent is related
• Name of DEPENDENT is the partial key
• DEPENDENT is a weak entity type
• EMPLOYEE is its identifying entity type via the identifying relationship
type DEPENDENT_OF

59 60

15
Example Attribute of a Relationship Type:
Hours of WORKS_ON Participation Constraints
§ Cardinality is the maximum number of relationship
instances for an entity participating in a relationship type.

§ Participation is the minimum number of relationship

instances for an entity participating in a relationship type.
• Participation can be optional (zero) or mandatory (1 or more).

§ If an entity's participation in a relationship is mandatory (also

called total participation), then the entity's existence
depends on the relationship.
• Called an existence dependency.

61 62

One-to-Many Participation
Participation Constraints Example
Relationship Example
§ Example: A project is associated with one department, and
a department may have zero or more projects. Project Has Department

P1
r1 D1

Project P2
Department r2 D2
Has 4
0..* 1..1
P3
A department may not
r3
A project may have only one D3
have any projects. department.
P4 r4
Each project has
A department may have a department. D4
multiple projects. r5
P5

Note: Every project must participate in the relationship

(mandatory). Relationship explanation: A project must be associated with one
department. A department may have zero or more projects.
63 64

16
 Many-to-Many Relationship
Participation Constraints Example 2
Participation Example
§ Example: A project must have one or more employees, and
an employee must work on one or more projects. Employee WorksOn Project
E1 r1 P1
E2 r2
r3 P2
Employee Project E3
WorksOn 4 r4
1..* 1..* E4
r5 P3
A project must have An employee may work on E5
at least one employee. multiple projects. r6
Each employee works on E6 P4
A project may have
r7
at least one project.
multiple employees. E7 r8
E8 P5
r9
r10

65 66

Alternative (min, max) notation for relationship

Notation for Constraints on Relationships
structural constraints:
§ Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or § Specified on each participation of an entity type E in a relationship type
R
M:N § Specifies that each entity e in E participates in at least min and at most
• Shown by placing appropriate numbers on the relationship edges. max relationship instances in R
§ Participation constraint (on each participating entity type): § Default(no constraint): min=0, max=n (signifying no limit)
total (called existence dependency) or partial. § Must have min£max, min³0, max ³1
• Total shown by double line, partial by single line. § Derived from the knowledge of mini-world constraints
§ Examples:
§ NOTE: These are easy to specify for Binary Relationship • A department has exactly one manager and an employee can manage
Types. at most one department.
Specify (0,1) for participation of EMPLOYEE in MANAGES
Specify (1,1) for participation of DEPARTMENT in MANAGES
• An employee can work for exactly one department but a department
can have any number of employees.
Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
Specify (0,n) for participation of DEPARTMENT in WORKS_FOR

67 68

17
 The (min,max) notation for relationship
COMPANY ER Schema Diagram using
constraints (min, max) notation

Read the min,max numbers next to the entity

type and looking away from the entity type

69 70

Alternate “syntax” for ER Model: UML Notation UML class diagrams

§ Represent classes (similar to entity types) as large rounded
boxes with three sections:
§ If you are familiar with UML, then ER database design can • Top section includes entity type (class) name
be expressed using Unified Modeling Language (UML) • Second section includes attributes
diagrams • Third section includes class operations (operations are not in
basic ER model)
§ Relationships (called associations) represented as lines
connecting the classes
• Other UML terminology also differs from ER terminology
§ Used in database design and object-oriented software
design
§ UML has many other types of diagrams for software design

71 72

18
 UML class diagram for COMPANY database
ER Model Example in UML notation
schema
3 Supervises
0..1
Supervisor Manages 4
0..*
Employee 0..1 0..* Department
Supervisee 3Has
number {PK} number {PK}
name 0..* 0..1 name
address
Composite state 0..1
Has
attribute city 6
street 0..*
title WorksOn 4
Project
salary 0..* 0..*
number {PK}
name
budget
location [1..3]
Relationship responsibility
/totalEmp
attributes hours

73 74

19