1. CPSC-310 Database Systems
Professor Jianer Chen
Room 315C HRBB
Lecture #3
Source: modification of slides by Jeffrey Ullman of Stanford U.

2. Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures
Functional Dependencies (Ch. 3)
Basic operations on relations
Relational Algebra (Ch. 2)
Storage management
(Chs )
SQL languages in DDL/DML
(Ch. 6)
Query processing
(Chs )
More on SQL
(Chs. 7-9)
Transition processing
(Chs )

3. Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures
Functional Dependencies (Ch. 3)
Basic operations on relations
Relational Algebra (Ch. 2)
Storage management
(Chs )
SQL languages in DDL/DML
(Ch. 6)
Query processing
(Chs )
More on SQL
(Chs. 7-9)
Transition processing
(Chs )

4. Roles
Sometimes an entity set appears more than once in a relationship.

5. Roles
Sometimes an entity set appears more than once in a relationship.
Example 1. Married relationship
Husband Wife
Bob Ann
Joe Sue
… …
Drinkers
Married

6. Roles
Sometimes an entity set appears more than once in a relationship.
Example 1. Married relationship
Example 2. Buddies relationship
Buddy Buddy2
Bob Ann
Joe Sue
Ann Bob
Joe Moe
… …
Husband Wife
Bob Ann
Joe Sue
… …
Drinkers
Married
Drinkers
Buddies

7. Roles
Sometimes an entity set appears more than once in a relationship.
Example 1. Married relationship
Example 2. Buddies relationship
Label the edges between the relationship and the entity set with names called roles.
Buddy Buddy2
Bob Ann
Joe Sue
Ann Bob
Joe Moe
… …
Husband Wife
Bob Ann
Joe Sue
… …
Drinkers
Married
Drinkers
Buddies

8. Roles
Sometimes an entity set appears more than once in a relationship.
Example 1. Married relationship
Example 2. Buddies relationship
Label the edges between the relationship and the entity set with names called roles.
Buddy Buddy2
Bob Ann
Joe Sue
Ann Bob
Joe Moe
… …
Husband Wife
Bob Ann
Joe Sue
… …
Drinkers
Married
husband
wife
Drinkers
Buddies

9. Roles
Sometimes an entity set appears more than once in a relationship.
Example 1. Married relationship
Example 2. Buddies relationship
Label the edges between the relationship and the entity set with names called roles.
Buddy Buddy2
Bob Ann
Joe Sue
Ann Bob
Joe Moe
… …
Husband Wife
Bob Ann
Joe Sue
… …
Drinkers
Married
husband
wife
Drinkers
Buddies 1 2

10. Subclasses
Subclass = special case = fewer entities = more properties.

11. Subclasses Subclass = special case = fewer entities = more properties.
Assume subclasses form a tree, i.e., no multiple inheritance.

12. Subclasses Subclass = special case = fewer entities = more properties.
Assume subclasses form a tree, i.e., no multiple inheritance.
Isa triangles indicate the subclass relationship, which points to the superclass.

13. Subclasses Subclass = special case = fewer entities = more properties.
Assume subclasses form a tree, i.e., no multiple inheritance.
Isa triangles indicate the subclass relationship, which points to the superclass.
Example Ales are a kind of beer. Not every beer is an ale, but some are. Suppose that in addition to all the properties (attributes and relationships) of beers, ales also have the attribute color.

14. Subclasses Subclass = special case = fewer entities = more properties.
Assume subclasses form a tree, i.e., no multiple inheritance.
Isa triangles indicate the subclass relationship, which points to the superclass.
Example Ales are a kind of beer. Not every beer is an ale, but some are. Suppose that in addition to all the properties (attributes and relationships) of beers, ales also have the attribute color.
name
Beers
manf
isa
Ales
color

15. Keys
A key is a set of attributes for an entity set such that no two entities in this set agree on all the attributes of the key.

16. Keys
A key is a set of attributes for an entity set such that no two entities in this set agree on all the attributes of the key.
It is allowed for two entities to agree on some, but not all, of the key attributes.

17. Keys
A key is a set of attributes for an entity set such that no two entities in this set agree on all the attributes of the key.
It is allowed for two entities to agree on some, but not all, of the key attributes.
We must designate a key for each entity set.

