1. CS4433 Database Systems
E-R Model

2. Why should we study this?

3. Key Steps in Building DB Applications
Step 0: pick an application domain
Step 1: conceptual design
Decide what to model in the application domain
Need a modeling language to express what you want
ER model is the most popular such language
Output: an ER diagram of the application domain

4. Key Steps in Building DB Applications
Step 2: pick a type of DBMS’s
Relational DBMS is most popular and is our focus
Step 3: translate ER design to a relational schema
Use a set of rules to translate from ER to relational schema
Use a set of schema refinement rules to transform the above relational schema into a good relational schema
At this point
You have a good relational schema on paper

5. Key Steps in Building DB Applications
Subsequent steps include
Implement your relational DBMS using a "database programming language" called SQL
Ordinary users cannot interact with the database directly and the database also cannot do everything you want, hence write your application program in C++, Java, PHP, etc. to handle the interaction and take care of things that the database cannot do
So, the first thing we should start with is to learn ER model ...

6. RUNNING EXAMPLE We want to store information about:
companies and employees
Each company has a name, an address, …
Each company has a list of employees
products manufactured by these companies
Each product has a name, a description, …

7. ER Model A language to specify what information a database must hold
what are the relationships among components of that information
What we will cover
basic constructs, constraints, weak entity sets, and design principles
Proposed by Peter Chen in 1976
"The Entity-Relationship Model --- Toward a Unified View of Data". in ACM transactions on database systems (TODS)
One of the most cited CS papers

8. Entities and Attributes
Real-world objects distinguishable from other objects
Described using a set of attributes
Attributes
each has an atomic domain: string, integers, reals, etc.
Entity set: a collection of similar entities

9. (Binary) Relationship
A mathematical definition:
if A, B are sets, then a relation R is a subset of A x B (Cartesian product)
A={1,2,3}, B={a, b, c, d},
R = {(1,a), (1,c), (3,b)}
makes is a subset of Product x Company: 1 2 3 a b c d A= B=
makes
Company
Product

10. Multiplicity of E/R Relationships
one-one:
many-one
many-many 1 2 3 a b c 1 2 3 a b c d 1 2 3 a b c d
What about makes relation?
makes
Company
Product

11. Example
An employee can work in many departments; a department can have many employees
In contrast, each department has at most one manager. So ?
dname
budget
did
Departments
Works_In
lot
name
ssn
Employees
How should be manage relation?
Manages

12. Multiway Relationships
How do we model a purchase relationship between buyers,
products and stores?
Purchase
Product
Person
Store
Can still be modeled as a mathematical set (how ?)
We can still model this as a mathematical set (ternary relation)

13. Arrows in Multiway Relationships
Q: what does the arrow mean ?
Purchase
Product
Person
Store
A given person can purchase a given product from at most one store!

14. Arrows in Multiway Relationships
Q: what does the arrow mean ?
Purchase
Product
Person
Store
A given person can purchase a given product from at most one store AND a given store sells to a given person at most one product

15. Roles in Relationships
What if we need an entity set twice in one relationship?
Purchase
Product
Person
Store
Person ?
Salesperson
Buyer

16. Roles in Relationships
Label the edges to indicate the roles
Collapse the two entity sets into one
Purchase
Product
Person
Store
Salesperson
Buyer

17. Attributes on Relationships
Purchase
Product
Person
Store
date

18. Converting Multiway Relationships to Binary
ProductOf
Product
Purchase
StoreOf
Store
date
BuyerOf
Person

19. Relationships: Summary
Modeled as a mathematical set
Binary and multiway relationships
Converting a multiway one into many binary ones
Constraints on the degree of the relationship
many-one, one-one, many-many
Attributes of relationships
not necessary, but useful

20. Subclasses(subentities)
Entity set containing special properties not associated with all members of the set
Subclass = special case
= with its own special properties and/or relationships
Example: Products
Software products
Educational products
Let us suppose that in addition to all the properties (attributes and relationships) of products, Software products also have the other attributes, e.g. platform
Assume subclasses form a tree
No multiple inheritance
Isa triangles indicate the subclass relationship
Point to the superclass
Superclass contains all common attributes
Subclasses contain specific attributes.

21. Subclasses price name category Product isa isa Software Product
Educational Product
platforms
age group

22. How to keep subclasstype
price
name
category
type
How to keep subclasstype
Supertype may have a discriminator attribute which indicates subtype
Product
isa
isa
Software Product
Educational Product
age group
platforms

23. Advantages of IsA Can create a more concise and readable E-R diagram
Attributes common to different entity sets need not be repeated
They can be grouped in one place as attributes of supertype
Attributes of (sibling) subtypes can be different

24. How to create ER for this?
STUDENT : UNDERGRADATE or GRADUATE

25. Subtypes: Exclusive or Inclusive
If subclasses are exclusive,
one superclass relates to at most one subclass.
If subclasses are inclusive,
one superclass can relate to one or more subclass.

26. ER diagram of
person
Student
Freshman …
Employee
Secretary ..

