Author: Graeme C. Simsion and Graham C. Witt Chapter 8 Organizing the Data Modeling Task.

Author: Graeme C. Simsion and Graham C. Witt

Chapter 8Organizing the Data Modeling Task

Copyright: ©2005 by Elsevier Inc. All rights reserved. 2

Generalization (2)

• Breaking the rule of non-overlapping of sub-types

• Benefits of sub and super-types

• Other Types of Generalization

– Relationship Generalization

– Attribute Generalization

– Alternative diagramming Conventions


Overlapping Subtypes and Roles

• There are several tactics we can use without breaking the “no overlaps” rule:

– Ignoring real-world overlaps

– Modeling only the Supertype

– Modeling the roles as participation in relationships

– Role entity classes and one-to-one relationships

– Multiple partitions


Ignoring Real-World Overlaps

• While a customer and a supplier may in fact be the same person, the business may be happy to treat them as if they were separate individuals.

– Beware the company that sued a customer for non-payment only to find that they were also a supplier and were withholding because the company had failed to pay them.

• You thus need to be careful in choosing not to reflect “real-world” overlap in the data model.

• But, don’t automatically model all overlaps!


Modeling Only the Supertype

• One of the most common approaches to modeling the roles of persons and organizations is to use only a single supertype entity class for all roles.

– If subtyping is done at all, it is on the basis of some other criterion, such as “legal entity class type”partnership, company, individual, etc.

– The supertype is typically named Party, Involved Party, or Legal Entity.

• The major limitation of the approach is that we cannot readily capture in the model the fact that some relationships apply only to certain roles.


Modeling the Roles as Participation in Relationships

• In the supertype-only model roles can often be described in terms of participation in relationships.

– a customer is a party who maintains an account

– a supplier as a party who participates in a contract for supply.


Using Role Entity Classes and One-to-One Relationships

Party

SupplierRole

CustomerRole

Account

Contractfor Supply

play

be playedby

be playplayed by

be party to

nominateas supplier

own

be ownedby


The party role explained

• The role entity classes can be supertyped into Party Role

– This is to facilitate communication and we would be most unlikely to implement at this level, : we could have no distinction among roles that the role entity classes were designed to provide.

– intermediate supertyping is often useful in that it helps us to address the roles we need in specific contexts

• The role entity class approach is usually the neatest solution to the problem when there are significant differences in the attributes and relationships applicable to different roles.


Multiple Partitions

• Several CASE tools allow multiple breakdowns (partitions) into complete, non-overlapping subtypes. (opposite)

LocalCompany

OverseasCompany

PrivateCompany

PublicCompany

StockExchange

list

be listed on

berepresented

by

represent

Company


Example explained

• Only a public company can be listed on a stock exchange.

• Only an overseas company can be represented by a local company.

• If a given company could be both public and local, for example, it would be difficult to model both of these constraints if we were restricted to a single partition.


Translating multiple partitons• Translation to a relational model is difficult. We can

do any one of the following:

1. Implement only the highest level supertype as a table

2. Select one partition and implement the subtypes as tables, e.g., Private Company and Public Company

3. Implement multiple levels selecting only some of the partitions, e.g., implement only Company, Private Company and Public Company as tables

4. Implement multiple levels and multiple partitions, e.g., implement Company, Local Company, Overseas Company, Private Company and Public Company all as tables.


When do we stop?

• Don’t subtype where sub-types have different identifiers, or different attribute groups, or participate in different relationships, or where some sub-types engage in critical processes and others do not

• Don’t sub-type where migration of occurrences from one sub-type to another is common


Benefits of Using Subtypes and Supertypes

• Creativity

– “Can this entity class be subtyped into more specific entity classes that represent distinct business concepts?” and,

– “Are any of the entity classes candidates for generalization into a common supertype?”

• Presentation: Level of Detail

• Communication

• Input to the Design of Views

• Classifying Common Patterns

• Divide and Conquer (top-down) Approach to Modeling


• Relationship generalization resulting from entity generalization

Vehicle

FurnitureItem

Machine

Vehicle Maintenance

Event

FurnitureItem

Maintenance Event

Machine Maintenance

Event

be the subject of

be for

be the subject of

be for

be the subject of

be for

Physical Asset Maintenance Event

generalizing entities

PhysicalAsset

MaintenanceEvent

be the subject of

be for