18. Keys
A key is a set of attributes for an entity set such that no two entities in this set agree on all the attributes of the key.
It is allowed for two entities to agree on some, but not all, of the key attributes.
We must designate a key for each entity set.
In an E/R diagram, underline the key attribute(s).

19. Keys
A key is a set of attributes for an entity set such that no two entities in this set agree on all the attributes of the key.
It is allowed for two entities to agree on some, but not all, of the key attributes.
We must designate a key for each entity set.
In an E/R diagram, underline the key attribute(s).
Courses
dept
number
hours
room

20. Keys
A key is a set of attributes for an entity set such that no two entities in this set agree on all the attributes of the key.
It is allowed for two entities to agree on some, but not all, of the key attributes.
We must designate a key for each entity set.
In an E/R diagram, underline the key attribute(s).
Courses
dept
number
hours
room
Note that hours and room could also serve as a key, but we must select only one key.

21. Keys
A key is a set of attributes for an entity set such that no two entities in this set agree on all the attributes of the key.
It is allowed for two entities to agree on some, but not all, of the key attributes.
We must designate a key for each entity set.
In an E/R diagram, underline the key attribute(s).
In an Isa hierarchy, only the root entity set has a key, which is the key for all entities in the hierarchy.
Courses
dept
number
hours
room
Note that hours and room could also serve as a key, but we must select only one key.

22. Keys
A key is a set of attributes for an entity set such that no two entities in this set agree on all the attributes of the key.
It is allowed for two entities to agree on some, but not all, of the key attributes.
We must designate a key for each entity set.
In an E/R diagram, underline the key attribute(s).
In an Isa hierarchy, only the root entity set has a key, which is the key for all entities in the hierarchy.
Beers
Ales
isa
name
manf
color
Courses
dept
number
hours
room
Note that hours and room could also serve as a key, but we must select only one key.

23. Weak Entity Sets
Occasionally, entities of an entity set need “help” to identify them uniquely.

24. Weak Entity Sets
Occasionally, entities of an entity set need “help” to identify them uniquely.
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 connected entity sets.

25. Example
(player) name is almost a key for football players, but there might be two players with the same name.

26. Example
(player) name is almost a key for football players, but there might be two players with the same name.
(player) number is certainly not a key, since players on two teams could have the same number.

27. Example
(player) name is almost a key for football players, but there might be two players with the same name.
(player) number is certainly not a key, since players on two teams could have the same number.
But number, together with the (team) name related to the player by relationship Plays-on should be unique.

28. Example
(player) name is almost a key for football players, but there might be two players with the same name.
(player) number is certainly not a key, since players on two teams could have the same number.
But number, together with the (team) name related to the player by relationship Plays-on should be unique.
Players
Teams
Plays-on
name
number

29. Example
(player) name is almost a key for football players, but there might be two players with the same name.
(player) number is certainly not a key, since players on two teams could have the same number.
But number, together with the (team) name related to the player by relationship Plays-on should be unique.
Players
Teams
Plays-on
name
number
Double diamond for supporting many-one relationship.
Double rectangle for the weak entity set.

30. Weak Entity-Set Rules
A weak entity set has one or more many-one relationships to other (supporting) entity sets.

31. Weak Entity-Set Rules
A weak entity set has one or more many-one relationships to other (supporting) entity sets.
Not every many-one relationship from a weak entity set need be supporting.

32. Weak Entity-Set Rules
A weak entity set has one or more many-one relationships to other (supporting) entity sets.
Not every many-one relationship from a weak entity set need be supporting.
The key for a weak entity set is its own underlined attributes and the keys for the supporting entity sets.

33. Weak Entity-Set Rules
A weak entity set has one or more many-one relationships to other (supporting) entity sets.
Not every many-one relationship from a weak entity set need be supporting.
The key for a weak entity set is its own underlined attributes and the keys for the supporting entity sets.
Example. (player) number and (team) name is a key for Players in the previous example.

34. Weak Entity-Set Rules
A weak entity set has one or more many-one relationships to other (supporting) entity sets.
Not every many-one relationship from a weak entity set need be supporting.
The key for a weak entity set is its own underlined attributes and the keys for the supporting entity sets.
Example. (player) number and (team) name is a key for Players in the previous example.
Players
Teams
Plays-on
name
number

35. How to make a good E/R diagram?

