1. CS 157B Database Systems Dr. T Y Lin

2. 1.2 Overview of a Database Management System 1.2.1 Data-Definition Language Commands –Illustrated by three examples on the website http://xanadu.cs.sjsu.edu/~drtylin/classes/cs157B/Spring2010/ Demo by Yaniv Cohen- 2/2/2011

3. Chapter 2 Relational Database Modeling

4. 2.1 An Overview of Data Models 2.1.1 What is a Data Model? 2.1.2 Important Data Models 2.1.3 The Relational Model in Brief 2.1.4 The Semistructured Model in Brief 2.1.5 Other Data Models 2.1.6 Comparison of Modeling Approaches

5. 2.1.1 What is a Data Model? Real World  Math Model: “  ” is explicit correspondence between real world objects to mathematical objects Roughly Entities  tuples

6. 2.1.1 What is a Data Model? Real World  Math Model: 1.Structure of the data (tuples) 2.Operations on the data –real world changes 3.Constraints on the data – to describe the data as close to real object as possible.

7. 2.2 Basics of the Relational Model TitleYearLengthgenre Gone with the wind1939231Drama Star Wars1977124SciFi Wayne’s world199295comedy Figure 2.3 The Relation Movies

8. 2.2.5 Equivalent Representations of a Relation A relation is a subset (of Cartesian product of domains(=sets)), so there is no order among tuples (elements) Every attribute is named, so if data(element) move with names, there is no order; we often refer such data as attribute value pair.

9. 2.2.5 Equivalent Representations of a Relation YearGenreTitlelength 1977SciFiStar Wars124 1992ComedyWayne’s World95 1939DramaGone With the Wind231 Figure 2.4 Another presentation of the relation Movies

10. 2.2.6 Relation Instances All the relation examples given in the web site are Relation Instances Relation is a variable Relation instance is a value in the variable.

