Presentation on theme: "Dimension Modeling Techniques"— Presentation transcript:
1Dimension Modeling Techniques DW ConceptsDimension Modeling TechniquesMilena GerovaProject ManagerTechnoLogica Ltd.3, Sofiisko Pole Str. tel: (+ 3592) (ten lines)
2TechnoLogica DW Projects Business Management System National Health Insurance Fund ( – current)Customer Data Integration Allianz Bulgaria Holding ( – current)Regulatory Reporting System BULBANK ( )Information System Monetary Statistics Bulgarian National Bank (April 2003 – August 2004)Management Information System BULBANK (January June 2002)
3Agenda DW Terminology Overview Dimensional Modeling Dimension Types History and DimensionsHierarchy in Dimensions
4The data warehouse must Make an organization’s information easily accessible.Present the organization’s information consistently.Be adaptive and resilient to changeBe a secure bastion that protects our information assets.Serve as the foundation for improved decision makingThe business community must accept the data warehouse if it is to be deemed successful.
6Dimensional ModelingDimensional modeling is a new name for an old technique for making databases simple and understandableDimensional modeling is quite different from third- normal-form (3NF) modelingERM ->The Transaction Processing ModelOne table per entityMinimize data redundancyOptimize updateDM -> The data warehousing modelOne fact table for a process in the organizationMaximize understandabilityOptimized for retrievalResilient to change
8Four-Step Dimensional Design Process 1. Select the business process to model.2. Declare the grain of the business process.3. Choose the dimensions that apply to each fact table row.4. Identify the numeric facts that will populate each fact table row.
9DimensionsDetermine these by the ways you want to slice and dice the dataSmall number of rows compared to factsUsually 5-10 dimensions surrounding a fact tableTime is almost always a dimension used by every factTrack historyUses Surrogate KeysHierarchies are usually built into them if possible
10Date DimensionThe date dimension is the one dimension nearly guaranteed to be in every data martDate Dimension = Time Dimension beforeWe can build the date dimension table in advance (5-10 years -> only 3,650 rows)
13Date DimensionData warehouses always need an explicit date dimension table. There are many date attributes not supported by the SQL date function, including fiscal periods, seasons, holidays, and weekends. Rather than attempting to determine these nonstandard calendar calculations in a query, we should look them up in a date dimension table.select sum(f.amount_sold) from DATE_DIM d, FACT f where d.Calendar_Month = ‘January’ and d.id = f.date_dim_id;
17Dimension Normalization (Snowflaking) The dimension tables should remain as flat tables physically.Normalized, snowflaked dimension tables penalize cross-attribute browsing and prohibit the use of bit-mapped indexes.Disk space savings gained by normalizing the dimension tables typically are less than 1 percent of the total disk space needed for the overall schema
19Too Many DimensionsA very large number of dimensions typically is a sign that several dimensions are not completely independent and should be combined into a single dimension.If our design has 25 or more dimensions, we should look for ways to combine correlated dimensions into a single dimensionIt is a dimensional modeling mistake to represent elements of a hierarchy as separate dimensions in the fact table.
20Surrogate KeysEvery join between dimension and fact tables in the data warehouse should be based on meaningless integer surrogate keys.You should avoid using the natural operational production codes. None of the data warehouse keys should be smart, where you can tell something about the row just by looking at the key.
21Surrogate KeysSurrogate keys are like an immunization for the data warehouseBuffer the data warehouse environment from operational changesPerformance advantages The smaller surrogate key translates into smaller fact tables, smaller fact table indices, and more fact table rows per block input-output operationSurrogate keys are used to record dimension conditions that may not have an operational code “No Promotion in Effect”, “Date Not Applicable.”
22Surrogate KeysThe date dimension is the one dimension where surrogate keys should be assigned in a meaningful, sequential orderSurrogate keys are needed to support one of the primary techniques for handling changes to dimension table attributesDon’t use concatenated or compound keys for dimension tables
25Conformed DimensionsMost dimensions are defined naturally at the most granular level possibleConformed dimensions are either identical or strict mathematical subsets of the most granular, detailed dimensionThey have consistent dimension keys, consistent attribute column names, consistent attribute definitions, and consistent attribute valuesThe conformed dimension may be the same physical table within the database or may be duplicated synchronously in each data mart
26Conformed DimensionsRoll-up dimensions conform to the base-level atomic dimension if they are a strict subset of that atomic dimension.
27Conformed Dimensions They should be built once in the staging area They must be published prior to staging of the fact dataThe dimension authority has responsibility for defining, maintaining, and publishing a particular dimension or its subsets to all the data mart clients who need it
28Tracking History in Dimensions Unchanging DimensionsChanging, but Original Values are Irrelevant A phone number in a customer recordSlowly Changing Dimensions (SCD) A customer address, managerRapidly Changing Dimensions Income range of a customerContinuously Changing Dimensions Customer age
29Type 1: Overwrite the Value The type 1 response is easy to implement, but:it does not maintain any history of prior attribute valuesany preexisting aggregations based on the department value will need to be rebuilt
30Type 2: Add a Dimension Row The type 2 response is the primary technique for accurately tracking slowly changing dimension attributes. It is extremely powerful because the new dimension row automatically partitions history in the fact table.It’s not suitable for dimension tables that already exceed a million rows
32Type 3: Add a Dimension Column The type 3 slowly changing dimension technique allows us to see new and historical fact data by either the new or prior attribute values.
33Hybrid SCD Techniques Series of Type 3 Attributes Predictable Changes with Multiple Version OverlaysReport each year’s sales using the district map for that year.Report each year’s sales using a district map from an arbitrary different year.Report an arbitrary span of years’ sales using a single district map from any chosen year. The most common version of this requirement would be to report the complete span of fact data using the current district map.
34Hybrid SCD Techniques Type 2 with "Current" Overwrite Unpredictable Changes with Single-Version Overlay preserves historical accuracy while supporting the ability to report historical data according to the current values
37Degenerate DimensionDimension keys without corresponding dimension tablesOperational control numbers such as order numbers, invoice numbers, and bill-oflading numbers usually give rise to empty dimensionsDegenerate dimensions are stored in the fact tables where the grain of the table is the document itself or a line item in the document
38Junk Dimensions What to do with flags and indicators Leave the flags and indicators unchanged in the fact table row.Make each flag and indicator into its own separate dimensionStrip out all the flags and indicators from the design.A junk dimension is a convenient grouping of typically low-cardinality flags and indicators
39Junk Dimensions Whether to use junk dimension 5 indicators, each has 3 values -> 243 (35) rows5 indicators, each has 100 values -> 100 million (1005) rowsWhen to insert rows in the dimension
41Customer Dimension Critical element for effective CRM The most challenging dimension for any data warehouseextremely deep (with millions of rows)extremely wide (with dozens or even hundreds of attributes)sometimes subject to rather rapid change
43Customer Dimension Other Common Customer Attributes GenderEthnicityAge or other life-stage classificationsIncome or other lifestyle classificationsStatus (for example, new, active, inactive, closed)Referring sourceBusiness-specific market segmentScores characterizing the customer, such as purchase behavior, payment behavior, product preferences
44Customer Dimension Aggregated Facts as Attributes These attributes are to be used for constraining and labeling; they are not to be used in numeric calculationsFocus on those which will be used frequentlyMinimize the frequency with which these attributes need to be updatedReplace metrics with more meaningful descriptive values, such as “High Spender”
45Dimension Outriggers for a Low-Cardinality Attribute Set
46Rapidly Changing Customer Dimensions ChallengesIt generally takes too long to constrain or browse among the relationships in such a big tableIt is difficult to use previously described techniques for tracking changes in these large dimensionsOne solution is to break off frequently analyzed or frequently changing attributes into a separate dimension, referred to as a minidimension
47Rapidly Changing Customer Dimensions The Mini Dimension with "Current" Overwrite
48Rapidly Changing Customer Dimensions The minidimension terminology refers to when the demographics key is part of the fact table composite keyIf the demographics key is a foreign key in the customer dimension, we refer to it as an outrigger
49Rapidly Changing Customer Dimensions Type 2 with Natural Keys in Fact Table
50Implications of Type 2 Customer Dimension Changes Be careful to avoid overcounting because we may have multiple rows in the customer dimension for the same individualCOUNT DISTINCTA most recent row indicatorThe comparison operators depend on the business rules used to set our effective/expiration dates.
51Customer Behavior Study Groups Capture the keys of the customers or products whose behavior you are tracking
55Commercial Customer Hierarchies Be aware of risk of double countingSELECT 'San Francisco', SUM(F.REVENUE) FROM FACT F, DATE D WHERE F.CUSTOMER_KEY IN (SELECT B.SUBSIDIARY_KEY FROM CUSTOMER C, BRIDGE B WHERE C.CUSTOMER_KEY = B.PARENT_KEY AND C.CUSTOMER_CITY = 'San Francisco') //to sum all SF parents AND F.DATE_KEY = D.DATE_KEY AND D.MONTH = 'January 2002‘ GROUP BY 'San Francisco'
58Common Dimensional Modeling Mistakes to Avoid Mistake 10: Place text attributes used for constraining and grouping in a fact tableMistake 9: Limit verbose descriptive attributes in dimensions to save spaceMistake 8: Split hierarchies and hierarchy levels into multiple dimensionsMistake 7: Ignore the need to track dimension attribute changesMistake 6: Solve all query performance problems by adding more hardware
59Common Dimensional Modeling Mistakes to Avoid Mistake 5: Use operational or smart keys to join dimension tables to a fact tableMistake 4: Neglect to declare and then comply with the fact table’s grainMistake 3: Design the dimensional model based on a specific reportMistake 2: Expect users to query the lowest-level atomic data in a normalized formaMistake 1: Fail to conform facts and dimensions across separate fact tables