[ Pobierz całość w formacie PDF ]
.The dimensionscome from the classification of this focal event, which is the fact table of a starschema [4].In determining the dimensions to use in this kind of analysis, first we need tounderstand what the focal event is.We can then look at the ways in which thisfocal event can be classified.From Figure 4.2 we see the focal event involves aproduct that has a product family, which has a product group, which has abeverage.On the sales dimension we see area, region, and market.These dimensions and levels should be defined by business analysts; Figure4.6 shows a good way to do this.As Figure 4.6 indicates this structure canbecome quite complex.The dimensions are not necessarily completelyindependent.For example, note how the price range dimension intersects theproduct dimension.This indicates that any product will have one particularparent along the product and price range dimensions.The model of Figure 4.5would need to be modified to take this into account properly, although it isquestionable whether it is worth undertaking this since it does complicate themodel somewhat.This issue could be handled by the dimension creation process.64 Enterprise SegmentFigure 4.6 A Tilak chart showing a typical set of dimensions and levels.This is a useful diagram providing we do not have more than six branches from any level.In practice we rarely do.The dimensions need not be measurable to the lowest level.In this case itmight not be worthwhile, or even possible, to analyze down to an individualsalesperson's territory or to an individual customer.In this case the dimensionsare elaborated part of the way down to the underlying event.It is still useful tounderstand what the lower levels are, both for future development and to see thefoundations of the higher levels.A full analysis of the customer's domain would involve producing a businessmodel for the customer's area.This would include a structural model, whichwould be used to rigorously define the dimensions.Each dimension shouldrepresent a hierarchical path along the structural model.The details of thisprocess are beyond the scope of this chapter.For the sake of discussion we willassume the dimensions have been determined.The dimensions can be defined explicitly by the user of the analysis system.Otherwise, they can be determined from corporate databases.For the latter, eachdimension needs a builder operation to tell it how to query corporate databases.This allows the system to add nodes to the dimension over time.4.1.2 Properties of Dimensions and Enterprise SegmentsAn important rule about dimensions is that the measurements for dimensions atlower levels can be properly combined into the higher level.Thus if we want tolook at sales revenue for the Northeast, we can do this by adding together thevalues for sales for all subregions of the Northeast region.Observations for Corporate Finance 65Any dimensions that are defined must support this property.Usually dimensionsare combined through addition, but there are some exceptions (see Section 4.2.5).Along with dimensions defined through business structures, another commondimension is time.Time is treated as a dimension by classifying the underlyingevent into a time period.If these periods are months then we can talk about suchfigures as revenue for (11-10, Northeast, March 1994).This implies a dimensionelement for March 1994 that would be a child of the dimension element for 1994.The time dimension satisfies the combinability property discussed above,providing the figures are only for that month (and not year-to-date figures).Wecan easily calculate year-to-dates from month-only figures but typically not bycombining along a dimension.Enterprise segments share an interesting property with more fundamentaltypes: All enterprise segments conceptually exist.There is no notion of con-ceptually creating the number 5, the quantity $5, or the date 1/1/2314.Thesethings all exist in our minds but may need to be created as objects in the computer.Enterprise segments share this property.Once all dimensions have been specifiedwith their dimension elements, then all enterprise segments conceptually exist,although they may not be created as software objects.This shared property raises the question of whether an enterprise segmentshould be treated as a fundamental type (see Section A.1.5).If so, it should nothave any mappings to nonfundamental objects.A dimension element and anobservation (inherited from an object of care) are both non -fundamental [ Pobierz całość w formacie PDF ]