1. 02: ER Model Ch 4.1 – 4.4 Optionally, begin with Ch 2.1.
CS411 Database Systems
02: ER Model
Ch 4.1 – 4.4
Optionally, begin with Ch 2.1.

2. Quick Announcements Registration questions: tiny.cc/411faq
There is no waitlist
Wait and watch to see if you can get in
Go talk to the academic office if you have any questions
Website up: tiny.cc/411sp17
Piazza is up and active. Start looking for team-mates now!
I have OH right after class today.

3. Today’s topic: So, why should we learn about ER Models / Diagrams?

4. Steps in Building a DB Application
Suppose you are building your “tiny-Amazon” or “tiny-Uber”.
Step 1: conceptual design (a “doodle”) for your data
Step 2: translate conceptual design into DBMS format
Step 3: set up your database in the DBMS
Subsequently:
Step 4: You can access/modify your data directly via the DBMS command line [advanced users]
Step 5: You can write a host of (web/mobile) applications that access the DBMS [for ordinary users]
Rough Analogy: floor plan, outline of a portrait, classes in an object oriented software, etc.

5. Steps in Building a DB Application
Suppose you are building your “tiny-Amazon” or “tiny-Uber”.
Step 1: conceptual design: our focus for today
need a modeling language or formalism to express what are the needs for the application
the ER (or Entity Relationship) model is the most popular such modeling language
output: “an ER diagram” of the data underlying the application domain
Rough Analogy: floor plan, outline of a portrait, classes in an object oriented software, etc.

6. Topic for today… The Entity – Relationship (ER) model
(or as I like to call it, doodles about data)

7. Entity Relationship Model
Proposed by Peter Chen in 1976
Gives us a language to specify
What information the database must hold
How the bits of information relate to one another
What we will cover
basic stuff
constraints
weak entity sets
design principles

8. Example of an ER-diagram
name
category
name
price
makes
Company
Product
stockprice
buys
employs
3 main types of concepts: entity sets, relations, attributes
no operations
Person
name
ssn
address

9. 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.
“Product” and “Company” are two entity sets.
Company
stockprice
name
category
Product
name
price

10. Relationships Formal definition: A={1,2,3}, B={a,b,c,d},
if A, B are sets, then a relation R is a subset of A x B
A={1,2,3}, B={a,b,c,d},
R = {(1,a), (1,c), (3,b)}
Same story w/ entity sets
makes is a subset of Product x Company: 1 2 3 a b c d A= B=
buys is a subset of “Person X Product”.
But “buys” is different from “makes” in a specific way.
makes
Company
Product

11. Back to the Diagram Entity Sets: Rectangles
Attributes: Ovals attached to rectangles
Relationships: Diamonds connecting rectanges

12. ER Diagram name category name price makes Company Product stockprice
buys
employs
##plus a bunch of other specifications that cannot be pictorially represented
##must be specified in English
Person
name
ssn
address

13. More about relationships ...

14. Multiplicity of E/R Relationships1 2 3 a b c d
one-one:
many-one
many-many
One on LHS/RHS connected to at most one on RHS/LHS 1 2 3 a b c d
One on LHS connected to at most one on RHS
No constraints 1 2 3 a b c d
arrow means “at most 1”
a special case of a constraint on the degree of the relation (e.g., at most 10)
Multiplicity can be shown with arrows
Arrow = at most 1
Another interpretation: “determines”

15. Q: Example scenarios for each case?
one-one:
many-one
many-many
Department – head ??
Actor – play ??
Employee – company ??

16. Q: Example scenarios for each case?
one-one:
many-one
many-many
Department – head ?? Each dep has 1 head, each head has 1 dep: one-one
Actor – play ?? Each actor has many plays, each play has many actors: many-many
Employee – company ?? Each employee has one company, each company has many employees

17. Multiway Relationships
How do we model a purchase relationship between buyers,
products and stores?
Purchase
Product
Person
Store
Can still model as a mathematical set (how ?)
Yes: As a subset of product x store x person

18. Arrows in Multiway Relationships
Q: what does the arrow mean ? A: Q:
Rental
VideoStore
Person
Movie
Invoice
“At most one”. That is, a specific combination of videostore, invoice and person can correspond to at most one movie.
What if I had an arrow into Person?

