PATTERNS OF DATA MODELING- P44 pps

Part VI Relational Database Design Chapter 16 Relational Database Design 205 This book is about patterns and patterns are described via models.. Next I drive the UML content into an IDEF

202 Chapter 15 / State Diagrams

AM Thus a Stimulus is a specific occurrence that conforms to the general description of its StimulusType.

A State is the period in which an Entity waits for the next Stimulus For example, Joe

Smith has placed his order and the order is in the StateType of OrderAcknowledged awaiting completion of verification Similar States are described by a common StateType All Stimuli are ignored in a State, except those for which a StateDiagram prescribes behavior Each En-tity can have many States over time, but has exactly one State at a time A StateDiagram has

no memory of the past and responds to Stimuli solely on the basis of an Entity’s current State Note the contrast between Stimulus and State A Stimulus represents a point in time A State represents an interval of time.

A Transition is an instantaneous change from a source State to a target State A

Tran-sition happens when a Stimulus occurs and the Entity’s current State and the Stimulus

match-es the typmatch-es specified for the TransitionType The Transition causmatch-es the Entity to shift to the target State Multiple Entities may be caused to Transition by the same Stimulus.

The StateDiagram and Scenario models use the ItemDescription and Homomorphism

templates (see Chapter 5)

15.3 Chapter Summary

A state diagram specifies the permissible states and stimuli that cause changes of state A scenario executes a state diagram and can store the current state as well as the past history State diagrams are helpful for situations where there is a lifecycle or a meaningful sequence

of steps to enforce Developers typically realize state diagrams by writing the equivalent pro-cedural code But another option is to have a generalized interpreter based on the models in this chapter

Bibliographic Notes

I have used declarative state diagrams on several industrial consulting projects This chapter was motivated by Chapter 6 of [Silverston-2009] Silverston and Agnew discuss the notion

of data status which can be much more richly modeled with state diagrams

[Blaha-2005] has a further explanation of UML state diagrams

References

[Blaha-2005] Michael Blaha and James Rumbaugh Object-Oriented Modeling and Design with UML,

2nd Edition Upper Saddle River, NJ: Prentice Hall, 2005.

[Silverston-2009] Len Silverston and Paul Agnew The Data Model Resource Book, Volume 3 New

York, New York: Wiley, 2009.

Part VI

Relational Database Design

Chapter 16 Relational Database Design 205

This book is about patterns and patterns are described via models I have presented two no-tations — the UML data structure notation and the IDEF1X notation — to help readers fa-miliar with either or both notations understand the nuances of patterns

Chapter 16 elaborates this use of two modeling notations and presents an overview of

my approach to the database design process I begin constructing a model with the UML data structure notation and then flesh out the attributes Next I drive the UML content into an IDEF1X model and add database design decisions Finally I use a tool and generate the ap-propriate database DDL (data definition language) code

16

Relational Database Design

This chapter summarizes my approach to database design I start with a UML model of con-ceptual and logical intent and use that as the basis for preparing an IDEF1X model Given

an IDEF1X model, modern tools can readily generate SQL code to create the database struc-ture As a matter of software engineering discipline, I recommend a uniform policy for database design and deviate from the recommendations that follow only for good cause (such

as demanding performance)

16.1 Mapping: Entity Types

As Figure 16.1 shows, each entity type normally maps to a table Each attribute becomes a column in the table There may be additional columns for existence-based identity, buried relationships, and generalization discriminators (to be explained)

Two alternative mappings are sometimes useful

airportID

Airport

iataCode (AK1.1) airportName

Figure 16.1 Entity type: Mapping Map each entity type to a table.

IDEF1X model

airportName

Airport

206 Chapter 16 / Relational Database Design

• Fragmentation For distributed databases it may be helpful to split an entity type into

vertical or horizontal fragments A vertical split maps attributes to columns in different tables A horizontal split apportions records across multiple tables with identical columns

• Elided table If an entity type has no attributes other than a primary key, it may not be

mapped to a table and simply omitted However, such an optimization seldom boosts performance I discourage this option because it leads to an irregular schema I prefer a strict correspondence between UML and IDEF1X models as a matter of software engi-neering rigor

16.2 Mapping: Non-Qualified Relationships

Relationship mappings mostly depend on the multiplicity

• Many-to-many relationship Map a many-to-many relationship to a distinct table (Fig-ure 16.2) The primary key of the relationship combines the primary keys of the entity types Role names become part of foreign key attribute names

• Simple one-to-many relationship Bury a foreign key in the “many” table (Figure 16.3) Role names become part of foreign key attribute names

• Simple optional-to-exactly-one relationship Bury a foreign key in the “optional”

ta-ble (Figure 16.4) Role names become part of foreign key attribute names The foreign key is unique in the buried table

• Other simple one-to-one relationship Bury a foreign key in either table.

• Relationship with attributes Regardless of the multiplicity, map the relationship to a

distinct table Add relationship attributes to the distinct table

• Aggregation and composition Follow the same mappings as the underlying

relation-ship

Figure 16.2 Many-to-many relationship: Mapping Map a

many-to-many relationship to a distinct table

IDEF1X model

UML model

Payment

amount date

Invoice

number date amount

paymentID

Payment

amount date invoiceID

Invoice

invoiceNumber date

amount

Payment_Invoice

paymentID (FK) invoiceID (FK)

16.2 Mapping: Non-Qualified Relationships 207

• Ordered relationship Use the same mapping as without ordering Add a sequence

number attribute and define a uniqueness constraint on the source entity type plus the sequence number (Figure 16.5)

• Ternary and n-ary relationships These seldom occur and many database design tools

do not support them Where possible, restate them as binary relationships Otherwise promote them to entity types and define the appropriate uniqueness constraints Sometimes it is desirable to disregard the recommended mappings and promote simple one-to-one and one-to-many relationships to distinct tables For example, Chapter 14 had a

sep-arate table for the relationship between Entity and Icon even though it was one-to-many (as well as for the relationships between Model–Diagram, Port–Tab, and Connection–Line) It

Figure 16.3 Simple one-to-many relationship: Mapping Bury a foreign

key in the “many” table

PublishedFlightLeg

scheduledDepartureTime scheduledDuration

iataCode {unique}

airportName

Airport

*

*

1 1 scheduledOrigin

scheduledDest

publishedFlightLegID

PublishedFlightLeg

scheduledDepartureTime scheduledDuration scheduledOriginID (FK) scheduledDestinationID (FK)

airportID

Airport

iataCode (AK1.1) airportName

IDEF1X model

UML model

Figure 16.4 Simple optional-to-exactly-one relationship: Mapping Bury

a foreign key in the “optional” table

0 1 Customer

salesData 1

creditInformation discountSchedules

tangibleActorID

TangibleActor

customerID

Customer

salesData creditInformation discountSchedules tangibleActorID (FK) (AK1.1)

TangibleActor

IDEF1X model

UML model