PATTERNS OF DATA MODELING- P44 pps

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 types specified for the TransitionType. The Transition causes 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. 203 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. 205 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 UML model iataCode {unique} 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, Po rt–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 . The Data Model Resource Book, Volume 3. New York, New York: Wiley, 2009. 203 Part VI Relational Database Design Chapter 16 Relational Database Design 205 This book is about patterns and patterns. 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. 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