chapter 6 developing data models for business databases

Chapter 6Chapter 6Developing Data Models for Business Databases

Outline Outline

Analysis of narrative problemsTransformations for generating alternative

designsFinalizing an ERDSchema ConversionAlternative notations

Analyzing Narrative Problems (I)Analyzing Narrative Problems (I)

Identify potential entity types and attributes– For entity types, find nouns that represent

groups of people, places, things, and events– For attributes, look for properties that provide

details about the entity types Determine primary keys

– Stable and single purpose– Identify other candidate keys

Problem Narrative Example (I)Problem Narrative Example (I)

BillBillNo

BillDateBillStartDateBillEndDateBillDueDate

CustomerCustNo

CustNameCustAddrCustType

MeterMeterNoMtrAddrMtrSize

MtrModel

ReadingReadNo

ReadTimeReadLevel

EmpNo

RateRateNo

RateDescRateFixedAmt

RateThreshRateVarAmt

Analyzing Narrative Problems (II)Analyzing Narrative Problems (II)

Identify relationships connecting previously identified entity types– Relationship references involve associations

among nouns representing entity types– Sentences that involve an entity type having

another entity type as a property– Sentences that involve an entity type having a

collection of another entity type

Problem Narrative Example (II)Problem Narrative Example (II)

RateNo

RateCustNo

Customer

BillNo

BillReadNo

Reading

MeterNo

Meter

Assigned Uses

ReadBy

Includes

SentTo

Diagram RefinementsDiagram Refinements

Construct initial ERDRevise many timesGenerate feasible alternatives and evaluate

according to requirementsGather additional requirements if neededUse transformations to suggest feasible

alternatives

Attribute to Entity Type Attribute to Entity Type TransformationTransformation

ReadNoReadTimeReadLevel

Reading

EmpNoEmpNameEmpTitle

Employee

Performs

ReadNoReadTimeReadLevelEmpNo

Reading

Compound Attribute Compound Attribute TransformationTransformation

CustomerCustNo

CustNameCustAddrCustType

CustomerCustNo

CustNameCustStreetCustCityCustStateCustPostalCustType

Entity Type Expansion Entity Type Expansion TransformationTransformation

RateSetNoRSApprDateRSEffDateRSDesc

RateSet

MinUsageMaxUsageFixedAmtVarAmt

Rate

Contains

RateNoRateDescRateFixedAmtRateVarAmtRateThresh

Rate

Weak to Strong Entity Weak to Strong Entity TransformationTransformation

RateSetNoRSApprDateRSEffDateRSDesc

RateSet

RateRateNoMinUsageMaxUsageFixedAmtVarAmt

Contains

RateSetNoRSApprDateRSEffDateRSDesc

RateSet

MinUsageMaxUsageFixedAmtVarAmt

Rate

Contains

History Transformation (I)History Transformation (I)

TitleHistoryChangeDateEmpTitle

TitleChanges

EmpNoEmpNameEmpTitle

Employee

EmployeeEmpNoEmpName

History Transformation (II)History Transformation (II)

CustomerCustNo...

MeterMeterNo...

Uses

CustomerCustNo...

MeterMeterNo...

Uses BegDate

Generalization Hierarchy Generalization Hierarchy TransformationTransformation

CustomerCustNo

CustNameCustAddr

CommercialTaxPayerID

EnterpriseZone

ResidentialSubsidized

DwellingType

D,C

CustomerCustNo

CustNameCustTypeCustAddr

TaxPayerIDEnterpriseZone

SubsidizedDwellingType

Summary of TransformationsSummary of TransformationsTransformation Details When to Use

Attribute to entity type

Replace attribute with an entity type and a 1-M relationship.

Add detail about an entity.

Split a compound attribute

Replace an attribute with a collection of attributes.

Standardize the data in an attribute.

Expand entity type Add a new entity type and a 1-M relationship.

Add a finer level of detail about an entity.

