1. More Dimensional Modeling

2. Facts

3. Types of Fact Design Transactional Periodic Snapshot –Predictable time period –Ex. Monthly, yearly, etc. Accumulating Snapshot –Needs updating, many dates –Ex. Application Process

4. Factless Fact Tables Events –Track combination of dimension values for a given occasion –Ex. Event Attendance Coverage –Track a status for a given amount of time –Ex. Facilities Usage

5. Changing Facts New measured facts (assumed same grain) –Alter fact table and then populate –If alter table not viable, create 2 nd fact table with old and new columns and then populate –If available from a particular point, then null or “not available” –If different grain, most likely different fact table

6. Dimensions

7. Changing Dimensions Handling Slowly Changing Dimensions –Overwrite –Add new dimension row –Add new dimension column If predictable, add as many columns –Hybrid

8. Changing Dimensions New dimension attributes –Add column to dimension table –“not available” if available only after a specific time New dimensions –Add new table –Add column to fact table containing foreign key and populate with correct dimension primary key values

9. Changing Dimensions Dimension becoming more granular –More granular dimensions mean more granular fact tables –Rebuild fact tables New data source involving new and existing dimensions –New source of data will have own granularity and dimensionality –Avoid force-fitting, create new fact table

10. Design Considerations

11. Extensability Design for change –Changes in business –Data not yet available but needed in the future Review Retail example –How to extend?

12. Extensibility Retail example –Customer dimension (Frequent shopper) –Clerk Dimension –Time of Day Dimension –Market Basket Analysis

13. Avoid Normalizing dimensions –More complex representation for users –More tables and joins = slower query performance (users) = harder db optimization (db optimizer) –Minor space savings –Defeats use of bitmap indexes

14. Avoid Too many dimensions –Fact table with too many dimensions will take up too much space –Usability and query performance issues –Less than 15 dimensions for business process –Hierarchies are lumped into 1 dimension

15. Avoid Relying on operational codes –Operational codes = smart keys –Use surrogate keys instead –Surrogate keys buffer DW from operational changes –Easier consolidation from different source areas despite different source keys –Can handle “not available” or “not applicable” keys –Space