be the be for subject of

be for be the subject of

PhysicalAsset

MaintenanceEvent

be the subject of

be for

generalizing relationships


• Generalizing mutually exclusive 1:many relationships

PersonInsurance

Policy

be involved in

involve

PersonInsurance

Policy

be insured under

insure be beneficiary of

nominate as beneficiary

be contact for

have as contact

hold as security

be assigned as security to


Mutually Exclusive Relationships

TaxAssessment

Company

Individual

Partnership

GovernmentBody

be for

be the subject of be for

be thesubject of

be thesubject of be for

be thesubject

be for

exclusivity arc

• Diagramming convention for mutually exclusive relationships


Attribute Generalization within Entity Classes: One Class!

• FINANCIAL PERFORMANCE(Department No, Year, Approved By,First Quarter Material Budget Amount, Second Quarter Material Budget Amount,Third Quarter Material Budget Amount, Last Quarter Material Budget Amount,First Quarter Material Actual Amount, Second Quarter Material Actual Amount,Third Quarter Material Actual Amount, Total Material Actual Amount,First Quarter Labor Budget Amount, Second Quarter Labor Budget Amount,Third Quarter Labor Budget Amount, Last Quarter Labor Budget Amount,First Quarter Labor Actual Amount, Second Quarter Labor Actual Amount,Third Quarter Labor Actual Amount, Total Labor Actual Amount,Other Budget Amount, Other Actual Amount, Discretionary Spending Limit)


Generalizing Budget vs. Actual for Each Category

FinancialPerformance

MaterialBudget

Item

LaborBudget

Item

OtherBudget

Item

MaterialActualItem

LaborActualItem

OtherActualItem

be included in

include

be

included in

include

beincluded in

include

beincluded in

include

beincluded in

include

beincluded in

include

• FINANCIAL PERFORMANCE (Department No, Year, Approved By, Discretionary Spending Limit)MATERIAL BUDGET ITEM (Department No, Year, Period Number, Material Budget Amount)LABOR BUDGET ITEM (Department No, Year, Period Number, Labor Budget Amount)OTHER BUDGET ITEM (Department No, Year, Period Number, Other Budget Amount)MATERIAL ACTUAL ITEM (Department No, Year, Period Number, Material Actual Amount)LABOR ACTUAL ITEM (Department No, Year, Period Number, Labor Actual Amount)OTHER ACTUAL ITEM (Department No, Year, Period Number, Other Actual Amount)


Generalizing to Budget vs. Actual for All Categories

FinancialPerformance

BudgetItem

ActualItem

beincluded in

include

beincluded in

include

• FINANCIAL PERFORMANCE (Department No, Year, Approved By, Discretionary Spending Limit)

• BUDGET ITEM (Department No, Year, Period Number, Budget Type, Budget Amount)

• ACTUAL ITEM (Department No, Year, Period Number, Budget Type, Actual Amount)


The ‘Thing’ Equivalent for Attributes

EquipmentItem

ParameterValue

be characterized by

characterize

Equipment Item ID

Parameter Type

Parameter Value


… And Generalized

• generalization for kind of equipment and parameter type vs. actual equipment and value

EquipmentItem

ParameterValue

be characterized by

characterize

ParameterType

beclassified by

classify

Parameter Type Code

Parameter Name

Format

Editing Rules

Optionality

EquipmentType

be characterized by

characterize

beclassified by

classify


Diagramming ConventionsPerson

WomanMan

Marriage

1..1

be the husband in

0..*

1..1

be the wife in

0..*

be the father of 0..*

1..1

0..* be the mother of

1..1

• Boxes in Boxes (the text)

• Most of the alternative conventions, including UML are based around lines between supertypes and subtypes.

– confused with relationships,

– implies that the model allows redundant data.


Using Tools that Do Not Support Subtyping

• usually tools suggest subtypes be shown as one-to-one relationships.

• suggest you adopt a relationship name, such as “be” or “is,”


Beginning next lecture

• Now that we know about the tools we can begin to explore using them in ‘anger’ in real business contexts

– Process/stages and deliverables

– Data warehousing

Author: Graeme C. Simsion and Graham C. Witt Chapter 8 Organizing the Data Modeling Task.

Documents

Transcript of Author: Graeme C. Simsion and Graham C. Witt Chapter 8 Organizing the Data Modeling Task.