5.2 Homomorphism Template 81 Normally there is one ActualFlightLeg for a PublishedFlightLeg and departureDate, but flight problems can lead to multiple ActualFlightLegs. An AircraftModel is a standard kind of aircraft, such as a Boeing 727. An Aircraft is a physical specimen of an AircraftModel and is uniquely identified with its tail number. Figure 5.13 has three occurrences of the item description template. • PublishedFlightLeg to ActualFlightLeg • AircraftModel to Aircraft • SeatDescription to Seat The example has one homomorphism. • AircraftModel to Aircraft corresponds to SeatDescription to Seat. Figure 5.14 extends the model of Figure 5.8 and shows another homomorphism. ReportDef- inition relates to ReportExecution. ReportDefinitions have Va ri a bl e s; each Var i ab l e is as- signed a Va lue for a ReportExecution. Figure 5.15 extends the model of Figure 5.6 resulting in two homomorphisms, one with vehicle and event and the other with event and task. A tune-up is an example of a Re- pairEventType. The replacement of spark plugs, replacing points, and setting the timing are examples of RepairTaskType. * 1 * 1 * 1 0 11 flightNumber ActualFlightLeg actualDepartureTime actualDuration 1 {ordered} * departureDate 0 1 * * 1 1 origin destination tailNumber Aircraft origin destination11 * * 1 * 1 * airlineCode airlineName Airline iataCode airportName Airport PublishedFlight frequency effectiveDate expirationDate modelNumber manufacturer AircraftModel PublishedFlightLeg scheduledDepartureTime scheduledDuration SeatDescription seatNumber seatType Seat 1 * Figure 5.13 Homomorphism: Flight model. Metadata Data FlightReservation fareCode ** 1 0 1 * {ordered} 82 Chapter 5 / Item Description Template 5.3 Chapter Summary The item description template arises when a model relates data and metadata. There is one template for item description and the template frequently occurs. The homomorphism template maps between two Item Description templates and ex- presses an analogy. The description of item 1 is to item 1 as the description of item 2 is to item 2. The relationship between items connects occurrences. The relationship between de- scriptions constrains occurrences. There is one template for homomorphism that occasion- ally occurs. Table 5.2 summarizes the item description and homomorphism templates. Figure 5.14 Homomorphism: Report model. ReportDefinition name ReportExecution creationDatetime Variable name Value value 1 1 1 * * * Metadata Data Person name 1 * creator 1 * RepairEventType name 1 PhysicalVehicle RepairEvent date ** VehicleModel name year vehicleIdentificationNumber RepairTaskType name ** {ordered} * RepairTask 1 * 1 * 1 * 1 * Metadata Data vehicleMileage isForWarranty description Figure 5.15 Homomorphism: Vehicle model. Company name address 1 * manufacturer Bibliographic Notes 83 Bibliographic Notes [Coad-1992] also associates an item with its description. [Rumbaugh-1991] discusses homomorphisms as part of advanced modeling. Section 2.5 of [Fowler-1997] does not mention the term homomorphism, but Fowler also distin- guishes between metadata and data layers. He structures his model in a manner that shows the symmetry. References [Coad-1992] Peter Coad. Object-oriented patterns. Communications ACM 35, 9 (September 1992), 152–159. [Fowler-1997] Martin Fowler. Analysis Patterns: Reusable Object Models. Boston, Massachusetts: Addison-Wesley, 1997. [Rumbaugh-1991] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Englewood Cliffs, New Jersey: Prentice Hall, 1991. Template name Synopsis UML template Use when Frequency Item description Relates data and metadata in the same model. The same model relates data and metadata. Frequent Homomor- phism Expresses an analogy between two item descrip- tion templates. Item description templates are involved in an analogy. Occasional Table 5.2 Summary of the item description and homomorphism templates Note: Consider these templates when a model has both data and metadata. 84 6 Star Schema Template The star schema represents data as facts that are bound to dimensions. A fact measures the performance of a business or some aspect of a business; examples include sales, budget, rev- enue, profit, and inventory. A dimension specifies one of the bases for facts; examples in- clude date, location, product, customer, and salesperson. The star schema is the usual approach to data warehouse applications. A data warehouse takes the disjointed, functional applications of a business and integrates them, putting their data in one database and storing data in a common format for reporting purposes. The simple structure of the star schema makes it easier to write ad-hoc queries that mine data and gain insight into an enterprise. However, the simple structure cannot enforce constraints about data—that is the purpose of the functional applications that handle the day-to-day operations of a business. The star schema is not limited to data warehouses and can also be used for functional applications with much reading and little writing. There is one template for the star schema. 6.1 Star Schema Template 6.1.1 UML Template Figure 6.1 shows the UML template for the star schema. A fact is surrounded by dimensions. The diagram happens to show eight dimensions, but there can be any number of dimensions. [Kimball-1998] suggests that a fact should have between five and fifteen dimensions for a well-designed star schema. Most dimensions are mandatory but some can be optional. 6.1 Star Schema Template 85 6.1.2 IDEF1X Template Figure 6.2 restates Figure 6.1 with the IDEF1X notation. All the dimension IDs in Fact are foreign keys. The dimension foreign keys are specified to be mandatory to simplify database joins. There is no conflict between the UML and IDEF1X templates, as a conceptual NULL can be indicated with a special “NONE” record. The combination of dimensions identifies each fact and is used as the primary key to reduce fact table size. Figure 6.1 Star schema: UML template. Use when there must be a flexible structure for querying data and constraints on data are unimportant. ** * * * * 1 0 1 0 1 0 1 <Fact> <Dimension6> <Dimension3> <Dimension7> <Dimension2><Dimension1> <Dimension8> 1 <Dimension5> * 0 1 0 1 <Dimension4> * 0 1 0 1 0 1 Figure 6.2 Star schema: IDEF1X template. dimension1ID (FK) Fact dimension2ID (FK) dimension3ID (FK) dimension4ID (FK) dimension5ID (FK) dimension6ID (FK) dimension7ID (FK) dimension8ID (FK) dimension1ID data Dimension1 dimension2ID data Dimension2 dimension3ID data Dimension3 dimension4ID data Dimension4 dimension6ID data Dimension6 dimension5ID data Dimension5 dimension7ID data Dimension7 dimension8ID data Dimension8 data . (FK) dimension1ID data Dimension1 dimension2ID data Dimension2 dimension3ID data Dimension3 dimension4ID data Dimension4 dimension6ID data Dimension6 dimension5ID data Dimension5 dimension7ID data. approach to data warehouse applications. A data warehouse takes the disjointed, functional applications of a business and integrates them, putting their data in one database and storing data in a. UML template Use when Frequency Item description Relates data and metadata in the same model. The same model relates data and metadata. Frequent Homomor- phism Expresses an analogy between