Enhanced Strategy - Speed Objects

The main principle behind this modelling strategy is to move as much as possible, the processing requirements to the batch process (run once) and away from the presentation process (run many, often and on demand).

This way we improve performance of batch processing and final consumer presentation.

Again object relationships considered as Type 1 are handled more than adequately by this strategy.

Whereas object relationships considered as Type 2 fall somewhat shorter than the ideal due to the requirement for temporal lookup in either batch or presentation.

The strategy of lookup once is not perfect but the more resource frugal – however maintenance of late reference data is an issue.

The implementation of speed objects may go some way to alleviating the downsides of Type 2 objects

A speed object is an object that is rebuilt at batch time either in its entirety or just for events in said batch – whichever is the more relevant.

Let us look again at the example that caused us an issue before

If rather than looking up the AccDHGen we instead used the epoch (date level for ease) of the tax point.

This as with Type 1 consideration is a total disconnect of fact and dimensional objects in batch processing.

We have previously seen the Account object using epoch of instance rather than simple generation

A possible speed object for these two fact and dimensional objects would have the elements DHkey, Generation, TPEpoch

This speed table provides an equality relationship between the fact object and itself and an equality relationship between itself and the dimensional object.

The relationship between this speed object and the fact object may be one to many or one to one and the dimensional object would be one to one.

This strategy eliminates any temporal range based relationship in the presentation layer improving the efficiency of presentation layer and the resolution of final consumer queries.

As this is fact data driven (as with the buckets and dummies) a practical implementation would be to utilize the bucket expanding it to contain the epoch element of the fact instances.

The bucket now has two uses

• To identify failed relationships and generate a dummy instance for referential integrity

• To build a speed table in the case of a relationship considered to be of Type 2.

The bucket contains all the fact object keys produced by the current batch so in its simplest form the strategy would be to add new instances to the speed object for contents of the bucket.

This does require a range relationship in the processing – but this is a one-time batch process rather than a many times presentation process.

Assuming the Dimensional object has completed processing and the presentation objects have been generated

This results in the instances to be inserted into the speed object for the fact instances processed in the current batch.

Care must be taken to avoid duplication of instances in the speed object and the elimination of bad or outdated references.

It may be of some value to recreate the speed table from scratch should processing and batch contingency allow.

Contents   Next