Download presentation
Presentation is loading. Please wait.
Published byKathlyn Fitzgerald Modified over 9 years ago
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.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.