Our Strategy : Creating the Enterprise Entity Model for an Enterprise Data Warehouse

The enterprise entity model required for an enterprise data warehouse is not the same as that required for an operational system. In it, entities do not need to map directly to the elements that are used in the actual business process. Rather, this type of enterprise entity model is defined on the principle that if information is required, this need can be defined. 


In operational system enterprise entity models, there can be no correctness or coherence without completeness, but in the enterprise entity model required for an enterprise data warehouse, only internal coherence is required. Completeness is defined by the intended use of the database and correctness arises as a function of internal coherence. Adopting this philosophy when defining the enterprise entity model for the enterprise data warehouse, allows the process to be kept simple initially, but it does not preclude the option of adding complexity at later stages. 


The first version, for example, may be defined at a very high level of consolidation corresponding to the detail in the initial business requirements for the enterprise data warehouse. These may be subsequently expanded to finer and finer levels of detail as required. In this way, building the enterprise entity model leads the investigation which leads to a more fully exploded picture of the enterprise data warehouse requirements. This can be thought of as an iterative, top down process. The iterative process of exploding the enterprise entity model into finer levels of detail and greater degrees of complexity is one in which revisions may be checked against available data sources such as the high level management reports typically found in spreadsheet format. 


When the enterprise entity model has been fully expanded to the level to which corporate reporting refers to line of business level detail (that is the top level of line of business specific management reports), sufficient knowledge is available to design an enterprise database. This database may be populated with data from available sources, even if these are mostly paper-based, and can then be validated by producing further reports and matching these against available management reports. 


Once such a layer of the enterprise entity model has been verified by this type of cross checking, and found to be both correct and useful, then further drilling to a lower level of detail and increased complexity may be specified. 
Although it is necessary to define each level in the enterprise entity model of warehouse design, it is often not possible to design and populate each corresponding level of the associated data warehouse simultaneously. 
Frequently, only data the highest levels of consolidation are available for some lines of business while data for other lines of business are available at varying degrees of detail. It is in this de-coupling, that the enterprise entity model of warehouse design reveals its merit. The user can design, build and start utilising an enterprise data warehouse very rapidly, getting access to more and more detail as the data structures are put in place.


It is a corporate reality that enterprise data warehouses take time to develop and populate and if it was necessary to wait for all the data to become available prior to exploiting such a warehouse, in many instances these would never be developed.

Testimonials
To follow...
 
Clients
  • MTN
  • Santam
  • Absa
  • Old Mutual
All Our Clients
Case Studies
  • Old Mutual
  • Santam
  • Absa
  • CSC
  • Uskotec
  • MTN
  • South African Airways
  • Vyinde
More Casse Studies
 
Newsfeed
The 500 Year Delta

"The Information Age...is dead and gone, replaced by the information economy...The Information Age was about the building of databases. It was about the rise of…

Read More