Modern Database Management - Jeffrey A. Hoffer, Mary B. Prescott

3. Chapter 1: The Database Environment Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

6. Figure 1-1a Data in context Context helps users understand data

7. Graphical displays turn data into useful information that managers can use for decision making and interpretation Figure 1-1b Summarized data

8. Descriptions of the properties or characteristics of the data, including data types, field sizes, allowable values, and data context

11. Figure 1-3 Old file processing systems at Pine Valley Furniture Company Duplicate Data

18. Segment of an Enterprise Data Model Segment of a Project-Level Data Model

19. One customer may place many orders, but each order is placed by a single customer  One-to-many relationship

20. One order has many order lines; each order line is associated with a single order  One-to-many relationship

21. One product can be in many order lines, each order line refers to a single product  One-to-many relationship

22. Therefore, one order involves many products and one product is involved in many orders  Many-to-many relationship

23. Figure 1-4 Enterprise data model for Figure 1-3 segments

24. Figure 1-5 Components of the Database Environment

28. Figure 1-6 Typical data from a personal database

29. Figure 1-7 Workgroup database with wireless local area network

31. Figure 1-8 An enterprise data warehouse

32. Evolution of DB Systems

33. Chapter 2: The Database Development Process Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

36. Figure 2-1 Segment from enterprise data model Enterprise data model describes the high-level entities in an organization and the relationship between these entities

43. Figure 2-2 Example of process decomposition of an order fulfillment function (Pine Valley Furniture) Decomposition = breaking large tasks into smaller tasks in a hierarchical structure chart

45. Example business function-to-data entity matrix (Fig. 2-3)

47. Systems Development Life Cycle (see also Figures 2.4, 2.5) Planning Analysis Physical Design Implementation Maintenance Logical Design

48. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Planning Purpose – preliminary understanding Deliverable – request for study Database activity – enterprise modeling and early conceptual data modeling Planning Analysis Physical Design Implementation Maintenance Logical Design

49. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Analysis Purpose–thorough requirements analysis and structuring Deliverable–functional system specifications Database activity–Thorough and integrated conceptual data modeling Planning Analysis Physical Design Implementation Maintenance Logical Design

50. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Logical Design Purpose–information requirements elicitation and structure Deliverable–detailed design specifications Database activity– logical database design (transactions, forms, displays, views, data integrity and security) Planning Analysis Physical Design Implementation Maintenance Logical Design

51. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Physical Design Purpose–develop technology and organizational specifications Deliverable–program/data structures, technology purchases, organization redesigns Database activity– physical database design (define database to DBMS, physical data organization, database processing programs) Planning Analysis Physical Design Implementation Maintenance Logical Design

52. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Implementation Purpose–programming, testing, training, installation, documenting Deliverable–operational programs, documentation, training materials Database activity– database implementation, including coded programs, documentation, installation and conversion Planning Analysis Physical Design Implementation Maintenance Logical Design

53. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Maintenance Purpose–monitor, repair, enhance Deliverable–periodic audits Database activity– database maintenance, performance analysis and tuning, error corrections Planning Analysis Physical Design Implementation Maintenance Logical Design

54. Prototyping Database Methodology (Figure 2.6)

55. Prototyping Database Methodology (Figure 2.6) (cont.)

56. Prototyping Database Methodology (Figure 2.6) (cont.)

57. Prototyping Database Methodology (Figure 2.6) (cont.)

58. Prototyping Database Methodology (Figure 2.6) (cont.)

64. Different people have different views of the database…these are the external schema The internal schema is the underlying design and implementation Figure 2-7 Three-schema architecture

65. Figure 2-8 Developing the three-tiered architecture

66. Figure 2-9 Three-tiered client/server database architecture

67. Pine Valley Furniture Segment of project data model (Figure 2-11)

68. Figure 2-12 Four relations (Pine Valley Furniture)

69. Figure 2-12 Four relations (Pine Valley Furniture) (cont.)

70. Chapter 3: Modeling Data in the Organization Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

77. Sample E-R Diagram (Figure 3-1)

78. Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity type is allowed Basic E-R notation (Figure 3-2) Entity symbols A special entity that is also a relationship Relationship symbols Attribute symbols

80. Inappropriate entities Figure 3-4 Example of inappropriate entities System user System output Appropriate entities

84. Figure 3-7 A composite attribute An attribute broken into component parts Figure 3-8 Entity with multivalued attribute (Skill) and derived attribute (Years_Employed) Multivalued an employee can have more than one skill Derived from date employed and current date

85. Figure 3-9 Simple and composite identifier attributes The identifier is boldfaced and underlined

86. Figure 3-19 Simple example of time-stamping This attribute that is both multivalued and composite

88. Figure 3-10 Relationship types and instances a) Relationship type b) Relationship instances

90. Degree of relationships – from Figure 3-2 Entities of two different types related to each other Entities of three different types related to each other One entity related to another of the same entity type

93. Figure 3-12 Examples of relationships of different degrees a) Unary relationships

94. Figure 3-12 Examples of relationships of different degrees (cont.) b) Binary relationships

95. Figure 3-12 Examples of relationships of different degrees (cont.) c) Ternary relationship Note: a relationship can have attributes of its own

96. Figure 3-17 Examples of cardinality constraints a) Mandatory cardinalities A patient must have recorded at least one history, and can have many A patient history is recorded for one and only one patient

97. Figure 3-17 Examples of cardinality constraints (cont.) b) One optional, one mandatory An employee can be assigned to any number of projects, or may not be assigned to any at all A project must be assigned to at least one employee, and may be assigned to many

98. Figure 3-17 Examples of cardinality constraints (cont.) a) Optional cardinalities A person is is married to at most one other person, or may not be married at all

99. Entities can be related to one another in more than one way Figure 3-21 Examples of multiple relationships a) Employees and departments

100. Figure 3-21 Examples of multiple relationships (cont.) b) Professors and courses (fixed lower limit constraint) Here, min cardinality constraint is 2

101. Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships simple composite

103. Strong entity Weak entity Identifying relationship

105. Figure 3-11a A binary relationship with an attribute Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship

106. Figure 3-11b An associative entity (CERTIFICATE) Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right. Note that the many-to-many cardinality between entities in Figure 3-11a has been replaced by two one-to-many relationships with the associative entity.

107. Figure 3-13c An associative entity – bill of materials structure This could just be a relationship with attributes…it’s a judgment call

108. Figure 3-18 Ternary relationship as an associative entity

109. Microsoft Visio Example for E-R diagram Different modeling software tools may have different notation for the same constructs

110. Chapter 4: The Enhanced ER Model and Business Rules Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

113. Figure 4-1 Basic notation for supertype/subtype notation a) EER notation

114. Different modeling tools may have different notation for the same modeling constructs b) Microsoft Visio Notation Figure 4-1 Basic notation for supertype/subtype notation (cont.)

115. Figure 4-2 Employee supertype with three subtypes All employee subtypes will have emp nbr, name, address, and date-hired Each employee subtype will also have its own attributes

117. Figure 4-3 Supertype/subtype relationships in a hospital Both outpatients and resident patients are cared for by a responsible physician Only resident patients are assigned to a bed

119. Figure 4-4 Example of generalization a) Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have common attributes

120. Figure 4-4 Example of generalization (cont.) So we put the shared attributes in a supertype Note: no subtype for motorcycle, since it has no unique attributes b) Generalization to VEHICLE supertype

121. Figure 4-5 Example of specialization a) Entity type PART Only applies to manufactured parts Applies only to purchased parts

122. b) Specialization to MANUFACTURED PART and PURCHASED PART Created 2 subtypes Figure 4-5 Example of specialization (cont.) Note: multivalued attribute was replaced by an associative entity relationship to another entity

124. Figure 4-6 Examples of completeness constraints a) Total specialization rule A patient must be either an outpatient or a resident patient

125. b) Partial specialization rule Figure 4-6 Examples of completeness constraints (cont.) A vehicle could be a car, a truck, or neither

127. a) Disjoint rule Figure 4-7 Examples of disjointness constraints A patient can either be outpatient or resident, but not both

