Date post: | 30-Dec-2015 |
Category: |
Documents |
Upload: | kathlyn-fitzgerald |
View: | 219 times |
Download: | 0 times |
Completing the Model
Common Problems in Database Design
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
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
Example of Fan Trap
Issue: Who works in which office?
contains
Office
OfficeCodeOfficeNameAddress
worksFor
employee
EmployeeIdFirstNameLastName
division
DivisionCodeDivisionName
Fixing a Fan Trap
contains
Office
OfficeCodeOfficeNameAddress
worksFor
employee
EmployeeIdFirstNameLastName
division
DivisionCodeDivisionName
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
Example of a Chasm
Issues: What if a customer is not assigned to an employee?
Represents
Customer
CustomerIdCustomerNameAddressDiscountRate
worksFor
employee
EmployeeIdFirstNameLastName
division
DivisionCodeDivisionName
Fixing a Chasm
dealsWith
Represents
Customer
CustomerIdCustomerNameAddressDiscountRate
worksFor
employee
EmployeeIdFirstNameLastName
division
DivisionCodeDivisionName
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
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)
Fixing Enumerations
• Enumerations– Split the enumeration to code and domain
value
(code, Approval)
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
Flattening Data Defining Data
• Split dependent data into multiple attributes– For example: miscName, miscNumber, …
• Eliminate defining attribute
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
Make Validation Entities
1. Create new entity1. 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
Make Validation Entities
5. Revise diagram1. Add new entity to diagram
2. Connect new entity to base entity with relationship1. 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
Transform “complex” attributes to entities
ServiceRecord
ServiceDateEquipmentNoEmployeeNameDescription
performedBy
Employee
EmployeeIdFirstNameLastNameHiredate
ServiceRecord
ServiceDateEquipmentNoEmployeeNoDescription
Use lookup entities(tables) for frequently used data
Employee
IdNameSalaryCountry
student
IdNameCountry
eresident
sresident country
codeName
Employee
IdNameSalaryCountryCode
student
IdNameCountryCode
Split compound attributes
customer
customerIdNameAddress
customer
customerIdNameStreetAddressCityCountry
Add History
Instructor
idNameTitle
TitleChanges
InstructorTitle
ChangeDateTitle
Instructor
idName
Transform weak entities to strong entities
payments
Installment
InvoiceNoInstallmentDateAmount
Invoice
InvoiceNoInvoiceDateCustomerId
payments
Installment
InstallmentIdInvoiceNoInstallmentDateAmount
Invoice
InvoiceNoInvoiceDateCustomerId
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.
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
Goals of Database Development
• Develop a Common Vocabulary
• Define the meaning of Data
• Ensure Data Quality
• Find an Efficient Implementation
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.