1. 6 Copyright © 2006, Oracle. All rights reserved. Developing Data Models for Business Databases (Part I)

2. 6.1 - 2 Outline Develop ERDs that are consistent with narrative ( 敘事性的 ) problem descriptions Use transformations to generate alternative ERDs for diagram refinement Document design decisions implicit in an ERD Analyze an ERD for common design errors Convert an ERD to a table design using conversion rules

3. 6.1 - 3 Characteristics of Data Modeling Problems Data modeling involves the collection and analysis of business requirements. It results in an ERD to represent the requirements Business requirements are rarely well structured –Conflicting statements ( 衝突的陳述 ) –Wide scope –Missing details ( 遺漏細節 ) –Many users –Requirements in many formats Solution : Add structure –Eliminate irrelevant (conflicting) details –Narrow scope –Add missing details

4. 6.1 - 4 Goals of Narrative Problem Analysis Create an ERD consistency with the narrative ( 敘述 性的 ) description of business requirements Simplicity Preference –Choose simpler designs especially in initial design –For example: An ERD with one entity type is less complex than an ERD with two entity types and a relationship. Add refinements and additional details later

5. 6.1 - 5 Steps of Narrative Problem Analysis 1.Identify entity types and attributes 2.Determine primary keys 3.Add relationships –Determine connections –Determine relationship cardinalities –Simplify relationships

6. 6.1 - 6 Determine Entity Types and Attributes For entity types, find nouns that represent groups of people, places, things, and events –“ Students take courses at the university.” For attributes, look for nouns describing properties that provide details about particular entity types. –“ Courses have a course number, semester, year, and room listed in the catalog.” Simplicity Principle Unless the problem description contains additional details about a noun, you should consider the noun initially as an attribute, rather than an entity type.

7. 6.1 - 7 Determine Primary Keys Ideally, PK should be Stable: – Never change after assigned to an entity Single purpose: –No other purpose other than entity identification Identify other unique attributes (Alternate Keys)

8. 6.1 - 8 Adding Relationships (Identify relationships ) Often appear as verbs connecting nouns –“Students enroll in courses each semester.” Identify relationships connecting previously identified entity types. Focus on : –Sentences that involve associations among nouns representing entity types –Sentences that involve an entity type having a collection of entities of another entity type (An order has a collection of items) –Sentences that involve an entity type having another entity type as a property

9. 6.1 - 9 Adding Relationships (Add cardinality) Add cardinality Maximum cardinality –“A course offering is taught by an instructor.” : 1 –“An order contains a collection of items.” : M Minimum cardinality can be indicated by the words such as –“optional” : 0 –“required” : 1

10. 6.1 - 10 Adding Relationships (Direct or Indirect Connections) Problem statement may lead to direct or indirect connections Direct connection: –A relationship between two entity types. Indirect connection: –A connection through other entity types and relationships. Example: “ An advisor counsels students about the choice of a major.” May indicate direct or indirect relationships between advisor, student and major

11. 6.1 - 11 Hub ( 樞紐 ) Entity Types Entity types involved in multiple relationships should be placed in the center as a hub in order to reduce the number of direct connections in an ERD. Entity types derived from important documents are often hubs in an ERD. –Orders, Registrations, purchase orders ( 採購單 ), etc. Example: “An order entity type can be directly related to customer, employee, and product. It removes the need for direct connections between every pair of entity types.”

12. 6.1 - 12 Hub Entity Types Order is a hub entity type

13. 6.1 - 13 Requirements of Water Utility Database (1) Customer data include a unique customer number, a name, a billing address, a type (commercial or residential), an applicable rate, and a collection (one or more) of meters. Meter ( 水錶 ) data include a unique meter number, an address, a size, and a model. The meter number is engraved on the meter before it is placed in service. A meter is associated with one customer at a time. An employee periodically reads each meter on a scheduled date. When a meter is read, a meter-reading document is created containing a unique meter reading number, an employee number, a meter number, a timestamp (includes date and time), and a consumption level. When a meter is first placed in service, there are no associated reading for it.

14. 6.1 - 14 Requirements of Water Utility Database (2) A rate includes a unique rate number, a description, a fixed dollar amount, a consumption threshold ( 用量 門檻 ), and a variable amount (dollars per cubic foot). –Consumption up to the threshold is billed at the fixed amount. –Consumption greater than the threshold is billed at the variable amount. Customers are assigned rates using a number of factors such as customer type, address, and adjustment factors. Many customers can be assigned the same rate. Rates are typically proposed months before approved and associated with customers.

15. 6.1 - 15 Requirements of Water Utility Database (3) The water utility bills are based on customers’ most recent meter readings and applicable ( 適用的 ) rates. A bill consists of a heading part and a list of detail lines. –The heading part contains a unique bill number, a customer number, a preparation date, a payment due date, and a date range for the consumption period. –Each detail line contains a meter number, a water consumption level, and a dollar amount. — The water consumption level is computed by subtracting the consumption levels in the two most recent meter readings. — The dollar amount is computed by multiplying the consumption level by the customer’s rate.