128. b) Overlap rule Figure 4-7 Examples of disjointness constraints (cont.) A part may be both purchased and manufactured

130. Figure 4-8 Introducing a subtype discriminator ( disjoint rule) A simple attribute with different possible values indicating the subtype

131. Figure 4-9 Subtype discriminator ( overlap rule) A composite attribute with sub-attributes indicating “yes” or “no” to determine whether it is of each subtype

132. Figure 4-10 Example of supertype/subtype hierarchy

134. Figure 4-13a Possible entity clusters for Pine Valley Furniture in Microsoft Visio Related groups of entities could become clusters

135. Figure 4-13b EER diagram of PVF entity clusters More readable, isn’t it?

136. Figure 4-14 Manufacturing entity cluster Detail for a single cluster

137. Chapter 4: The Enhanced ER Model and Business Rules Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

140. Figure 4-1 Basic notation for supertype/subtype notation a) EER notation

141. Different modeling tools may have different notation for the same modeling constructs b) Microsoft Visio Notation Figure 4-1 Basic notation for supertype/subtype notation (cont.)

142. Figure 4-2 Employee supertype with three subtypes All employee subtypes will have emp nbr, name, address, and date-hired Each employee subtype will also have its own attributes

144. Figure 4-3 Supertype/subtype relationships in a hospital Both outpatients and resident patients are cared for by a responsible physician Only resident patients are assigned to a bed

146. Figure 4-4 Example of generalization a) Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have common attributes

147. Figure 4-4 Example of generalization (cont.) So we put the shared attributes in a supertype Note: no subtype for motorcycle, since it has no unique attributes b) Generalization to VEHICLE supertype

148. Figure 4-5 Example of specialization a) Entity type PART Only applies to manufactured parts Applies only to purchased parts

149. b) Specialization to MANUFACTURED PART and PURCHASED PART Created 2 subtypes Figure 4-5 Example of specialization (cont.) Note: multivalued attribute was replaced by an associative entity relationship to another entity

151. Figure 4-6 Examples of completeness constraints a) Total specialization rule A patient must be either an outpatient or a resident patient

152. b) Partial specialization rule Figure 4-6 Examples of completeness constraints (cont.) A vehicle could be a car, a truck, or neither

154. a) Disjoint rule Figure 4-7 Examples of disjointness constraints A patient can either be outpatient or resident, but not both

155. b) Overlap rule Figure 4-7 Examples of disjointness constraints (cont.) A part may be both purchased and manufactured

157. Figure 4-8 Introducing a subtype discriminator ( disjoint rule) A simple attribute with different possible values indicating the subtype

158. Figure 4-9 Subtype discriminator ( overlap rule) A composite attribute with sub-attributes indicating “yes” or “no” to determine whether it is of each subtype

159. Figure 4-10 Example of supertype/subtype hierarchy

161. Figure 4-13a Possible entity clusters for Pine Valley Furniture in Microsoft Visio Related groups of entities could become clusters

162. Figure 4-13b EER diagram of PVF entity clusters More readable, isn’t it?

163. Figure 4-14 Manufacturing entity cluster Detail for a single cluster

164. Packaged data models provide generic models that can be customized for a particular organization’s business rules

166. Figure 4-18 EER diagram to describe business rules

169. Figure 4-19 Data model segment for class scheduling

170. Figure 4-20 Business Rule 1: For a faculty member to be assigned to teach a section of a course, the faculty member must be qualified to teach the course for which that section is scheduled Action assertion Anchor object Corresponding object Corresponding object In this case, the action assertion is a R estriction

171. Figure 4-21 Business Rule 2: For a faculty member to be assigned to teach a section of a course, the faculty member must not be assigned to teach a total of more than three course sections Action assertion Anchor object Corresponding object In this case, the action assertion is an U pper LIM it

172. Chapter 5: Logical Database Design and the Relational Model Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

177. Figure 5-3 Schema for four relations (Pine Valley Furniture Company) Primary Key Foreign Key (implements 1:N relationship between customer and order) Combined, these are a composite primary key (uniquely identifies the order line)…individually they are foreign keys (implement M:N relationship between order and product)

