Upload
elda
View
37
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Chapter 6. Developing Data Models for Business Databases. Outline. Analysis of narrative problems Transformations for generating alternative designs Finalizing an ERD Schema Conversion Alternative notations. Analyzing Narrative Problems (I). - PowerPoint PPT Presentation
Citation preview
Chapter 6Chapter 6Developing Data Models for Business Databases
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Outline Outline
Analysis of narrative problemsTransformations for generating alternative
designsFinalizing an ERDSchema ConversionAlternative notations
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Problem Narrative Example (I)Problem Narrative Example (I)
BillBillNo
BillDateBillStartDateBillEndDateBillDueDate
CustomerCustNo
CustNameCustAddrCustType
MeterMeterNoMtrAddrMtrSize
MtrModel
ReadingReadNo
ReadTimeReadLevel
EmpNo
RateRateNo
RateDescRateFixedAmt
RateThreshRateVarAmt
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Problem Narrative Example (II)Problem Narrative Example (II)
RateNo
RateCustNo
Customer
BillNo
BillReadNo
Reading
MeterNo
Meter
Assigned Uses
ReadBy
Includes
SentTo
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Diagram RefinementsDiagram Refinements
Construct initial ERDRevise many timesGenerate feasible alternatives and evaluate
according to requirementsGather additional requirements if neededUse transformations to suggest feasible
alternatives
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Attribute to Entity Type Attribute to Entity Type TransformationTransformation
ReadNoReadTimeReadLevel
Reading
EmpNoEmpNameEmpTitle
Employee
Performs
ReadNoReadTimeReadLevelEmpNo
Reading
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Compound Attribute Compound Attribute TransformationTransformation
CustomerCustNo
CustNameCustAddrCustType
CustomerCustNo
CustNameCustStreetCustCityCustStateCustPostalCustType
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Entity Type Expansion Entity Type Expansion TransformationTransformation
RateSetNoRSApprDateRSEffDateRSDesc
RateSet
MinUsageMaxUsageFixedAmtVarAmt
Rate
Contains
RateNoRateDescRateFixedAmtRateVarAmtRateThresh
Rate
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Weak to Strong Entity Weak to Strong Entity TransformationTransformation
RateSetNoRSApprDateRSEffDateRSDesc
RateSet
RateRateNoMinUsageMaxUsageFixedAmtVarAmt
Contains
RateSetNoRSApprDateRSEffDateRSDesc
RateSet
MinUsageMaxUsageFixedAmtVarAmt
Rate
Contains
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
History Transformation (I)History Transformation (I)
TitleHistoryChangeDateEmpTitle
TitleChanges
EmpNoEmpNameEmpTitle
Employee
EmployeeEmpNoEmpName
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
History Transformation (II)History Transformation (II)CustomerCustNo...
MeterMeterNo...
Uses
CustomerCustNo...
MeterMeterNo...
Uses BegDate
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Generalization Hierarchy Generalization Hierarchy TransformationTransformation
CustomerCustNo
CustNameCustAddr
CommercialTaxPayerID
EnterpriseZone
ResidentialSubsidized
DwellingType
D,C
CustomerCustNo
CustNameCustTypeCustAddr
TaxPayerIDEnterpriseZone
SubsidizedDwellingType
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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.
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Documentation with the ER Documentation with the ER AssistantAssistantAttribute commentsEntity type commentsRelationship commentsDesign justificationsDiagram notes
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Example Entity Type ClusterExample Entity Type Cluster
RateSetNoRSAapprDateRSEffDate
RateSetCustNoCustNameCustType
Customer
BillNoBillDateBillStartDate
BillReadNoReadTimeReadLevel
Reading
MeterNoMtrSizeMtrModel
Meter
Assigned Uses
ReadBy
IncludesMinUsageMaxUsageFixedAmt
Rate
EmpNoEmpNameEmpTitle
EmployeePerforms
Contains
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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.
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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 )
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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 )
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Generalization Hierarchy ExampleGeneralization Hierarchy Example
Employee table: EmpNo (PK)SalaryEmp table: EmpNo (PK), EmpNo (FK)HourlyEmp table: EmpNo (PK), EmpNo (FK)
EmployeeEmpNo
EmpNameEmpHireDate
SalaryEmpEmpSalary
HourlyEmpEmpRate
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Optional 1-M RuleOptional 1-M Rule
Separate table for each optional 1-M relationship
Avoids null valuesRequires an extra table and join operationControversial
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
1-1 Relationships1-1 Relationships
EmpNoEmpName
EmployeeOfficeNoOffAddressOffPhone
Office
Manages
CREATE TABLE Office (… PRIMARY KEY (OfficeNo) , FOREIGN KEY(EmpNo) REFERENCES Employee, UNIQUE (EmpNo) )
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
ERD VariationsERD Variations
No standard ERD notationSymbol variationsPlacement of cardinality symbolsRule variationsBe prepared to adjust to the ERD notation
in use by each employer
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
ERD Rule VariationsERD Rule Variations
M-way relationshipsM-N relationshipsRelationships with attributesSelf-referencing relationshipsRelationships connected to other
relationships
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
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
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Generalization RelationshipGeneralization Relationship
Undergraduate
Major : String Minor : String
Graduate
ThesisTitle : String ThesisAdvisor : String
Status{complete}
Generalizationname
Student
StdSSN : Long StdFirstName : String StdLastName : String
Generalizationconstraint
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
Composition RelationshipComposition Relationship
OrdLine
LineNo : Integer Qty : Integer
Composition symbol(dark diamond)
Order
OrdNo : Long OrdDate : Date OrdAmt : Currency
1..n
1..1
McGraw-Hill/Irwin © 2004 The McGraw-Hill Companies, Inc. All rights reserved.
SummarySummary
Data modeling is an important skill Use notation preciselyConsider alternative designsApply specialized concepts carefullyWork many problemsNo standard ERD notation