Weak entity to strong entity

Remove identification dependency symbols and possibly add a primary key.

Remove combined foreign keys after conversion to tables.

Add history For attribute history, replace an attribute with an entity type and a 1-M relationship. For relationship history, change relationship cardinality to M-N with an attribute.

Add detail for legal requirements or strategic reporting.

Add generalization hierarchy

Starting from a supertype: add subtypes, a generalization hierarchy, and redistribute attributes to subtypes. Starting from subtypes: add a supertype, a generalization hierarchy, and redistribute common attributes and relationships to the supertype.

Accepted classification of entities; Specialized attributes and relationships for the subtypes.

Documenting an ERDDocumenting an ERD

Important for resolving questions and in communicating a design

Identify inconsistency and incompleteness in a specification

Identify reasoning when more than one feasible alternative exists

Do not repeat the details of the ERDIncorporate documentation into the ERD

Documentation with the ER Documentation with the ER AssistantAssistantAttribute commentsEntity type commentsRelationship commentsDesign justificationsDiagram notes

Common Design ErrorsCommon Design Errors Misplaced relationships: wrong entity types

connected Incorrect cardinalities: typically using a 1-M

relationship instead of a M-N relationship Missing relationships: entity types should be

connected directly Overuse of specialized modeling tools:

generalization hierarchies, identification dependency, self-referencing relationships, M-way relationships

Redundant relationships: derived from other relationships

Resolving Design ErrorsResolving Design Errors

Misplaced relationships: use entity type clusters to reason about connections

Incorrect cardinalities: incomplete requirements: inferences beyond the requirements

Missing relationships: examine implications of requirements

Overuse of specialized modeling tools: only use when usage criteria are met

Redundant relationships: Examine relationship cycles for derived relationships

Example Entity Type ClusterExample Entity Type Cluster

RateSetNoRSAapprDateRSEffDate

RateSetCustNoCustNameCustType

Customer

BillNoBillDateBillStartDate

BillReadNoReadTimeReadLevel

Reading

MeterNoMtrSizeMtrModel

Meter

Assigned Uses

ReadBy

IncludesMinUsageMaxUsageFixedAmt

Rate

EmpNoEmpNameEmpTitle

EmployeePerforms

Contains

Summary of Data Modeling Summary of Data Modeling StrategiesStrategiesUse notation preciselyStrive for simplicityERD connections

– Avoid over connecting the ERD– Identify hub(s) of the ERD

Use specialized patterns carefullyJustify important design decisions

Summary of Basic Conversion Summary of Basic Conversion RulesRules Each entity type becomes a table. Each 1-M relationship becomes a foreign key in

the table corresponding to the child entity type (the entity type near the crow’s foot symbol).

Each M-N relationship becomes an associative table with a combined primary key.

Each identifying relationship adds a column to a primary key.

Application of Basic Rules (I)Application of Basic Rules (I)

CourseNoCrsDescCrsUnits

Course

OfferNoOffLocationOffTime

Offering

Has

CREATE TABLE Course (… PRIMARY KEY (CourseNo) )

CREATE TABLE Offering (… PRIMARY KEY OfferNo, FOREIGN KEY (CourseNo) REFERENCES Course )

Application of Basic Rules (II)Application of Basic Rules (II)

StdSSNStdName

StudentOfferNoOffLocationOffTime

Offering

Enrolls_In

EnrGrade

CREATE TABLE Enrollment (… PRIMARY KEY (StdSSN, OfferNo), FOREIGN KEY (StdSSN) REFERENCES Student, FOREIGN KEY OfferNo REFERENCES Offering )

Application of Basic Rules (III)Application of Basic Rules (III)

• Same conversion result as the previous slide

• Different application of rules

StdSSNStdName

StudentOfferNoOffLocation

Offering

EnrGrade

EnrollmentRegisters Grants

Generalization Hierarchy RuleGeneralization Hierarchy Rule

