The VDM core elements discussed below comprise the basic architectural elements to construct an elementary but complete multidimensional design. These same elements define the aspects of our design pattern implementations:
Transitioning from analysis to design is the most vulnerable phase of the lifecycle. Under time pressure, often inadequately detailed or over-detailed requirements are directly translated to disjoint design artifacts. VDM provides a framework of core and optional semantic constructs and behaviors. These modular elements easily map to requirements and are supported by pre-elaborated implementations we call design patterns. Two premises we accept are
Requirements will evolve and change
Assembling and adapting well understood design patterns reduces defects and avoids the "afterthought design" syndrome.
When certain abstract behaviors are added to the system, the fact taxonomy automatically extends to include more specializations. Let's take the sales fact as an example: When we add the TY/LY comparison behavior, we autmatically break down Sales to TY_Sales, LY_Sales and possibly PY_Sales corresponding to this year, last year and the prior year respectively. Now consider introducing the Relocation behavior and each of these categories of sales are further subdivided into regular and relocated store sales, leading to six distinct metrics. If we bring in the Same-Store Sale distinction the Relocated Store Sales are further broken down to SSS_Sales and Non-SSS-Sales.
An abstract behavior delivers a narrow slice of functionality, it is associated with a design pattern that implements this functionality, and can be combined with other compatible such patterns to deliver more complex behavior. As a typical example, one can add "time versioning" and "hierarchical" behaviors to a dimension to derive a versioned hierarchical dimension. The design pattern of each of these behaviors not only defines the structural extensions required, but also maintenance functionality, the appropriate hooks to properly associate them with base and aggregate facts, as well as appropriate extensions to access view definitions and other mechanisms.
Fact design cannot be addressed in isolation. It should always be views as a part of "cube design" working in conjunction with the relevant dimensions, aggregations and other facts to accommodate their integration through simple access constructs.
A long history of inventory snapshots by product-location or of financial positions by book/account-CUSIP can be very large, costly to maintain and inefficient to query. Storing differences from day-to-day rather than the complete snapshot reduces the volume if only a few of the products or positions are affected from day to day. In a typical retail situation, about 10% of the inventory changes in a day, making such a differential approach appealing. In financial systems, a much smaller number of position changes each day, however it is common to include value of the position as a metric, resulting in nearly all positions changing daily. For those systems a differential approach would make sense only if query-time valuation can be included and proves cost-effective.