Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.


Share this Page URL
Help

6.4.6. Deriving a fact model from a data... > 6.4.6. Deriving a fact model from a ... - Pg. 177

156 CHAPTER 6 Fact models Given the highly intensive and iterative nature of this process, do not use a repository tool during workshops. A spreadsheet not only provides significantly faster data entry and modification facilities but also requires significantly less effort in tidying up outputs for presentation back to stakeholders. Once the taxonomy is reasonably stable, it can be imported into a repository. 6.4.4 Taxonomy publication The best way to ensure acceptance of the taxonomy is to make it widely available to stakeholders, easy to access and easy to provide feedback. Wiki-style media are ideal for this. Feedback may include pro- posed changes to definitions (and possibly even terms), or reclassification of terms within the taxon- omy, as stakeholders develop more understanding of the set of terms and their meanings. 6.4.5 Discovering fact types In my experience, the most useful approach to discovering fact types is to consider in turn each pair of top-level concepts, such as party and location. What are the associations of interest between various types of parties and locations? For example: F102. F103. F104. F105. F106. person was born in country person is citizen of country person resides at address organization operates at address employee works at branch This should be repeated for each pair. Don't overlook associations between parties and other parties, or locations and other locations, such as F107. F108. F109. F110. F111. F112. F113. F114. organization employs person employee reports to employee organization is part of organization person is married to person person is parent of person address is in city city is in state state is in country 6.4.6 Deriving a fact model from a data model If up-to-date data models are already in use, they may be able to be used as sources of terms and fact types by applying the correspondences documented in Section 6.5.1. This may, however, not be as easy as it sounds, since many data models use entity class and attribute names that are abbreviated and/or cryptic rather than reflecting business terminology. If that is the case, each business term created from examination of the data model should be mapped to the corresponding entity class name or attribute name (in reality, often a database table or column name). This mapping is best recorded against the term in the fact model repository rather than in the data model. This is for two reasons: