2. Agenda
2
Introduction to Order Management
Order Transactions
Invoice Transactions
Accumulating Snapshot for the Order Fulfillment
Pipeline
Fact Table Comparison
Implementing
In the Real World
Techniques
Summary
3. Introduction to Order Management
3
Order management comprised of a series of
business process
A subset of the data warehouse bus matrix
5. Order Transactions
5
The natural granularity for an order transaction fact
table is one row for each line item on an order.
Example of result schema
6. Order Transactions
6
Fact Normalization
Dimension Role-Playing
Product Dimension Revisited
Customer Ship-To Dimension
Deal Dimension
Degenerate Dimension for Order Number
Junk Dimensions
Multiple Currencies
Header and Line Item Facts with Different Granularity
7. Fact Normalization
7
Fact Normalization : A single, generic fact amount,
along with a dimension that identifies the type of
fact
Use Fact Normalization when
Set of facts is sparsely populated for a given fact row.
No computations are made between facts.
We generally resist the urge to further normalize
the fact table
8. Dimension Role-Playing
8
Role-Playing : occurs when a single dimension
simultaneously appears several times in the same
fact table.
Date dimension is found in every fact table because
we are always looking at performance over time.
9. Dimension Role-Playing
9
Example of Role-playing
Request
Date
Assembly Order
Date Date
Time
Dimension
Arrival Ship
Date Date
10. Product Dimension Revisited
10
Product dimension describes the complete portfolio of
products sold by a company.
Characteristics of Product dimension
1. Numerous verbose descriptive columns.
2. One or more attribute hierarchies in addition to many
nonhierarchical attributes.
3. Add readable text strings to augment or replace numeric
codes in the operational product master.
4. Quality assure all the text strings to ensure that there are
no misspellings, impossible values, or cosmetically
different versions of the same attribute.
5. Document the product attribute definitions, interpretations,
and origins in the data warehouse’s metadata.
11. Customer Ship-To Dimension
11
The customer ship-to dimension contains one row for
each discrete location to which we ship a product.
Common hierarchy is natural geographic,
customer’s organizational.
Country Bill’s number
Region Customer Name
Province Customer Organization Name
Address Customer Corporate Parent
Name
12. Customer Ship-To Dimension
12
Factors must be taken into consideration:
1. The one-to-one or many-to-one relationship may turn
out to be a many-to-many relationship.
2. If the relationship between sales rep and customer
ship-to varies over time then the combined dimension
is in reality some kind of fact table itself!
3. If the sales rep and customer ship-to dimensions
participate independently in other business process
fact tables, we’d likely keep the dimensions separate.
14. Deal Dimension
14
Deal dimension describes the incentives that have
been offered to the customer that theoretically
affect the customers’ desire to purchase products.
Deal dimension describes
the full combination of terms
Allowance
Incentives
15. Deal Dimension
15
Deal Dimension Design
1. If the terms, allowances, and incentives are
correlated, then package them into a single deal
dimension.
2. If the terms, allowances, and incentives are quite
uncorrelated, then split such a deal dimension into its
separate components.
3. In a very large fact table, the desire to reduce the
number of keys in the fact table composite key would
favor keeping the deal dimension as a single
dimension.
17. Degenerate Dimension
17
for Order Number
Degenerate dimensions typically are reserved for
operational transaction identifiers.
Each line item row in the orders fact table includes
the order number as a degenerate dimension.
Useful of Degenerate Dimension for Order Number
allows us to group the separate line items on the order.
enables us to answer such questions as the average
number of line items on an order.
is used occasionally to link the data warehouse back to
the operational world.
18. Junk Dimension
18
Why have junk dimension
Leave flags and indicators unchanged in the fact table
row
Make each flag, indicator into its own separate
dimension.
Strip out all the flags and indicators from the design.
A junk dimension is a convenient grouping of
typically low-cardinality flags and indicators.
20. Multiple Currencies
20
Multiple Currencies : Expressed in both local
currency and the standardized corporate currency.
The conversion rate table contains all combinations
of effective currency exchange rates going in both
directions.
21. Multiple Currencies
21
Track multiple currencies with a daily currency
exchange fact table.
22. Header and Line Item Facts with
22
Different Granularity
Shouldn’t mix fact granularities (for example, order
and order line facts) within a single fact table.
Allocating header facts to the line item.
24. Invoice Transactions
24
Occurs when products are shipped from our facility
to the customer
Each items corresponding to a product being
shipped
Various prices, discounts, and allowances are
associated with each line item
26. Invoice Transactions
26
From invoice fact table we can see …
All company’s products
All customers
All contract and deals
All off-invoice discounts and allowances
All revenue
All variable and fixed costs (manufacturing, delivering)
All money left over after delivery of product
Customer satisfaction metrics
The optimal place to start a DW
27. 27 Accumulating Snapshot
for the Order Fulfillment Pipeline
28. Accumulating Snapshot for
28
the Order Fulfillment Pipeline
Useful when we want to better understand how
quickly products move through pipeline
Order Fulfillment Pipeline Diagram
31. Accumulating Snapshot for
31
the Order Fulfillment Pipeline
Typically have multiple dates representing major
milestones of the process
Useful when the products moving through the
pipeline is uniquely identified
Electronics equipment with a serial number
Automobile with a vehicle ID number
Fits most naturally with short-lived processes
Lag calculations
35. Designing Real-Time Partitions
35
DW extend its existing historical time series
seamlessly to the current instant
Separated physically and administratively from the
conventional static DW tables
Requirements
Contain all the activity occurred since the last update
Link as seamlessly as possible to the grain and content
Be so lightly indexed that incoming data can be
continuously dribbled in
42. DELL Data Warehouse
42
DELL Data Warehouse(DDW) is a global information
management system that stores data pulled directly
from Dell’s Regional Order Management and Service
Systems.
Order Data is available for the US, Latin America, Canada,
Europe, Asia Pacific and Japan. It’s upload daily with the
previous day’s activity.
of the order in the order lifecycle. The DW provides
information for all order statuses and order types to the
item level.
Order Status indicates the position
Order Type indicates how revenue and cost associated with
the order will be treated for accounting purposes.
43. Dell – Lifecycle of an Order
43
Every order at Dell goes through the following
stages shown below :
55. Summary
55
Context of the order management process
Dimension role-playing
Multiple currencies
Common challenges in modeling orders data
56. Summary
56
Facts at different levels if granularity
Set of facts associated with invoice transactions
Power of accumulating snapshot fact tables
Differences between the three fundamental types
of fact tables
Designing Real-Time Partitions
57. Members
57
49050867 ก
49050917 F
49050925 ก F F
49051154
49051162 F
58. ก ก
58
1. ก ก F
2. ก Business Process F OLTP
3. ก Dimension Fact Table
4. F F F OLTP
5. F F OLTP
6. F Dimension Table
7. F Fact Table
8. F Cube
9. F ก F
10. Slide Presentation
59. ก F F
59
ก ก F
ก Business Process F OLTP
ก Dimension Fact Table
F F F OLTP
F Dimension Dimension
F Dimension Dimension Table
F Fact Table Table
Table Table F
F Dimension Dimension
Fact Table Slide ก F
Table Table
F Cube Presentation Slide
Fact Table
Presentation
ก F ก