Вы находитесь на странице: 1из 43

ORDER

MANAGEMENT
CHAPTER 5
OVERVIEW

▪ Introduction to Order Management


▪ Order Transactions
▪ Invoice Transactions
▪ Accumulating Snapshot for the Order Fulfillment Pipeline
▪ Fact Table Comparison
▪ Designing Real-Time Partition
INTRODUCTION TO ORDER MANAGEMENT

Order management comprised of a series of business


process
A subset of the data warehouse bus matrix
ORDER TRANSACTIONS
ORDER TRANSACTION

The natural granularity for an order transaction fact table is


one row for each line item on an order.
Example of result schema
ORDER TRANSACTION

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
FACT NORMALIZATION
FACT NORMALIZATION

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
DIMENSION ROLE-PLAYING
DIMENSION ROLE-PLAYING

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.
DIMENSION ROLE-PLAYING

▪ Example of Role-Playing
PRODUCT DIMENSION REVISITED
PRODUCT DIMENSION REVISITED

1. Numerous verbose descriptive columns.


2. One or more attribute hierarchies in addition to many
nonhierarchical attributes.
3. Remap the operational product key to a surrogate key.
4. Add readable text strings to augment or replace numeric codes in
the operational product master.
5. Quality assure all the text strings to ensure that there are no
misspellings, impossible values, or cosmetically different versions of
the same attribute.
6. Document the product attribute definitions, interpretations, and
origins in the data warehouse’s metadata.
CUSTOMER SHIP-TO DIMENSION
CUSTOMER SHIP –TO DIMENSION

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.
CUSTOMER SHIP –TO DIMENSION

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.
CUSTOMER SHIP –TO DIMENSION

▪ Example of Customer Ship-To Dimension


DEAL DIMENSION
DEAL DIMENSION

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
DEAL DIMENSION

Deal Dimension Design

▪ If the terms, allowances, and incentives are correlated,


then package them into a single deal dimension.
▪ If the terms, allowances, and incentives are quite
uncorrelated, then split such a deal dimension into its
separate components.
▪ 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.
DEAL DIMENSION

EXAMPLE OF DEAL DIMENSION


DEGENERATE DIMENSION 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
oallows 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.
ois used occasionally to link the data warehouse back to
the operational world.
JUNK DIMENSION
JUNK DIMENSION

Why have junk dimension?


oLeave flags and indicators unchanged in the fact
table row
oMake each flag, indicator into its own separate
dimension.
oStrip out all the flags and indicators from the design.
A junk dimension is a convenient grouping of
typically low-cardinality flags and indicators.
JUNK DIMENSION

Sample rows of an order indicator junk dimension


MULTIPLE CURRENCIES
MULTIPLE CURRENCIES

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.
MULTIPLE CURRENCIES

Track multiple currencies with a daily currency exchange fact table.


HEADER AND LINE ITEM FACTS
WITH DIFFERENT GRANULARITY
HEADER AND LINE ITEM FACTS WITH 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.
INVOICE TRANSACTION
INVOICE TRANSACTION

▪Occurs when products are shipped from our


facility to the customer
▪Each item corresponding to a product being
shipped
▪Various prices, discounts, and allowances are
associated with each line item
INVOICE TRANSACTION
INVOICE TRANSACTION

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 rate/metrics
ACCUMULATING SNAPSHOT FOR
THE ORDER FULIFILLMENT
PIPELINE
ACCUMULATING SNAPSHOT FOR THE ORDER
FULFILLMENT PIPELINE

▪ Useful when we want to better understand how


quickly products move through pipeline

Order Fulfillment Pipeline Diagram


ACCUMULATING SNAPSHOT FOR THE ORDER
FULFILLMENT
ACCUMULATING SNAPSHOT FOR THE ORDER
FULFILLMENT
ACCUMULATING SNAPSHOT FOR THE ORDER
FULFILLMENT

▪ 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
FACT TABLE COMPARISON
FACT TABLE COMPARISON
DESIGNING REAL-TIME PARTITIONS
DESIGNING REAL-TIME PARTITIONS

▪ Data Warehouse 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