PATTERNS OF DATA MODELING- P30 pot

10.8 Document 129 DocumentComposition enables a document to combine lesser documents. For example, a product specification sheet may consist of various paragraphs, pictures, and tables. For a given document, there may be no decomposition, one level of decomposition, or multiple levels of decomposition. DocumentComposition is a directed acyclic graph as some documents are reusable in multiple contexts. Note that DocumentComposition avoids symmetry (see Chapter 8) with the distinction between parent and child. There is also DocumentFlow. A Document starts out as a concept (ConceptualDoc) and is then expressed in one or more languages (LanguageDoc). For example, a product specification sheet may have English, German, and Japanese translations. LanguageDocs can be parameterized; a SpecificDoc assigns a value to each parameter. For example, a Language- Doc may have a picture of an electric motor with placeholders (parameters) for length and diameter; the SpecificDoc specifies the actual length and diameter for each motor. And final- ly a SpecificDoc can be the basis for generating ConvertedDocs in formats such as PDF, Figure 10.14 Archetype Customer: IDEF1X model. tangibleActorID TangibleActor . . . customerID Customer salesData creditInformation discountSchedules tangibleActorID (FK) (AK1.1) DocumentFlow Figure 10.15 Archetype Document: UML model. A Document is a physical or electronic representation of a body of information. Document name creationDate size comment ConceptualDoc LanguageDoc SpecificDoc ConvertedDoc DocumentComposition * * * 0 1 parent child parent child parameterValueparameter * 1 * * 1 * formatlanguage Attribute name {unique} Value value 130 Chapter 10 / Archetypes HTML, and XML. The model permits meaningless sequences, but this explanation describes the intended flow and application code must enforce a proper sequence. Thus there is a flow to the progression of documents. Documents start out as concepts, are expressed in various languages, have parameters added, and then are converted into the desired formats. 10.9 Event An Event is an occurrence at some point in time (Figure 10.17, Figure 10.18). The notion of an event often appears in application models. An EventType is a general category of Events. This archetype involves data and metadata and uses the shading convention from Chapter 5. EventTypes can be organized into a generalization hierarchy. For example, a superevent could be pressing a key on a keyboard. A subevent would be pressing an alphanumeric key and a further subevent would be pressing the letter X. Sometimes it is helpful to organize the definition of events by their similarities and differences using generalization. There is also a simple model of cause and effect. A group of causes might lead to a group of effects. By multiple traversals of EventCausality there can be a cascade of events. Figure 10.16 Archetype Document: IDEF1X model. documentDiscrim documentID Document documentName creationDate size comment LanguageDoc languageDocID (FK) language ConceptualDoc conceptualDocID (FK) ConvertedDoc convertedDocID (FK) format SpecificDoc specificDocID (FK) documentDiscrim DocComposition parentDocID (FK) childDocID (FK) parentDocID (FK) attributeID Attribute attributeName (AK1.1) valueID Value value specificDocID (FK) attributeID (FK) LangDoc_parameter languageID (FK) parameterID (FK) 10.10 Flight 131 10.10 Flight A Flight is the travel by an airplane between airports (Figure 10.19, Figure 10.20). The Flight archetype is representative of many transportation routing problems. A published flight is the planned travel and an actual flight is the realized travel. The frequency indicates the days of the week for a PublishedFlight. The effectiveDate and expirationDate bracket the time peri- od for which the PublishedFlight is in effect. A PublishedFlightLeg refers to the scheduled travel between airports with one takeoff and landing. (A through flight has multiple legs.) In contrast, an ActualFlightLeg refers to the actual travel made by an aircraft on a particular date. The actual origin, destination, departure time, and duration can vary because of weather and equipment problems. Normally there is one ActualFlightLeg for a Published- FlightLeg and departureDate, but flight problems can lead to multiple ActualFlightLegs. Each AircraftModel has a manufacturer and model number. Each individual Aircraft has a tail number and refers to an AircraftModel. Note that PublishedFlightLeg to ActualFlight- Leg and AircraftModel to Aircraft illustrate the Item Description template (see Chapter 5). Figure 10.17 Archetype Event: UML model. An Event is an occurrence at some point in time. Event datetime * 1 EventCausality cause effect ** ** 0 10 1 1 * subevent superevent EventGeneralization EventType name {unique} Figure 10.18 Archetype Event: IDEF1X model. eventGeneralizationID EventGeneralization superEventTypeID (FK) (AK1.1) eventCausalityID EventCausality eventID Event datetime eventTypeID EventCausality_cause eventCausalityID (FK) causeEventID (FK) EventCausality_effect eventCausalityID (FK) effectEventID (FK) eventTypeID EventType eventTypeName (AK1.1) eventGeneralizationID (FK) 132 Chapter 10 / Archetypes Figure 10.19 Archetype Flight: UML model. A Flight is the travel by an airline between airports. modelNumber {unique} manufacturer AircraftModel PublishedFlight frequency effectiveDate airlineCode {unique} airlineName Airline * 1 0 11 expirationDate flightNumber PublishedFlightLeg scheduledDepartureTime scheduledDuration ActualFlightLeg actualDepartureTime actualDuration 1 {ordered} * departureDate 0 1 * * 1 1 scheduledOrigin scheduledDest tailNumber {unique} Aircraft actualOrigin actualDestination11 * * 1 * 1 * iataCode {unique} airportName Airport * {ordered} Figure 10.20 Archetype Flight: IDEF1X model. publishedFlightID PublishedFlight frequency effectiveDate expirationDate aircraftModelID (FK) airlineID (FK) (AK1.1) flightNumber (AK1.2) publishedFlightLegID PublishedFlightLeg scheduledDepartureTime scheduledDuration publishedFlightID (FK) (AK1.1) sequenceNumber (AK1.2) scheduledOrigin (FK) scheduledDestination (FK) actualFlightLegID ActualFlightLeg actualDepartureTime actualDuration publishedFlightLegID (FK) (AK1.1) departureDate (AK1.2) sequenceNumber (AK1.3) airlineID Airline airlineCode (AK1.1) airlineName aircraftModelID AircraftModel modelNumber (AK1.1) manufacturer aircraftID Aircraft tailNumber (AK1.1) aircraftModelID (FK) airportID Airport iataCode (AK1.1) airportName actualOrigin (FK) actualDestination (FK) aircraftID (FK) 10.11 Item 133 10.11 Item An Item is a part or a service (Figure 10.21, Figure 10.22). A RenderedService is a group of tasks that are performed. In Section 10.14 many PhysicalParts can correspond to a Catalog- Par t. Similarly many RenderedServices can correspond to an OfferedService. An example of an OfferedService is a business audit. Corresponding RenderedServices would be business audits performed on particular dates. A physical item can break down into lesser physical items, leading to a decomposition tree. The parent–child relationship on PhysicalItem is redundant with the Contains relationship of PhysicalPart (Section 10.14). If PhysicalItem and PhysicalPart are in the same model, you should omit the Contains relationship on PhysicalPart. The PhysicalItem decomposition is broader in scope and subsumes PhysicalPart decomposition. Section 10.14 shows relationships for CatalogPart and PhysicalPart. RenderedService Figure 10.21 Archetype Item: UML model. An Item is a part or a service. PhysicalItem parent child * 0 1 quantity startDatetime PhysicalPart OfferedService name CatalogPart 0 1 * endDatetime CatalogItem Figure 10.22 Archetype Item: IDEF1X model. catalogItemDiscrim catalogItemID CatalogItem catalogItemDiscrim OfferedService offeredServiceID (FK) offeredServiceName CatalogPart catalogPartID (FK) physicalItemDiscrim physicalItemID PhysicalItem physicalItemDiscrim RenderedService renderedServiceID (FK) startDatetime PhysicalPart physicalPartID (FK) endDatetime offeredServiceID (FK) . . . . . . parPhyItem_childPhyItem childPhyItemID (FK) quantity parentPhyItemID (FK) . 10.17, Figure 10.18). The notion of an event often appears in application models. An EventType is a general category of Events. This archetype involves data and metadata and uses the shading convention. the definition of events by their similarities and differences using generalization. There is also a simple model of cause and effect. A group of causes might lead to a group of effects. By multiple. group of tasks that are performed. In Section 10.14 many PhysicalParts can correspond to a Catalog- Par t. Similarly many RenderedServices can correspond to an OfferedService. An example of an OfferedService