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
Top Related