Mimic generalization hierarchy as much as possible– Each subtype table contains specific attributes plus

the primary key of its parent table.

– Foreign key constraints for subtype tables

– CASCADE DELETE option for referenced rows Reduce need for null values Need joins and outer joins to combine tables

Generalization Hierarchy Generalization Hierarchy ExampleExample

Employee table: EmpNo (PK)SalaryEmp table: EmpNo (PK), EmpNo (FK)HourlyEmp table: EmpNo (PK), EmpNo (FK)

EmployeeEmpNo

EmpNameEmpHireDate

SalaryEmpEmpSalary

HourlyEmpEmpRate

Optional 1-M RuleOptional 1-M Rule

Separate table for each optional 1-M relationship

Avoids null valuesRequires an extra table and join operationControversial

Optional 1-M ExampleOptional 1-M Example

CREATE TABLE Teaches (… PRIMARY KEY (OfferNo) , FOREIGN KEY(OfferNo) REFERENCES Offering, FOREIGN KEY(FacSSN) REFERENCES Faculty )

FacSSNFacName

FacultyOfferNoOffLocationOffTime

Offering

Teaches

1-1 Relationships1-1 Relationships

EmpNoEmpName

EmployeeOfficeNoOffAddressOffPhone

Office

Manages

CREATE TABLE Office (… PRIMARY KEY (OfficeNo) , FOREIGN KEY(EmpNo) REFERENCES Employee, UNIQUE (EmpNo) )

ERD VariationsERD Variations

No standard ERD notationSymbol variationsPlacement of cardinality symbolsRule variationsBe prepared to adjust to the ERD notation

in use by each employer

ERD Rule VariationsERD Rule Variations

M-way relationshipsM-N relationshipsRelationships with attributesSelf-referencing relationshipsRelationships connected to other

relationships

Chen ERD NotationChen ERD Notation

CourseCourseNoCrsDescCrsUnits

Has

OfferingOfferNo

OffLocationOffTime

...

(0:N) (1:1)

Mininum cardinalityfor Course

Maximum Cardinalityfor Course

Maximum Cardinalityfor Offering

Mininum cardinalityfor Offering

Unified Modeling LanguageUnified Modeling Language

Standard notation for object-oriented modeling– Objects– Object features– Interactions among objects

UML supports class diagrams, interface diagrams, and interaction diagrams

More complex than ERD notation

Simple Class DiagramSimple Class Diagram

Offering

EnrollmentCount() : Integer OfferingFull() : Boolean

OfferNo : Long OffTerm : String OffYear : Integer OffLocaton : String

Faculty

FacAge() : Integer

FacSSN : String FacFirstName : String FacLastName : String FacDOB : Date

0..n

0..1Teaches

TaughtBy

Object name

Attributes

Operations

Association

Role nameCardinality

Association ClassAssociation Class

Offering

EnrollmentCount() : Integer OfferingFull() : Boolean

OfferNo : Long OffTerm : String OffYear : Integer OffLocaton : String

Student

StdAge() : Integer

StdSSN : String StdFirstName : String StdLastName : String StdDOB : Date

0..n

0..nTakes

Enrolls

Enrollment

EnrGrade : Numeric

Associationclass

Generalization RelationshipGeneralization Relationship

Undergraduate

Major : String Minor : String

Graduate

ThesisTitle : String ThesisAdvisor : String

Status{complete}

Generalizationname

Student

StdSSN : Long StdFirstName : String StdLastName : String

Generalizationconstraint

Composition RelationshipComposition Relationship

OrdLine

LineNo : Integer Qty : Integer

Composition symbol(dark diamond)

Order

OrdNo : Long OrdDate : Date OrdAmt : Currency

1..n

1..1

SummarySummary

Data modeling is an important skill Use notation preciselyConsider alternative designsApply specialized concepts carefullyWork many problemsNo standard ERD notation