16. 6.1 - 16 Water Utility Database (Customer Data ) Customer data include a unique customer number, a name, a billing address, a type (commercial or residential), an applicable rate, and a collection (one or more) of meters. 12

17. 6.1 - 17 Water Utility Database (Meter and Meter-Reading) Meter data include a unique meter number, an address, a size, and a model. A meter is associated with one customer at a time. An employee periodically reads each meter on a scheduled date. When a meter is read, a meter- reading document is created containing a unique meter reading number, a timestamp (includes date and time), a consumption level, an employee number, and a meter number. When a meter is first placed in service, there are no associated reading for it. 1-M FK 1 2 3 4

18. 6.1 - 18 Water Utility Database (Water Rate) A rate includes a unique rate number, a description, a fixed dollar amount, a consumption threshold ( 用量門檻 ), and a variable amount (dollars per cubic foot). Many customers can be assigned the same rate. Rates are typically proposed months before approved and associated with customers. Assigned relationship 213

19. 6.1 - 19 Water Utility Database (Bill) A bill consists of a heading part and a list of detail lines. The heading part contains a unique bill number, a customer number, a preparation date, a payment due date, and a date range for the consumption period. A bill has a list of detail lines. Each detail line has a meter number, a water consumption level, and an amount. 1-M FK 12 3 4 4 5

20. 6.1 - 20 ER Diagram Refinements ( 精鍊 ) Construct initial ERD Revise many times In refining a data model, you should generate feasible alternatives and evaluate them according to requirements Gather additional requirements from users to evaluate feasible alternatives if needed Use transformations to suggest feasible alternatives

21. 6.1 - 21 1.Transform Attribute into Entity Type Initial Design: Reading only includes EmpNo Revised Design: learn more about employee details important to the problem Add Employee entity type An employee periodically reads each meter on a scheduled date. 1 2 Transform into entity type

22. 6.1 - 22 2.Splitting Compound Attribute ( 組合屬性 ) A compound attribute contains multiple kinds of data. More difficult/less efficient to search (compound) address because of lack of standardization Initial Design: Compound attributes Revised Design: Split into smaller attributes Split compound attribute

23. 6.1 - 23 3.Expanding Entity Types Make an entity type into two entity types and a relationship Useful to record a finer level of detail about entities Initially, the variable amount apply to all consumption level beyond a fixed level ( 基本量 ). It can be useful to have a more complex rate structure in which the variable amount depends on the consumption level. 0 ~220 : 2.10 元 / 度 221 ~ 440 : 2.68 元 / 度 >= 441 : 3.27 元 / 度 台灣電費費率 (101/4/30 以前 ) 3 種變動費率

24. 6.1 - 24 Expanding Entity Types The RateSet entity type represents a set of rates approved by the utility’s governing commission. 批准日期 生效日期 0 ~220 : 2.10 元 / 度 221 ~ 440 : 2.68 元 / 度 >= 441 : 3.27 元 / 度 台灣電費費率 (101/4/30 以前 ) Expand entity type

25. 6.1 - 25 4.Weak to Strong Entity Transformation Facilitates references after conversion to a table design For a weak entity, table design involves a combined PK. Most useful for associative entity types Steps : 1.Remove identification dependency symbols (identifying relationships and weak entity) 2.Find a PK

26. 6.1 - 26 Weak to Strong Entity Transformation Note that the combination of RateSetNo and MinUsage is unique in design documentation so that a candidate key constraint can be specified after conversion to a table design. RateSetNo is a FK in Rate RateSetNo is a FK and part of PK in Rate

27. 6.1 - 27 5.Adding History to Attributes EmpTitle attribute is replaced with a weak entity type and an identifying 1-M relationship Use version number as a local key Record effective dates (beginning and ending) of change Add history to an attribute

28. 6.1 - 28 ˊ 6.Adding History to 1-M Relationships 儲存現在和過去的記錄，客戶可能搬遷 Changing a 1-M relationship into an associative entity type and a pair of identifying 1-M relationships. The associative entity type is necessary because the combination of customer and meter may not be unique without a version number. Why ? 搬離又搬回

29. 6.1 - 29 Adding Limited History (An Alternative Design for Employee) For a limited history, a fixed number of attributes can be added to the same entity type. Two sets of attributes are added to store current and previous titles. Note that only current and previous titles are stored Original design

30. 6.1 - 30 7.Adding Generalization Hierarchy Use this transformation sparingly ( 節制地 ) Customer can be classified as commercial or residential –The attributes specific to commercial customer (TaxPayerID & EnterpriseZone) do not apply to residential customers. Benefits: Avoid null values Subsidized 補助的 Dwelling Type 住宅類別

31. 6.1 - 31 分組專題 (Data Modeling Problems) 下一週上課前一天中午十二點整交 分組專題 #5 第六章 200-201 頁 Data Modeling Problems 20 (Use ER Assistant to draw ERD)