PATTERNS OF DATA MODELING- P21 doc

Figure 5.13 has three occurrences of the item description template.. 5.3 Chapter SummaryThe item description template arises when a model relates data and metadata.. The homomorphism tem

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 ReportDefReportDef-initions have Variables; each Variable is as-signed a Value 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

0 1 1

flightNumber

ActualFlightLeg

actualDepartureTime actualDuration

1 {ordered}

*

departureDate 0 1

*

*

1

1

origin

destination

tailNumber

Aircraft

origin 1 1 destination

*

*

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}

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

date

VehicleModel

name

year

vehicleIdentificationNumber

RepairTaskType

name

{ordered}

*

RepairTask

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

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.

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