11. Database Schema about Movies Moviestar ( name : string, address : string, gender : char, birthdate : date ) Movies( title: string; Year : integer, Length : integer, Genre : string, studioName : string, producerC# : integer )

12. StarsIn ( MovieTitle: string, Movieyear : integer Starname : string ) MovieExec ( name: string, address : string cert# : integer netWorth : integer ) Studio ( name: string, address : string pressC# : integer )

13. 2.2.9 Exercises for Section 2.2 Next example is for exercise

14. Two relations of Banking database acctNoTypeBalance 12345Savings12000 23456Checking1000 34567Saving25 firstNameLastNameId noAccount RobbieBanks901-22212345 LennaHand 805-33312345 LennaHand 805-33323456 The relations accounts The relations customers Figure 2.6 Two relations of banking customers

15. 2.3 Defining a Relation Schema in SQL 2.3.1 Relations in SQL 2.3.2 Data Types 2.3.3 Simple Table Declarations 2.3.4 Modifying Relation Schemas 2.3.5 Default Values 2.3.6 Declaring Keys 2.3.7 Exercises for Section 2.3

16. 2.3.1 Relations in SQL

17. 2.3.2 Data Types

18. 2.3.3 Simple Table Declarations

19. Example CREATE TABLE Movie ( title VARCHAR(255), year INTEGER, length INTEGER, inColor CHAR(1), studioName CHAR(50), producerC# INTEGER, ); Figure 2.7 : SQL declaration of the table Movies

20. Example 2 : Moviestar CREATE TABLE MOVIESTAR ( NAME CHAR(30), ADDRESS VARCHAR2(50), GENDER CHAR(6), BIRTHDATE DATE ); Figure 2.8 Declaring the relation schema for the Moviestar relation

21. 2.3.4 Modifying Relation Schemas CREATE TABLE MOVIEEXEC (NAME CHAR(30) NOT NULL, ADDRESS VARCHAR2(50) NOT NULL, CERT# VARCHAR2(10) NOT NULL, NETWORTH NUMBER(15) NOT NULL );

22. 2.3.4 Modifying Relation Schemas REMARK we're going to add a Foreign Key In MOVIEEXEC Table ALTER TABLE MovieExec ADD FOREIGN KEY (Cert#) REFERENCES Movie(ProducerC#);

23. 2.3.5 Default Values

24. Example 2.5 We consider Example 2.3. To use the default character ? As the default for an unknown gender.\ Earliest possible date for Unknown Birthdate. DATE ‘0000-00-00’ –Gender CHAR(1) DEFAULT ‘?’, –Birthdate DATE DEFAULT DATE ‘0000-00-00’,

25. Another Example We could have declared the default value for new attribute phone to be ‘listed’ when we added this attribute, ALTER TABLE MovieStar ADD phone CHAR (16) DEFAULT ‘ unlisted’;

26. 2.3.6 Declaring Keys

27. Example 2.6 Schema MovieStar No star would use the name of another star, we shall assume the name itself forms a key for this relation. Then we can declare name as PRIMARY KEY. CREATE TABLE MovieStar ( name CHAR (30) Primary Key, address VARCHAR (255), gender CHAR(1), birthdate DATE );

28. Alternative way We can use separate definition of key. Unique can replace Primary Key CREATE TABLE MOVIESTAR ( name CHAR(30), address VARCHAR2(255), gender CHAR(1), birthdate DATE, PRIMARY KEY (name) ); Figure 2.10Separate declaration of the key

29. Example 2.7 The Relation Movie, whose key is the pair of attributes ‘title and year’ must be declared like this CREATE TABLE Movies( title CHAR(100), yearINTEGER, lengthINTEGER, genreCHAR(10), studiNameCHAR(30), producerC#INTEGER, PRIMARY KEY (title,year) );

31. 2.3.7 Exercises for Section 2.3

32. 2.4 An Algebraic Query Language 2.4.1 Why Do We Need a Special Query Language? 2.4.2 What is an Algebra? 2.4.3 Overview of Relational Algebra 2.4.4 Set Operations on Relations 2.4.5 Projection 2.4.6 Selection 2.4.7 Cartesian Product 2.4.8 Natural Joins 2.4.9 Theta-Joins 2.4.10 Combining Operations to Form Queries 2.4.11 Naming and Renaming 2.4.12 Relationships Among Operations 2.4.13 A Linear Notation for Algebraic Expressions 2.4.14 Exercises for Section 2.4

33. 2.4.1 Why Do We Need a Special Query Language?

34. 2.4.2 What is an Algebra?

35. 2.4.3 Overview of Relational Algebra

36. 2.4.4 Set Operations on Relations

37. NameAddressGenderBirthdate Carrie Fisher123 Maple st., HollywoodF9/9/99 Mark hamill456 Oak road., BrentwoodM8/8/88 Relation R NameAddressGenderBirthdate Carrie Fisher123 Maple st., HollywoodF9/9/99 Harrison Ford789 Palm Dr., Beverly HillsM7/7/77 Relation S Figure 2.12 Two Relations

38. Example 2.8 Relation R and S UNION (R S) is Note: the two tuples for Carrie Fisher from two relations appear only once in result NameAddressGenderBirthdate Carrie Fisher123 Maple st., HollywoodF9/9/99 Mark Hamill456 oak Rd., BrentwoodM8/8/88 Harrison Ford789 Palm Dr., Beverly HillsM7/7/77

39. The Intersection (R S) Now, Only the Carrie Fisher tuple appears, because only it is in both relations. The Difference is R-S is Fisher and Hamill tuples appear in R and thus are candidates for R-S. thus Fisher appear in S. so is not R-S. NameAddressGenderBirthdate Carrie Fisher123 Maple st., Hollywood F9/9/99 NameAddressGenderBirthdate Mark Hamill 456 oak Rd., Brentwood M8/8/88

40. 2.4.5 Projection

41. Projection TitleYearLengthGenreStudionameproducerC# Star Wars1977124SciFiFox12345 Galaxy1999104ComedyDreamWorks67890 Wayne’s World 199295ComedyParamount99999 Figure 2.13 the Relation Movies

42. Example 2.9 TitleYearLength Star Wars1977124 Galaxy Quest1999104 Wayne’s World199295 ∏ Title,year,length (Movies) ∏ genre (Movies) Genre SciFi Comedy

43. 2.4.6 Selection

44. Example 2.10 The relation Movies be as in Fig 2.13. then the value of expression length >= 100(Movie) is TitleYearLengthGenreStudioNameproducerC# Star Wars1977124SciFiFox12345 Galaxy1999104ComedyDreamWorks67890

45. Example 2.11 Set tuples in the relation movies that represent Fox Movies atleast 100 minutes long. You can use AND for more than one condition. Length >= 100 AND studioName = ‘Fox’ (Movies) Is the only one in the resulting relation. TitleYearLengthGenreStudioNameproducerC# Star Wars1977124SciFiFox12345

46. 2.4.7 Cartesian Product

47. 2.4.8 Natural Joins

48. AB 12 34 BCD 256 478 91011 Relation R Relation S Relation R X S AR.BS.BCD 12256 12478 1291011 34256 34478 3491011

49. Example 2.13 ABCD 1256 3478

50. 2.4.9 Theta-Joins

51. ABC 123 678 978 BCD 234 235 7810 Relation U (a) Relation V (b) Result U V ABCD 1234 1235 67810 978 Figure 2.16 Natural join of relations

52. Example 2.15 Consider all nine pairs of tuples, one from each relation. Whether A component from U-tuple is less than the D Component of the V-tuple. AU.BU.CV.BV.CD 123234 123235 1237810 67878 97878 Figure 2.17 Result of U theta Join A < D V

53. Example 2.16 U and V that has more complex condition : U A < D AND (U.B != V.B) V We require for successful pairing not only that the A component of U-tuple be less than D component of the V-tuple, but that the two tuples disagree on their respective B components is the only one to satisfy both conditions, so this relation is the result of the theta-join. AU.BU.CV.BV.CD 1237810

54. 2.4.10 Combining Operations to Form Queries

55. ∏ Title,year (σ length >=100 (Movies) ∩ σ StudioName =‘Fox’ (Movies) Represents the same expression ∩ ∏ Title,year σ length >=100 σ StudioName =‘Fox’

56. 2.4.11 Naming and Renaming

57. Example 2.18 ABXCD 12256 12478 1291011 34256 34478 3491011 Figure 2.19 R X ρ s (X,C,D) (S)

58. 2.4.12 Relationships Among Operations

59. 2.4.13 A Linear Notation for Algebraic Expressions

60. 2.4.14 Exercises for Section 2.4

61. 2.5 Constraints on Relations 2.5.1 Relational Algebra as a Constraint Language 2.5.2 Referential Integrity Constraints 2.5.3 Key Constraints 2.5.4 Additional Constraint Examples 2.5.5 Exercises for Section 2.5 2.6 Summary of Chapter 2 2.7 References for Chapter 2

62. 2.5.1 Relational Algebra as a Constraint Language

63. 2.5.2 Referential Integrity Constraints

64. Example 2.21 Consider the two relations from our running movie database: Movie(title,year,length,genre,studioName, producerC#) MovieExec(name,address,cert#,netWorth) ∏ producerC# (Movies) ⊆ ∏ cert# (MocvieExec)

65. Example 2.22 StarsIn(movietitle, movieYear,starName) Movie(title,year,length,studioName, producerC#) ∏ movieTitle, movieYear (StarsIn) ⊆ ∏ title,year (Movies)

66. 2.5.3 Key Constraints

67. Example 2.23 Recall that name is the key for relation MovieStar(name,address,gender,birthdate)

68. 2.5.4 Additional Constraint Examples

69. Example 2.5.3 Recall the name of the Key for relation MovieStar(Name,address,gender,birthdate) The requirement can be expressed by the algebraic expression σ MS1.name = MS2.name AND MS1.address ≠ MS2.address (MS1 x MS2) = ∅ MS1 in the product MS1 x MS2 is shorthand for the remaining ρ MS1(name,address,gender,birthdate) (MovieStar)

70. Example 2.24

71. The only legal value for Gender attribute is ‘F’ and ‘M’. We can express the gender attribute of MovieStar alegrabically by: σ Mgender ≠‘F’ AND gender ≠‘M’ (MovieStar) = ∅

72. Example 2.25 If one must have networth of at least $100,000,000 to be president of movie studio. We can define this algebraically but first we have to perform theta-join on this two relations. –MovieExec(name,address,cert#,networth) –Studio(name,address, presC#)

73. We can express this constraint as : σ networth < 100000000 (Studio ⋈ presC# = cert# MovieExec) ∅ Alternative way to express the same constraints is to compare the set of certificates that represent studio president with the set of certificates that represents the networth of atleast $100000000; Former must be the subset of the latter. ∏ TpressC# (Studio) ⊆ ∏ cert# (σ networth < 100000000 (MovieExec))

74. 2.5.5 Exercises for Section 2.5

75. 2.6 Summary of Chapter 2

76. 2.7 References for Chapter 2

77. Chapter 3 Design Theory for Relational Databases

78. 3.1 Functional Dependencies 3.1.1 Definition of Functional Dependency 3.1.2 Keys of Relations 3.1.3 Superkeys 3.1.4 Exercises for Section 3.1

79. 3.1.1 Definition of Functional Dependency

80. 3.1.2 Keys of Relations

81. 3.1.3 Superkeys

82. 3.1.4 Exercises for Section 3.1

83. 3.2 Rules About Functional Dependencies 3.2.1 Reasoning About Functional Dependencies 3.2.2 The Splitting/Combining Rule 3.2.3 Trivial Functional Dependencies 3.2.4 Computing the Closure of Attributes 3.2.5 Why the Closure Algorithm Works 3.2.6 The Transitive Rule 3.2.7 Closing Sets of Functional Dependencies 3.2.8 Projecting Functional Dependencies 3.2.9 Exercises for Section 3.2

84. 3.2.1 Reasoning About Functional Dependencies

85. 3.2.2 The Splitting/Combining Rule

86. 3.2.3 Trivial Functional Dependencies

87. 3.2.4 Computing the Closure of Attributes

88. 3.2.5 Why the Closure Algorithm Works

89. 3.2.6 The Transitive Rule

90. 3.2.7 Closing Sets of Functional Dependencies

91. 3.2.8 Projecting Functional Dependencies

92. 3.2.9 Exercises for Section 3.2

93. 3.3 Design of Relational Database Schemas 3.3.1 Anomalies 3.3.2 Decomposing Relations 3.3.3 Boyce-Codd Normal Form 3.3.4 Decomposition into BCNF 3.3.5 Exercises for Section 3.3

94. 3.3.1 Anomalies

95. 3.3.2 Decomposing Relations

96. 3.3.3 Boyce-Codd Normal Form

97. 3.3.4 Decomposition into BCNF

98. 3.3.5 Exercises for Section 3.3

99. 3.4 Decomposition: The Good, Bad, and Ugly 3.4.1 Recovering Information from a Decomposition 3.4.2 The Chase Test for Lossless Join 3.4.3 Why the Chase Works 3.4.4 Dependency Preservation 3.4.5 Exercises for Section 3.4

100. 3.4.1 Recovering Information from a Decomposition

101. 3.4.2 The Chase Test for Lossless Join

102. 3.4.3 Why the Chase Works

103. 3.4.4 Dependency Preservation

104. 3.4.5 Exercises for Section 3.4

105. 3.5 Third Normal Form 3.5.1 Definition of Third Normal Form 3.5.2 The Synthesis Algorithm for 3NF Schemas 3.5.3 Why the 3NF Synthesis Algorithm Works 3.5.4 Exercises for Section 3.5

106. 3.5.1 Definition of Third Normal Form

107. 3.5.2 The Synthesis Algorithm for 3NF Schemas

108. 3.5.3 Why the 3NF Synthesis Algorithm Works

109. 3.5.4 Exercises for Section 3.5

110. 3.6 Multivalued Dependencies 3.6.1 Attribute Independence and Its Consequent Redundancy 3.6.2 Definition of Multivalued Dependencies 3.6.3 Reasoning About Multivalued Dependencies 3.6.4 Fourth Normal Form 3.6.5 Decomposition into Fourth Normal Form 3.6.6 Relationships Among Normal Forms 3.6.7 Exercises for Section 3.6

111. 3.6.1 Attribute Independence and Its Consequent Redundancy

112. 3.6.2 Definition of Multivalued Dependencies

113. 3.6.3 Reasoning About Multivalued Dependencies

114. 3.6.4 Fourth Normal Form

115. 3.6.5 Decomposition into Fourth Normal Form

116. 3.6.6 Relationships Among Normal Forms

117. 3.6.7 Exercises for Section 3.6

118. 3.7 An Algorithm for Discovering MVD's 3.7.1 The Closure and the Chase 3.7.2 Extending the Chase to MVD's 3.7.3 Why the Chase Works for MVD's 3.7.4 Projecting MVD's 3.7.5 Exercises for Section 3.7 3.8 Summary of Chapter 3 3.9 References for Chapter 3

119. 3.7.1 The Closure and the Chase

120. 3.7.2 Extending the Chase to MVD's

121. 3.7.3 Why the Chase Works for MVD's

122. 3.7.4 Projecting MVD's

123. 3.7.5 Exercises for Section 3.7

124. 3.8 Summary of Chapter 3

125. 3.9 References for Chapter 3

126. Chapter 4 High-Level Database Models

127. 4.1 The Entity/Relationship Model 4.1.1 Entity Sets 4.1.2 Attributes 4.1.3 Relationships 4.1.4 Entity-Relationship Diagrams 4.1.5 Instances of an E/R Diagram 4.1.6 Multiplicity of Binary E/R Relationships 4.1.7 Multiway Relationships 4.1.8 Roles in Relationships 4.1.9 Attributes on Relationships 4.1.10 Converting Multiway Relationships to Binary 4.1.11 Subclasses in the E/R Model 4.1.12 Exercises for Section 4.1

128. 4.1.1 Entity Sets

129. 4.1.2 Attributes

130. 4.1.3 Relationships

131. 4.1.4 Entity-Relationship Diagrams

132. 4.1.5 Instances of an E/R Diagram

133. 4.1.6 Multiplicity of Binary E/R Relationships

134. 4.1.7 Multiway Relationships

135. 4.1.8 Roles in Relationships

136. 4.1.9 Attributes on Relationships

137. 4.1.10 Converting Multiway Relationships to Binary

138. 4.1.11 Subclasses in the E/R Model

139. 4.1.12 Exercises for Section 4.1

140. 4.2 Design Principles 4.2.1 Faithfulness 4.2.2 Avoiding Redundancy 4.2.3 Simplicity Counts 4.2.4 Choosing the Right Relationships 4.2.5 Picking the Right Kind of Element 4.2.6 Exercises for Section 4.2

141. 4.2.1 Faithfulness

142. 4.2.2 Avoiding Redundancy

143. 4.2.3 Simplicity Counts

144. 4.2.4 Choosing the Right Relationships

145. 4.2.5 Picking the Right Kind of Element

146. 4.2.6 Exercises for Section 4.2

147. 4.3 Constraints in the E/R Model 4.3.1 Keys in the E/R Model 4.3.2 Representing Keys in the E/R Model 4.3.3 Referential Integrity 4.3.4 Degree Constraints 4.3.5 Exercises for Section 4.3

148. 4.3.1 Keys in the E/R Model

149. 4.3.2 Representing Keys in the E/R Model

150. 4.3.3 Referential Integrity

151. 4.3.4 Degree Constraints

152. 4.3.5 Exercises for Section 4.3

153. 4.4 Weak Entity Sets 4.4.1 Causes of Weak Entity Sets 4.4.2 Requirements for Weak Entity Sets 4.4.3 Weak Entity Set Notation 4.4.4 Exercises for Section 4.4

154. 4.4.1 Causes of Weak Entity Sets

155. 4.4.2 Requirements for Weak Entity Sets

156. 4.4.3 Weak Entity Set Notation

157. 4.4.4 Exercises for Section 4.4

158. 4.5 From E/R Diagrams to Relational Designs 4.5.1 From Entity Sets to Relations 4.5.2 From E/R Relationships to Relations 4.5.3 Combining Relations 4.5.4 Handling Weak Entity Sets 4.5.5 Exercises for Section 4.5

159. 4.5.1 From Entity Sets to Relations

160. 4.5.2 From E/R Relationships to Relations

161. 4.5.3 Combining Relations

162. 4.5.4 Handling Weak Entity Sets

163. 4.5.5 Exercises for Section 4.5

164. 4.6 Converting Subclass Structures to Relations 4.6.1 E/R-Style Conversion 4.6.2 An Object-Oriented Approach 4.6.3 Using Null Values to Combine Relations 4.6.4 Comparison of Approaches 4.6.5 Exercises for Section 4.6

165. 4.6.1 E/R-Style Conversion

166. 4.6.2 An Object-Oriented Approach

167. 4.6.3 Using Null Values to Combine Relations

168. 4.6.4 Comparison of Approaches

169. 4.6.5 Exercises for Section 4.6

170. 4.7 Unified Modeling Language 4.7.1 UML Classes 4.7.2 Keys for UML classes 4.7.3 Associations 4.7.4 Self-Associations 4.7.5 Association Classes 4.7.6 Subclasses in UML 4.7.7 Aggregations and Compositions 4.7.8 Exercises for Section 4.7

171. 4.7.1 UML Classes

172. 4.7.2 Keys for UML classes

173. 4.7.3 Associations

174. 4.7.4 Self-Associations

175. 4.7.5 Association Classes

176. 4.7.6 Subclasses in UML

177. 4.7.7 Aggregations and Compositions

178. 4.7.8 Exercises for Section 4.7

179. 4.8 From UML Diagrams to Relations 4.8.1 UML-to-Relations Basics 4.8.2 From UML Subclasses to Relations 4.8.3 From Aggregations and Compositions to Relations 4.8.4 The UML Analog of Weak Entity Sets 4.8.5 Exercises for Section 4.8

180. 4.8.1 UML-to-Relations Basics

181. 4.8.2 From UML Subclasses to Relations

182. 4.8.3 From Aggregations and Compositions to Relations

183. 4.8.4 The UML Analog of Weak Entity Sets

184. 4.8.5 Exercises for Section 4.8

185. 4.9 Object Definition Language 4.9.1 Class Declarations 4.9.2 Attributes in ODL 4.9.3 Relationships in ODL 4.9.4 Inverse Relationships 4.9.5 Multiplicity of Relationships 4.9.6 Types in ODL 4.9.7 Subclasses in ODL 4.9.8 Declaring Keys in ODL 4.9.9 Exercises for Section 4.9

186. 4.9.1 Class Declarations

187. 4.9.2 Attributes in ODL

188. 4.9.3 Relationships in ODL

189. 4.9.4 Inverse Relationships

190. 4.9.5 Multiplicity of Relationships

191. 4.9.6 Types in ODL

192. 4.9.7 Subclasses in ODL

193. 4.9.8 Declaring Keys in ODL

194. 4.9.9 Exercises for Section 4.9

195. 4.10 From ODL Designs to Relational Designs 4.10.1 From ODL Classes to Relations 4.10.2 Complex Attributes in Classes 4.10.3 Representing Set-Valued Attributes 4.10.4 Representing Other Type Constructors 4.10.5 Representing ODL Relationships 4.10.6 Exercises for Section 4.10 4.11 Summary of Chapter 4 4.12 References for Chapter 4

196. 4.10.1 From ODL Classes to Relations

197. 4.10.2 Complex Attributes in Classes

198. 4.10.3 Representing Set-Valued Attributes

199. 4.10.4 Representing Other Type Constructors

200. 4.10.5 Representing ODL Relationships

201. 4.10.6 Exercises for Section 4.10

202. 4.11 Summary of Chapter 4

203. 4.12 References for Chapter 4