179. Domain definitions enforce domain integrity constraints

181. Figure 5-5 Referential integrity constraints (Pine Valley Furniture) Referential integrity constraints are drawn via arrows from dependent to parent table

182. Figure 5-6 SQL table definitions Referential integrity constraints are implemented with foreign key to primary key references

184. (a) CUSTOMER entity type with simple attributes Figure 5-8 Mapping a regular entity (b) CUSTOMER relation

185. (a) CUSTOMER entity type with composite attribute Figure 5-9 Mapping a composite attribute (b) CUSTOMER relation with address detail

186. Figure 5-10 Mapping an entity with a multivalued attribute One–to–many relationship between original entity and new relation (a) Multivalued attribute becomes a separate relation with foreign key (b)

188. Figure 5-11 Example of mapping a weak entity a) Weak entity DEPENDENT

189. NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity Foreign key Figure 5-11 Example of mapping a weak entity (cont.) b) Relations resulting from weak entity Composite primary key

191. Figure 5-12 Example of mapping a 1:M relationship a) Relationship between customers and orders Note the mandatory one Again, no null value in the foreign key…this is because of the mandatory minimum cardinality Foreign key b) Mapping the relationship

192. Figure 5-13 Example of mapping an M:N relationship a) Completes relationship (M:N) The Completes relationship will need to become a separate relation

193. New intersection relation Figure 5-13 Example of mapping an M:N relationship (cont.) b) Three resulting relations Foreign key Foreign key Composite primary key

194. Figure 5-14 Example of mapping a binary 1:1 relationship a) In_charge relationship (1:1) Often in 1:1 relationships, one direction is optional.

195. b) Resulting relations Figure 5-14 Example of mapping a binary 1:1 relationship (cont.) Foreign key goes in the relation on the optional side, Matching the primary key on the mandatory side

197. Figure 5-15 Example of mapping an associative entity a) An associative entity

198. Figure 5-15 Example of mapping an associative entity (cont.) b) Three resulting relations Composite primary key formed from the two foreign keys

199. Figure 5-16 Example of mapping an associative entity with an identifier a) SHIPMENT associative entity

200. Figure 5-16 Example of mapping an associative entity with an identifier (cont.) b) Three resulting relations Primary key differs from foreign keys

202. Figure 5-17 Mapping a unary 1:N relationship (a) EMPLOYEE entity with unary relationship (b) EMPLOYEE relation with recursive foreign key

203. Figure 5-18 Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations

205. Figure 5-19 Mapping a ternary relationship a) PATIENT TREATMENT Ternary relationship with associative entity

206. b) Mapping the ternary relationship PATIENT TREATMENT Remember that the primary key MUST be unique Figure 5-19 Mapping a ternary relationship (cont.) This is why treatment date and time are included in the composite primary key But this makes a very cumbersome key… It would be better to create a surrogate key like Treatment#

208. Figure 5-20 Supertype/subtype relationships

209. Figure 5-21 Mapping Supertype/subtype relationships to relations These are implemented as one-to-one relationships

212. Example–Figure 5-2b Question–Is this a relation? Answer–Yes: Unique rows and no multivalued attributes Question–What’s the primary key? Answer–Composite: Emp_ID, Course_Title

215. Figure 5.22 Steps in normalization

217. Table with multivalued attributes, not in 1 st normal form Note: this is NOT a relation

218. Table with no multivalued attributes and unique rows, in 1 st normal form Note: this is relation, but not a well-structured one

221. Order_ID  Order_Date, Customer_ID, Customer_Name, Customer_Address Therefore, NOT in 2 nd Normal Form Customer_ID  Customer_Name, Customer_Address Product_ID  Product_Description, Product_Finish, Unit_Price Order_ID, Product_ID  Order_Quantity Figure 5-27 Functional dependency diagram for INVOICE

222. Partial dependencies are removed, but there are still transitive dependencies Getting it into Second Normal Form Figure 5-28 Removing partial dependencies

