THE DATA WAREHOUSE TOOL KIT CH. 3 RETAIL SALESFOUR STEP DIMENSIONAL DESIGN PROCESS = Select the Business Process = Do not ea business department or function to avoid duplicating information = Examples: purchasing, ordering, shipping, billing = Declare the Grain = Specify exactly what an individual fact table represents = Examples: One row per scan of an individual product on a sales transactionFOUR STEP DIMENSIONAL DESIGN PROCESS = Identify the Dimensior = “How do employees describe the data resulting from the business process measurement events? = Represent the who, what, when, where, why, and how associated with an event = Examples: date, product, customer, employee, facility = Identify the Facts = What is the process measuring? = Typical facts are numeric figures = Examples: quantity ordered or dollar cost amount Be sure to consider both user requirements and the realities of your source data while making decis ions regarding the four step dimensional design processKEY INPUTS FOR THE DIMENSIONAL MODEL DE: Business Requirements Dimensional Model 1. Business Process 2. Grain 3. Dimensions 4. Facts a ~ Data RealitiesTHE DATA WAREHOUSE TOOL KIT CH. 3 RETAIL SALES“copes $30005225 Figure 3:2: Sample cash eter exptRetail Sales Fact, Store Dimension Cashier Dimension Date Key (FK) Product Key (FK) ‘Store Key (FK) Promotion Key (FK) Cashier Key (FK) Payment Method Key (Fk) POS Transaction # (0D) Sales Quantity Regular Unit Price Discount Unit Price Net Unit Price Extended Discount Dollar Amount Extended Sales Dollar Amount Extended Cost Dollar Amount Extended Gross Profit Dollar Amount Product Dimension Promotion Dimension Payment Method Dimension Measured facts in retail sales schema.= Date Dimension = Included in alnost every dimensions] model = Can be built in advance = Ranges from past historical data that maybe stored to years into the future = Examples: date, day of the week, month, quarter, year, holiday, weekday ames te re Ye Fell Date [ony ot | Calendar [Calendar| Calendar| Fiscal ear- [Hotiday | Weekday ‘acne a louetey |oate __|eserpin _|wert__|Mont” enter |Your |tont|idester _indeatar ora] OVOTAOTS [wary 12073 [Twety —[onuay—| OF 72013 |vteay_— [wan 20190102] 07022013 [wary 2203 [Wee [a ‘a1 72043 nok orga] ovos5 | sway 9, 2073_|Thesey aoa ar aor] Noga Woks oraooe|ovowaon3 [wary 42013 [rien [any | oF raorsa| Net | Weta cst o1go0s] 01082013 [swans 2013 [Suraj —[anuay | oF 201301 |e | Wecy iar 201906] oy062013 | sway 6 2073 [Sunday [sway | oF 01301] Neoany [Weta ‘ea 2013007] 07/2013 | wary 7, 2073 [Mendy | aa ar 7201901 iy | Wk [none orga] ov082013 [wary a 2013 [Twssay —[Juay | oF raorst|Ne-tay | wet ——— Figure 3-5: Date dimension sample rows.DIMENSION TABLE DETAILS = Product Dimension = Describes every SKU in the store = Almost alvays sourced from operational product master file = Headquarters’ responsibility to define the appropriate product master record and unique SKU for each new product = Merchandise hierarchies are important to group attributes = Despite redundancies, there is no need to normalize the data, as space savings in dimensional table vould be minimalDIMENSION TABLE DETAILS = Product Dimension = Describes every SKU in the store = Almost alvays sourced from operational product master file = Headquarters’ responsibility to define the appropriate product master record and unique SKU for each new product = Merchandise hierarchies are important to group attributes = Despite redundancies, there is no need to normalize the data, as space savings in dimensional table vould be minimalProduct Dimension Product Key (PK) ‘SKU Numba (14) Product Description ‘Brand Descrition ‘Subcatepory Description Category Description ‘Department Number ‘Department Descrition Package Type Description Package Size Fat Content Diet Type Weight Weight Unit of Measure ‘Storage Type ‘Shelf Life Type Shett width Shel Weight Shet Depth Figure 3-8: Product dimension table. it own yada Deparmet ‘ant ‘ater ‘sed Wer 3008 ay aoe Lot ease Frese ons ek 5321 Frases Frenne mars Fre Fons fos T28 Feserows % base Frese Fonts etree eas downy atc: Deparmet at Sate tae time aman ies bey ont ee Bay Ras at saer Bey eit +08 Frese Fone att as Frese Fonis apt 18573 Figure 3-9: Diling down on dimension atvibutes.DIMENSION TABLE DETAILS Store Dimension Describes every store in the retail chain POS systems may only supply a store number ona transaction versus having comprehensive store master file Able to use multiple hierarchies such as geographical and organizational ore Denon Por etal fa acon Fak Sere Kay PO ‘Date Kay Store Nas Product ey (FO) peo pease. Store Namba (Natural Key) Store ay {Prodect Drnenson_| Store Sextet Promenen tay 6) Store Gry POS aac [frometien Denenson) Store Cony Sse Store Stat Sse Oat Store 2p Code et Doar route Stor Manager ‘Gon Prot Dota Amount Store Dent fora pe Proto Poctang Franca arses Set syringe Fes Open Oa {is Rode! OatDIMENSION TABLE DETAILS = Promotion Dimension = Describes the promotion conditions under which the product was sold = Often referred to as a casual dimension as it describes factors thought to cause change in product sales Tromotion Dinenon Poi eat San Hanae at Fromoten Kay (PO Dat Key (FO (ase nanan Frometon Name Pret ky a Price Recon Type Store ay 0 {Product Dimension] Fromoton Mad Bremodon tay) SS] fahpe an Tee POS ara Member es Cage Se Bonar Anne ‘hated Rare Go Dots Amourt Seka Powder Gros rot Door Aunt Promdoon Cont ——e———er_—— Fremotion sgn Date Fromoton End Date ‘nd moreDIMENSION TABLE DETAILS = Promotion Dimension Describes factors thought to cause a change in product sales Four casual mechanisas are price reductions, ads, displays, and coupons Tracking and grouping similar promotions into one dimension helps show correlations Separating promotions into different dimensions provides more straight forvard information Itens sold that are not part of a pronotion should be noted to avoid a null promotion keySeals Figure 3-12: Querying the retail sales schema. i ian a a Fae Dara) Dae as bas Prey Tote Daye Stra Srna 0 TH eh Ponte 9 Pra een Cote Gamera tine onon ais H tani ve Porta iy) Cay eon rovtaacon 0) Sie Oty ‘Store Dimension Regular Unit Price ‘Promotion Dimension Se) sae Toner Sarna 9 brute Doutcataamoun | |_| Porte cote em Stor Distt nen ae tar Promotion Meda Type Boston] Store Region ee, Promotion Begin ate nett rs re ot Aa nero [Fae i | rr) Poe ie 0 aoe Erejn 0) Papen ed ner gon oan ee Pare ie reDEGENERATE DIMENSIO! = Degenerate Dimension Is a dimension key on a fact table that does not have its ovn dimension table Very common when the grain of a fact table represent a single transaction or transaction line Often play an integral role in the fact table’ s primary key because it represents the unique identifier of a parent Examples: Order numbers, invoice numbers, bill of lading numbers= Surrogate Keys = They are integers that are assigned sequentially as needed to populate a dimension to join dinensional tables to fact tables = It may take some extra time and work to implement surrogate keys but they do have their benefits in ‘the long run which include: Buffering the data warehouse from operational changes + Integrating wvltiple sources = Improved performance Handling nvL1 oF vnkaoen conditions Supporting dinension attribute change trackingSNOWFLAKE SCHEMAS WITH NORMALIZED DIMENSIONS = Snowflake Schema = Dimension table normalization snowflaking s often referred to as = Primary reasons against snowflaking are ease of use and performance = More snovflaked tables make it more complex = Minor disk space saved by normalizing = Optimizers have difficultly = Users ability to browse within a dimension is negatively affected as velOUTRIGGER DIMENSIONS = Outrigger Dimensions a a] = A dimension can contain a reference to Rmeraiaum_ | [Seat eel another dimension table and the ee cose fe Ne / secondary dimension is referred to as lesa |= pane wey the an outrigger dimension esearamairst = Are permissible, but should be used a sparingly. = Inmost cases, the correlations between dimensions should be demoted to a fact sagas. perinibe sovflaing vith « dimension oxign for cme o ow-carinalty table, where both dimensions are trues represented as separate foreign keys.CENTIPEDE FACT TABLES WITH TOO MANY DIMENSIONS Centipede Fact Tables Sone designers create separate normalized dimensions for each level of a many-to- one hierarchy, such as a date dimension, month dimension, quarter dimension, and year dimension, and then include all these foreign keys ina fact table resulting in a centipede fact table. Centipede fact tables also result when designers enbed numerous foreign keys to individual low-cardinality dimension tables rather than creating a junk dimension Should be avoided 5 ‘ot 6 Meaay Norah ey O80 Suara Yesrtoy 08 Foca 8 Feealketh 9 Fre ty Strat ey {Stage y Expr 0 ergo Sie Sat tay 019 Sore Dae ay O99 Sore agony Sore haoran 6) Frometon ay Peet pe 9 Perfecto 0) and Ur