Conformed Dimensions and Inheritance
One specialised and high profile aspect of any organisations enterprise data architecture is the delivery of data for analysis and reporting purposes. This is known in the industry as data warehousing and business intelligence. A common data structure used within this area are dimensional data structures. One particular dimensional data structure concept that is often used albeit rather poorly is the conformed dimension principle (I’ve called this a principle as that the way I have always seen it).
The concept of conformed dimensions is that it makes sense to design one instance of a dimension and re-use when ever this dimension is required. For example if we have a person dimension that person dimension would be used every time we need either an employee dimension, a customer dimension or a contact dimension etc, etc. This provides us with a level of consistency in design which means we gain benefit from the user interpretation perspective as well as the physical implementation angle.
An extension to this concept that I often adopt is to add into the mix the concept of inheritance. This work in a very similar way as before but instead of having separate dimensions for for customer, contact and employee that all share the same structure we create one single parent dimension called PERSON that has all the person data and we create sub types called CUSTOMER, CONTACT and EMPLOYEE that are either views or materialised views (or the alternative for a non Oracle databases). The PERSON dimension may look something like the following:
The example above has a series of indicators that all the view to quickly identify if the PERSON falls into a specific type of person. The views don't need to include the indicators when implemented as sub type conformed dimensions.
The concept of conformed dimensions is that it makes sense to design one instance of a dimension and re-use when ever this dimension is required. For example if we have a person dimension that person dimension would be used every time we need either an employee dimension, a customer dimension or a contact dimension etc, etc. This provides us with a level of consistency in design which means we gain benefit from the user interpretation perspective as well as the physical implementation angle.
An extension to this concept that I often adopt is to add into the mix the concept of inheritance. This work in a very similar way as before but instead of having separate dimensions for for customer, contact and employee that all share the same structure we create one single parent dimension called PERSON that has all the person data and we create sub types called CUSTOMER, CONTACT and EMPLOYEE that are either views or materialised views (or the alternative for a non Oracle databases). The PERSON dimension may look something like the following:
| PERSON IDENTIFIER |
| FORENAME |
| FAMILY NAME |
| TELEPHONE NUMBER |
| …… |
| CUSTOMER INDICATOR |
| EMPLOYEE INDICATOR |
| CONTACT INDICATOR |
The example above has a series of indicators that all the view to quickly identify if the PERSON falls into a specific type of person. The views don't need to include the indicators when implemented as sub type conformed dimensions.
Comments
Post a Comment