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
37.
38.
39.
40.
41.
42.
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
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
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
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
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
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
91.
92.
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
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
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
116.
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
118.
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
123.
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
126.
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
129.
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
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
143.
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
145.
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
150.
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
153.
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
156.
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
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
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)
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
183.
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)
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
190.
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
196.
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
201.
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
204.
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#
209. Figure 5-21 Mapping Supertype/subtype relationships to relations These are implemented as one-to-one relationships
210.
211.
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
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
219.
220.
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
223.
224. Transitive dependencies are removed Figure 5-28 Removing partial dependencies Getting it into Third Normal Form
225.
226.
227. Figure 5-31 Enterprise keys a) Relations with enterprise key b) Sample data with enterprise key
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
237.
238.
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
240.
241.
242.
243.
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
247.
248.
249.
250.
251. Figure 6-4 Physical file terminology in an Oracle environment
252.
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
254.
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
285. Primary key of parent table Identifying foreign keys and establishing relationships Foreign key of dependent table
286.
287. Relational integrity is enforced via the primary-key to foreign-key match Figure 7-7 Ensuring data integrity through updates
288.
289.
290.
291.
292.
293.
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
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
314.
315.
316. Results Unlike INNER join, this will include customer rows with no matching order rows
317.
318. Figure 8-2 Results from a four-table join From CUSTOMER_T table From ORDER_T table From PRODUCT_T table
319.
320.
321.
322.
323.
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
325.
326.
327.
328.
329. Figure 8-5 An SQL Transaction sequence (in pseudocode)
330.
331.
332.
333.
334. Figure 8-6 Triggers contrasted with stored procedures Procedures are called explicitly Triggers are event-driven Source : adapted from Mullins, 1995.