224. Transitive dependencies are removed Figure 5-28 Removing partial dependencies Getting it into Third Normal Form

227. Figure 5-31 Enterprise keys a) Relations with enterprise key b) Sample data with enterprise key

228. Chapter 6: Physical Database Design and Performance Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

232. Figure 6-1 Composite usage map (Pine Valley Furniture Company)

233. Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Data volumes

234. Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Access Frequencies (per hour)

235. Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Usage analysis: 140 purchased parts accessed per hour  80 quotations accessed from these 140 purchased part accesses  70 suppliers accessed from these 80 quotation accesses

236. Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Usage analysis: 75 suppliers accessed per hour  40 quotations accessed from these 75 supplier accesses  40 purchased parts accessed from these 40 quotation accesses

239. Figure 6-2 Example code look-up table (Pine Valley Furniture Company) Code saves space, but costs an additional lookup to obtain actual value

244. Figure 6-3 A possible denormalization situation: two entities with one-to-one relationship

245. Figure 6-4 A possible denormalization situation: a many-to-many relationship with nonkey attributes Extra table access required Null description possible

246. Figure 6-5 A possible denormalization situation: reference data Extra table access required Data duplication

251. Figure 6-4 Physical file terminology in an Oracle environment

253. Figure 6-7a Sequential file organization If not sorted Average time to find desired record = n/2 1 2 n Records of the file are stored in sequence by the primary key field values If sorted – every insert or delete requires resort

255. Figure 6-7b B-tree index uses a tree search Average time to find desired record = depth of the tree Leaves of the tree are all at same level  consistent access time

256. Figure 6-7c Hashed file or index organization Hash algorithm Usually uses division-remainder to determine record position. Records with same position are grouped in lists

257. Figure 6-8 Bitmap index index organization Bitmap saves on space requirements Rows - possible values of the attribute Columns - table rows Bit indicates whether the attribute of a row has the values

258. Figure 6-9 Join Indexes–speeds up join operations

266. Database Architectures (Figure 6-11) Legacy Systems Current Technology Data Warehouses

267. Chapter 7: Introduction to SQL Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

274. Figure 7-1 A simplified schematic of a typical SQL environment, as described by the SQL-2003 standard

275. Some SQL Data types

276. Figure 7-4 DDL, DML, DCL, and the database development process

279. The following slides create tables for this enterprise data model

280. Figure 7-6 SQL database definition commands for Pine Valley Furniture Overall table definitions

281. Defining attributes and their data types

282. Non-nullable specification Identifying primary key Primary keys can never have NULL values

283. Non-nullable specifications Primary key Some primary keys are composite– composed of multiple attributes

284. Default value Domain constraint Controlling the values in attributes

285. Primary key of parent table Identifying foreign keys and establishing relationships Foreign key of dependent table

287. Relational integrity is enforced via the primary-key to foreign-key match Figure 7-7 Ensuring data integrity through updates

294. Merge Statement Makes it easier to update a table…allows combination of Insert and Update in one statement Useful for updating master tables with new data

301. Venn Diagram from Previous Query

309. Chapter 8: Advanced SQL Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall

312. The following slides create tables for this enterprise data model

313. These tables are used in queries that follow Figure 8-1 Pine Valley Furniture Company Customer and Order tables with pointers from customers to their orders

316. Results Unlike INNER join, this will include customer rows with no matching order rows

318. Figure 8-2 Results from a four-table join From CUSTOMER_T table From ORDER_T table From PRODUCT_T table

324. Figure 8-3b Processing a correlated subquery Subquery refers to outer-query data, so executes once for each row of outer query Note: only the orders that involve products with Natural Ash will be included in the final results

329. Figure 8-5 An SQL Transaction sequence (in pseudocode)

334. Figure 8-6 Triggers contrasted with stored procedures Procedures are called explicitly Triggers are event-driven Source : adapted from Mullins, 1995.

335. Figure 8-7 Simplified trigger syntax, SQL:2003 Figure 8-8 Create routine syntax, SQL:2003

337. Chapter 9: The Client/Server Database Environment Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall