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.