27. Constraints
Constraint: an assertion about the database that must be true at all times
Part of the database schema
Very important in database design
When creating the ER diagram, you need to find as many constraints as possible!
Finding constraints is part of the modeling process
Types of Constraints
Keys: SSN uniquely identifies a person
Single-value constraints: a person can have only one father
Referential integrity constraints: if you work for a company, it must exist in the database
Domain constraints: peoples’ ages are between 0 and 150
General constraints: all others (at most 60 students enroll in the class COP4710)

28. Why Constraints Give more semantics to the data
Help us better understand it
Prevent wrong data entry
Allow us to refer to entities (e.g., using keys)
Enable efficient storage, data lookup, etc.

29. Keys in E/R Diagrams Every entity set must have a key why?
The key is an attribute or a group of attributes whose values can be used to uniquely identify an individual entity in an entity set.
There can be more than one key for an entity set
A candidate key is a simple or composite key that is unique and minimal. 
It is unique because no two rows in a table may have the same value at any time.
It is minimal because every column is necessary in order to attain uniqueness.
Among all candidate keys, one key will be designated as primary key
The primary key is a candidate key that is selected by the database designer to be used as an identifying mechanism for the whole entity set. It must uniquely identify tuples in a table and not be null. The primary key is indicated in the ER model by underlining the attribute.

30. Keys in E/R Diagrams Underline: No formal way to specify multiple
price
name
category
Underline:
Product
No formal way
to specify multiple
keys in E/R diagrams
Person
name
ssn
address

31. SINGLE-VALUE CONSTRAINTS
An entity may have at most one value for a given attribute or relationship
an attribute of an entity set has a single value
a many-one relation implies a single value constraint
E.g. a person can have only one father

32. Not null An attribute has a non-null, single value value must exist
E.g. Each person much have a name

33. Referential Integrity Constraint
states that table relationships must always be consistent. 
if a value of one attribute (column) of a relation (table) references a value of another attribute (either in the same or a different relation), then the referenced value must exist
In some formalisms we may refer to other object but get garbage instead
e.g. a dangling pointer in C/C++
The Referential integrity constraint on relationships explicitly requires a reference to exist

34. Referential Integrity Constraint

35. Referential Integrity Constraint
makes
Product
Company
makes
Product
Company

36. Weak Entity Sets
Entity sets are weak when their key attributes come from other classes to which they are related
This happens if:
part-of hierarchies
splitting n-ary relations to binary
Diamond with double border
If an attribute of it is a part of the key, underline it
lot
name
age
pname
Dependents
Employees
ssn
Policy
cost )

37. Weak Entity Sets The entity set E is said to be weak if
in order to identify entities of E uniquely, we need to follow one or more many-one relationships from E and include the key of the related entities from the owner entity sets: one owner, many weak entities
lot
name
age
pname
Dependents
Employees
ssn
Policy
cost )

38. Weak Entity Sets examples

39. Design Principles:

40. Be Faithful Entity set and their attributes should reflect reality
Can not attach an attribute “number of cylinders” to “Stars” entity
Relationship types should make sense with real world
Star-Movie
Less obvious

41. Be Faithful What is wrong here?
Purchase
Product
Person
President
Country
Person
Teaches
Instructor
Course

42. Avoiding Redundancy
Redundancy occurs when we say the same thing in two different ways
Redundancy wastes space and (more importantly) encourages inconsistency
The two instances of the same fact may become inconsistent if we change one and forget to change the other, related version
name
name
addr
ManfBy
Beers
Manfs
manf
This design states the manufacturer of a beer twice: as an attribute and as a related entity
Problem?

43. Another Possible Design
name
manf
manfAddr
Beers
What is the problem?
This design repeats the manufacturer’s address once for each beer; loses the address if there are temporarily no beers for a manufacturer
Good design??

44. A Good Design name name addr ManfBy Beers Manfs
This design gives the address of each manufacturer exactly once

45. Entity Sets vs. Attributes
An entity set should satisfy at least one of the following conditions:
It is more than the name of something; it has at least one non-key attribute. or
It is the “many” in a many-one or many-many relationship
name
name
addr
ManfBy
Beers
Manfs

46. Which One is Good?
name
manf
Beers
name
name
ManfBy
Beers
Manfs

47. Don’t Overuse Weak Entity Sets
Database designers often doubt that anything could be a key by itself
They make all entity sets weak, supported by all other entity sets to which they are linked
In reality, we usually create unique ID’s for entity sets.
Examples include social-security numbers, automobile VIN’s etc
When Do We Need Weak Entity Sets?
The usual reason is that there is no global authority capable of creating unique ID’s
Example: it is unlikely that there could be an agreement to assign unique player numbers across all football teams in the world

48. How to Identify Them by #10

49. ER modeling questions Conceptual design Entity vs attribute
Entity vs relationship ?

50. Entity vs. attribute Entity EMPLOYEE (w/ emp#, name, job_code, ...)
Q: How about ‘spouse’ - entity or attribute?
A: probably, ‘attribute’ is enough
Q: How about ‘dependents’?
A: Entity - we may have many dependents

51. Entity vs. Relationship

52. ER Review Basic constructs entity, attribute, entity set
relation: binary, multi-way, converting from multi-way
relationship roles, attributes on relationships
subclasses (is-a)
Constraints
on relations
many-one, one-one, many-many
keys, single-valued, ref. integrity, domain & general constraints
Weak Entity Set
Design principles