19. Arrows in Multiway Relationships
Q: how do I say: “invoice determines store” ?
A: no good way; best approximation:
Q: Why is this bad ?
A: We aren’t clarifying that the store is a function of the invoice only
Rental
VideoStore
Person
Movie
Invoice
Because we arent clarifying that the Store is a function of the invoice alone, not the invoice, movie and person jointly.

20. Roles in Relationships
What if we need an entity set twice in one relationship?
Purchase
Product
Store
buyer
Person
Purchase
Product
Person
Store
salesperson
buyer

21. Roles in Relationships
What if we need an entity set twice in one relationship?
Product
Purchase
Store
buyer
salesperson
Person
Role described as a label on each edge.

22. Attributes on Relationships
date
Product
Purchase
Store
not necessary, but useful
Person

23. Attributes on Relationships
date
Attributes on Relationships
Purchase Detail
Product
Purchase
Store
Person
Thus, not necessary to add attributes to relationships.
But, this is overkill; simpler to have date as an attribute of Purchase

24. Some ER Modeling Tools Require 2-way Relationships
Do we need multi-way relationships or do 2-way (binary) relationships suffice?

25. How would you convert this into binary?
date
Product
Purchase
Store
not necessary, but useful
Person

26. Converting Multiway Relationships to Binary
Q: Why the arrows?
ProductOf
date
Product
Purchase
StoreOf
Store
There are some data models (not E/R, but say, UML or ODL) that require relationships to be binary. This slide notes that any multi-way rel can be converted to a collection of binary, many-one rels. (Note the arrows). Why many-one rels? Because the relationship was a *set*. Each member in that set is now an entity in the new "connecting" entity set. Each member uniquely corresponds to at most one entity in the other sets.
BuyerOf
Person

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

28. Subclasses in ER Diagrams
name
category
price
Product
A, B, C, D, E
isa
isa
isa is 1-1 relationship.
A, C
B, C, D
Software Product
Educational Product
platforms
Age Group

29. Subclasses “Isa” triangles indicate the subclass relationship.
Point to the superclass.
Subclasses form a tree.
I.e., no “multiple inheritance”.
Why subclasses?
Unnecessary to add redundant properties to the root entity set that don’t apply to many of the entities

30. ER Vs. Object Oriented Subclasses
In the object-oriented world, objects are in one class only.
Subclasses inherit properties from superclasses.
In contrast, E/R entities have components in all subclasses to which they belong.
Matters when we convert to relations.

31. Subclasses in ER Diagrams
name
category
price
Product
A, B, C, D, E
isa
isa
isa is 1-1 relationship.
A, C
B, C, D
Software Product
Educational Product
platforms
Age Group

32. Another Example year length Stars title Movies Voices isa isa
The Minions?
Mad Max: Fury Road?
Murder on the Orient Express?
Movies
Voices
isa
isa
Who framed roger rabbit
Animation Movies
Murder-Mysteries
weapon 32

33. Constraints in ER diagram
A constraint = an assertion about the database that must be true at all times
Part of the database schema = structure
(so it must be part of the ER diagram)
Very important in database design

34. Modeling Constraints
Finding constraints is part of the modeling process.
Commonly used constraints:
Keys: attributes that identify entities in an entity set
e.g., social security number uniquely identifies a person.
Referential integrity constraints: relationship-based constraints
e.g., 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 50 students enroll in a class)
Also, “single valued constraint” => Read text

35. Why Are Constraints Important?
They:
Allow us to give more semantics to the data
Help us better understand it
Lead to a more faithful modeling of the data
Allow us to refer to entities (e.g., using keys)
Enable efficient storage, data lookup, etc.

36. Keys in E/R Diagrams name category Underline: price
This means “name” and “category” together uniquely determine product
Product
No formal way
to specify multiple
keys in E/R diagrams
Person
name
ssn
address

37. More about Keys A key can consist of more than one attribute
Every entity set must have a key
why?
because the entity set is a set of uniquely identifiable entities; in the worst case all attributes together will form the key
There can be more than one key for an entity set
one key will be designated as primary key
Requirement for key in an isa hierarchy
see text

38. Referential Integrity Constraints
The database equivalent of “Don’t allow dangling pointers”
the Referential Integrity Constraint on relationships explicitly requires a reference to exist

39. Referential Integrity Constraints
Recall: the arrow meant “at most one”.
Each Product must be related to (“made by”) at most one Company in the database.
makes
Product
Company
Wouldn’t it be weird if a product was not associated with any company?
Company
Product
makes
This says “exactly one”.
Each Product must be related to (“made by”) exactly one Company in the database.
Arrow = at most 1
Semicircle = exactly 1

40. Referential Integrity Constraints
Owns
Runs
Studios
Presidents
Movies
What do these two semi-circles mean?
Each movie is owned by precisely one studio, and
Each president runs exactly one studio

41. Weak Entity Sets
Entity sets are weak when some of their key attributes come from other classes to which they are related.
We’ll see why this is important in a bit…
Sports and number don’t uniquely determine the team
Football team 1 may be present multiple times
But sport, univ and number do
affiliation
Team )
University
sport
number
name

42. Weak Entity Sets
Entity sets are weak when some of their key attributes come from other classes to which they are related.
CS411, along with UIUC determine the rest of the attributes
(“Database Systems”)
OfferedAt
Course )
University
Title
number
name

43. Weak Entity Sets
Occasionally, entities of an entity set need “help” to identify them uniquely.
Entity set E is 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 entity sets.
Note: not an is-a relationship because E is not a “subclass” of F: Univ and Team

44. Notations for weak entity set
affiliation
Team )
University
sport
number
name
OfferedAt
Course )
University
Title
number
name
“University” is a “supporting entity set” for “Team”.
“Affiliation” is a “supporting relationship”.

45. Another scenario where weak e.s. arises
date
Product
Purchase
Store
Person
A Multi-way relationship …

46. Another scenario where weak e.s. arises
… converted to binary relationships
Remember this is what we had…
ProductOf
date
Product
Purchase
StoreOf
Store
Note that the only descriptor of a “purchase” entity is “date”, which is obviously not enough.
Not sufficient to identify purchase via just dates
BuyerOf
Person 46

47. Another scenario where weak e.s. arises
3 Supporting Entity Sets &
3 Supporting Relationships
name
price
category
ProductOf
date
Product )
name
address
Purchase
StoreOf
Store )
address
name
ssn
BuyerOf )
Person 47

48. Now, about design principles ...

49. Design Principles Be Faithful to Reality Avoid Redundancy
Pick the Right Kind of Element
Also:
Simplicity
Choose the Right Relationships
(See Textbook for examples…)

50. Design Principles: Be Faithful To Reality
Purchase
Product
Person
No: A Person may purchase multiple Products
President
Country
Person
No: A Country can have at most one President
Teaches
Instructor
Course
Yes if multiple instructors, No if not.

51. Avoiding Redundancy
Redundancy occurs when we say the same thing in two different ways.
Redundancy wastes space (as we will see) and (more importantly) encourages inconsistency.
The two instances of the same fact may become inconsistent if we change one & forget to change the other.

52. Example: Good name name addr ManfBy Beers Manfs
This design gives the address of each manufacturer exactly once.

53. Example: Bad name name addr ManfBy Beers Manfs manf
This design states the name of the manufacturer of a beer twice: as an attribute and as a related entity.
Update issues, Wasteful, …

54. Example: Bad name manf manfAddr Beers
This design repeats the manufacturer’s address once for each beer (wasteful, update anomalies);
Also loses the address if there are temporarily no beers for a manufacturer.

55. Entity Sets Versus Attributes
An entity set should satisfy at least one of the following conditions:
It is more than the name of something;
i.e., it has at least one non-key attribute. or
It is the “many” in a many-one or many-many relationship.
Examples will illustrate why, but also think why each of these rules actually make sense.

56. Example: Good name name addr ManfBy Beers Manfs
Manfs deserves to be an entity set because of the nonkey attribute addr.
Beers deserves to be an entity set because it is the “many” of the many-one relationship ManfBy.

57. Example: Good name manf Beers
If we had no manufacturer address information…
There is no need to make the manufacturer an entity set, because we record nothing about manufacturers besides their name.

58. Example: Bad name name ManfBy Beers Manfs
Since the manufacturer is nothing but a name, and is not at the “many” end of any relationship, it should not be an entity set.

59. ER Review Basic stuff Constraints entity, attribute, entity set
relation: binary, multiway, converting from multiway
relationship roles, attributes on relationships
subclasses (is-a)
Constraints
on relations
many-one, one-one, many-many
limitations of arrows
keys, single-valued, ref integrity, domain & general constraints

60. ER Review
Weak entity set
Design principles