36. How to make a good E/R diagram?
Avoid redundancy.

37. How to make a good E/R diagram?
Avoid redundancy.
Don’t use an entity set when an attribute will do.

38. How to make a good E/R diagram?
Avoid redundancy.
Don’t use an entity set when an attribute will do.
Limit the use of weak entity sets.

39. How to make a good E/R diagram?
Avoid redundancy.
Don’t use an entity set when an attribute will do.
Limit the use of weak entity sets.

40. Avoiding Redundancy
Redundancy occurs when we say the same thing in two or more different ways.

41. Avoiding Redundancy
Redundancy occurs when we say the same thing in two or more different ways.
Redundancy wastes space

42. Avoiding Redundancy
Redundancy occurs when we say the same thing in two or more different ways.
Redundancy wastes space and (more importantly) encourages inconsistency.

43. Avoiding Redundancy
Redundancy occurs when we say the same thing in two or more 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 (update anomaly), or when we delete instances (deletion anomaly).

44. Avoiding Redundancy
Redundancy occurs when we say the same thing in two or more 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 (update anomaly), or when we delete instances (deletion anomaly).
Beers
name
manf
manfAddr
Bad: This design repeats the manufacturer’s address once for each beer and loses the address if there are temporarily no beers for a manufacturer.

45. Avoiding Redundancy
Redundancy occurs when we say the same thing in two or more 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 (update anomaly), or when we delete instances (deletion anomaly).
Beers
name
manf
manfAddr
name
name
addr
ManfBy
Beers
Manfs
Bad: This design repeats the manufacturer’s address once for each beer and loses the address if there are temporarily no beers for a manufacturer.
Good: This design gives the address of each manufacturer exactly once.

46. Avoiding Redundancy
Redundancy occurs when we say the same thing in two or more 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 (update anomaly).
Beers
Manfs
ManfBy
name
manf
addr
Another example of bad designs 46

47. How to make a good E/R diagram?
Avoid redundancy.
Don’t use an entity set when an attribute will do.
Limit the use of weak entity sets.

48. Entity Sets Versus Attributes
An entity set should satisfy at least one of the following conditions:

49. Entity Sets Versus 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 nonkey attribute,

50. Entity Sets Versus 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 nonkey attribute, or
It is the “many” in a many-one or many-many relationship.

51. Entity Sets Versus 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 nonkey attribute, or
It is the “many” in a many-one or many-many relationship.
Beers
Manfs
ManfBy
name
Bad: The manufacturer is nothing but a name, and is not at the “many” end of any relationship, it should not be an entity set.

52. Entity Sets Versus 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 nonkey attribute, or
It is the “many” in a many-one or many-many relationship.
Beers
Manfs
ManfBy
name
Beers
name
manf
Good: Since nothing is recorded for manufacturers besides their names, there is no need to make the manufacturer an entity set.
Bad: The manufacturer is nothing but a name, and is not at the “many” end of any relationship, it should not be an entity set.

53. Entity Sets Versus 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 nonkey attribute, or
It is the “many” in a many-one or many-many relationship.
Beers
Manfs
ManfBy
name
Beers
name
manf
Good: However, if we also need to record manufacturers’ addresses:
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.

54. Entity Sets Versus 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 nonkey attribute, or
It is the “many” in a many-one or many-many relationship.
Beers
Manfs
ManfBy
name
addr
Good: However, if we also need to record manufacturers’ addresses:
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.

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; it has at least one nonkey attribute, or
It is the “many” in a many-one or many-many relationship.
Beers
Manfs
ManfBy
name
addr
Good: However, if we also need to record manufacturers’ addresses:
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.

56. Entity Sets Versus 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 nonkey attribute, or
It is the “many” in a many-one or many-many relationship.
Beers
Manfs
ManfBy
name
addr
Good: However, if we also need to record manufacturers’ addresses:
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. How to make a good E/R diagram?
Avoid redundancy.
Don’t use an entity set when an attribute will do.
Limit the use of weak entity sets.

58. Don’t Overuse Weak Entity Sets
Beginning 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.

59. Don’t Overuse Weak Entity Sets
Beginning 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.

60. When Do We Need Weak Entity Sets?
The usual reason is that there is no global authority capable of creating unique ID’s.

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

62. Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures
Functional Dependencies (Ch. 3)
Basic operations on relations
Relational Algebra (Ch. 2)
Storage management
(Chs )
SQL languages in DDL/DML
(Ch. 6)
Query processing
(Chs )
More on SQL
(Chs. 7-9)
Transition processing
(Chs )

63. Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures
Functional Dependencies (Ch. 3)
Basic operations on relations
Relational Algebra (Ch. 2)
Storage management
(Chs )
SQL languages in DDL/DML
(Ch. 6)
Query processing
(Chs )
More on SQL
(Chs. 7-9)
Transition processing
(Chs )

64. From E/R Diagrams to Relations (Converting E/R diagrams into tables)

65. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
a relation is a table

66. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
a relation is a table
name manf
Winterbrew Pete’s
Bud Lite Anheuser-Busch
Beers

67. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
a relation is a table
name manf
Winterbrew Pete’s
Bud Lite Anheuser-Busch
Beers
table/relation name

68. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
a relation is a table
Attributes
(column
headers)
name manf
Winterbrew Pete’s
Bud Lite Anheuser-Busch
Beers
table/relation name

69. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
a relation is a table
Attributes
(column
headers)
name manf
Winterbrew Pete’s
Bud Lite Anheuser-Busch
Beers
Tuples
(rows)
table/relation name

70. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
Schemas

71. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
Schemas
Relation schema = relation name and attribute list.

72. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
Schemas
Relation schema = relation name and attribute list.
Optionally: types of attributes

73. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
Schemas
Relation schema = relation name and attribute list.
Optionally: types of attributes
Example: Beers(name, manf) or Beers(name: string, manf: string)

74. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
Schemas
Relation schema = relation name and attribute list.
Optionally: types of attributes
Example: Beers(name, manf) or Beers(name: string, manf: string)
Database = collection of relations.

75. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
Schemas
Relation schema = relation name and attribute list.
Optionally: types of attributes
Example: Beers(name, manf) or Beers(name: string, manf: string)
Database = collection of relations.
Database schema = all relation schemas in the database.

76. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
Why Relations?

77. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
Why Relations?
Very simple model.
Often matches how we think about data.
Abstract model that underlies SQL, the most important database language today.

78. From E/R Diagrams to Relations (Converting E/R diagrams into tables)

79. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).

80. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
Beers
name
manf
Relation: Beers(name, manf)

81. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
a relationship  a relation with attributes:
* keys of the connected entity sets.
* attributes of the relationship itself.

82. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
a relationship  a relation with attributes:
* keys of the connected entity sets.
* attributes of the relationship itself.
name
addr
name
manf
Drinkers
Beers

83. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
a relationship  a relation with attributes:
* keys of the connected entity sets.
* attributes of the relationship itself.
name
addr
name
manf
Drinkers
Likes
Beers

84. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
a relationship  a relation with attributes:
* keys of the connected entity sets.
* attributes of the relationship itself.
name
addr
name
manf
Drinkers
Likes
Beers
Likes(drinker, beer)

85. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
a relationship  a relation with attributes:
* keys of the connected entity sets.
* attributes of the relationship itself.
Likes(drinker, beer)
Favorite(drinker, beer)
Drinkers
Beers
Likes
Favorite
name
addr
manf

86. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
a relationship  a relation with attributes:
* keys of the connected entity sets.
* attributes of the relationship itself.
name
addr
name
manf
Drinkers
Likes
Beers 2 1
Favorite
Likes(drinker, beer)
Buddies
Favorite(drinker, beer)
Buddies(name1, name2)

87. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
a relationship  a relation with attributes:
* keys of the connected entity sets.
* attributes of the relationship itself.
name
addr
name
manf
Drinkers
Likes
Beers 2 1
Favorite
Likes(drinker, beer)
Buddies
Favorite(drinker, beer)
husband
wife
Buddies(name1, name2)
Married
Married(husband, wife)

88. From E/R Diagrams to Relations (Converting E/R diagrams into tables)
an entity set  a relation (attributes  attributes).
a relationship  a relation with attributes:
* keys of the connected entity sets.
* attributes of the relationship itself.
Likes(drinker, beer)
Favorite(drinker, beer)
Married(husband, wife)
Buddies(name1, name2)
Drinkers
Beers
Likes
Favorite
Married
husband
wife
name
addr
manf
Buddies 1 2