1. Completing the Model Common Problems in Database Design

2. Common Design problems Misplaced relationships Incorrect Cardinalities Missing Relationships Overuse of specialized data modeling tools (ex: Inheritance, multiway relationships) Redundant Relationships Information Traps: Fan/Chasm Unnormalized Attributes

3. Fan Traps Result of hierarchical relationships that split semantic relationships resulting in the loss of information Commonly expressed by traversals from weak entity to related weak entity through parent which results in loss of information Fixed by reordering hierarchy

4. Example of Fan Trap Issue: Who works in which office?

5. Fixing a Fan Trap

6. Chasms Result of hierarchical relationships that split semantic relationships resulting in the loss of business rules Commonly expressed by creating artificial intermediate entity values for the sole purpose of providing a link Fixed by rebalancing hierarchy and adding appropriate relationships

7. Example of a Chasm Issues: What if a customer is not assigned to an employee?

8. Fixing a Chasm

9. Unnormalized Attribute Does an attribute name contain data? –Multiple Attributes: ex : A1, A2, A3, …, An ex :First_Inspection, Second_Inspectionm … –Enumerations: X-Approval, Y-Approval, Z-Approval Difficult to predict population and changes require attribute changes

10. Fixing Repeating Attributes Split repeating variables into its own –Split into a repeating data group (new entity) based on index ex: (A,n) ex: (InspectionResult, OrderNo)

11. Fixing Enumerations Enumerations –Split the enumeration to code and domain value (code, Approval)

12. Data Defining Data Does one attribute’s value define the meaning and/or domain of another attribute’s value? –For example: miscCode  miscValue where miscCode defines the what the value of miscValue will be– name, number, … Data defining data is extensible but very difficult to use in queries and reports

13. Flattening Data Defining Data Split dependent data into multiple attributes –For example: miscName, miscNumber, … Eliminate defining attribute

14. Validation Entities Does an entity have any attributes that are enumerations but are not foreign keys? Create special code entities to hold the list of enumerated values and descriptions– also known as Reference tables or Cross- Reference entities

15. Make Validation Entities 1.Create new entity 1.Often uses special naming for references 2.Often beginning of a truly independent entity that may have other attributes– for example, State 2.Copy enumerated attribute to new entity 3.Choose primary key for new entity 4.Replace enumerated attribute in base entity with primary key from new entity

16. Make Validation Entities 5.Revise diagram 1.Add new entity to diagram 2.Connect new entity to base entity with relationship 1.Only identifying if reference is part of base entity’s primary key 2.Cardinality is always one new reference entity to many base entity 3.Modality is always required new reference entity and optional base Entity

17. Transform “complex” attributes to entities

18. Use lookup entities(tables) for frequently used data

19. Split compound attributes

20. Add History

21. Transform weak entities to strong entities

22. Intelligent vs Surrogate Keys A surrogate key is an artificial or synthetic key that is used as a substitute for a natural key aka intelligent key. "Surrogate key" may also be known as "System- generated key", "Database Sequence number", "Synthetic key", "Technical key" or an "Arbitrary, unique identifier". primary keys are hard to change. Intelligent keys suffer from this problem because not only are they used as primary and foreign keys but they also have some business meaning associated with them The biggest advantage for intelligent keys is that users understand what they mean whereas surrogate keys don't make any business sense. Data Models that use surrogate keys usually have more normalization errors.

23. Surrogate vs. Intelligent Keys Natural keys: are more logical can sometimes can mean fewer joins help to encourage good modeling are traditional/user friendly make snooping around in the data easier Surrogate keys: are shorter are easier to join take less storage enable natural key fields to be easily changed are what Object Oriented (and object relational) databases use

24. Goals of Database Development Develop a Common Vocabulary Define the meaning of Data Ensure Data Quality Find an Efficient Implementation

25. Final Word Remember that the goal of the DB development is to produce a DB that provides an important resource for an organization. The DB should be designed so that it can serve the customers and other team members efficiently.