Identifying the dimensions

The dimensions to be related to the fact table are a natural byproduct of the grain chosen in step 2 and thus largely impact the decision in step 2. A single sample row from the fact table should clearly indicate the business entities (dimensions) associated with the given process such as the customer who purchased an individual product on a certain date and at a certain time via a specific promotion. Fact tables representing a lower grain will have fewer dimensions. For example, a fact table representing the header level of a purchase order may identify the vendor but not the individual products purchased from the vendor:

  • Identify and communicate the dimensions that can be used to filter (aka slice and dice) each business process:
    • The foreign key columns based on the grain chosen in the previous step reference dimension tables.
    • Review a sample of all critical dimension tables, such as Product or Customer, and ensure these tables contain the columns and values necessary or expected.
  • Communicate which dimensions can be used to filter multiple business processes simultaneously:
    • In this project, the Product, Sales Territory, and Date dimensions can be used to filter all three fact tables. 
    • The data warehouse bus matrix referenced earlier can be helpful for this step
  • Look for any gap between the existing dimension tables and business questions or related reports:
    • For example, existing IT-supported reports may contain embedded logic that creates columns via SQL which are not stored in the data warehouse
  • Strive to maintain version control for dimension tables and the columns (attributes) within dimension tables:
    • It may be necessary for project stakeholders to adapt or migrate from legacy reports or an internally maintained source to the Corporate BI source

A significant challenge to the identity of the dimensions step can be a lack of Master Data Management (MDM) and alternative versions. For example, the sales organization may maintain their own dimension tables in Excel or Microsoft Access and their naming conventions and hierarchy structures may represent a conflict or gap with the existing data warehouse. Additionally, many corporate applications may store their own versions of common dimensions, such as products and customers. These issues should be understood and, despite pressure to deliver BI value quickly or according to a specific business team's preferred version, the long-term value of a single definition for an entire organization as expressed via the bus matrix should not be sacrificed.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.175.253