VDM Public

Public information; No registration required

Core Framework

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:

  • Base Facts
  • Aggregates
  • Dimensions
  • Reference Information
  • Semantic and Operational Metadata
  • Provisioning Layer
  • Access Layer
  • Physical Architecture
VDM Access: 
VDM Public

VDM Architecture Principles

Modular organization along behavior boundaries
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.
VDM Access: 
VDM Public

Year-to-Year Comparison Behavior

VDM Access: 
VDM Public

Administrative behaviors

VDM Access: 
VDM Public

How General should Facts be in the Database

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.

VDM Access: 
VDM Public

Time-Versioned Behavior

VDM Access: 
VDM Public

Hierarchical Behavior

VDM Access: 
VDM Public

Abstract Behaviors

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.

VDM Access: 
VDM Public

Cube Design

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.

Here are some special topics around fact design:

VDM Access: 
VDM Public

Balances, Differential Facts & Inventory History

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.

VDM Access: 
VDM Public

Pages