1. Lecture 5
CS.456 DATABASE DESIGN

2. Characteristics related to Fact tables
Concatenated key
Data Grain
Fully Additive Measures
Semi additive Measures
Table Deep, Not Wide
Sparse Data
Degenerate Dimensions.

3. Concatenated Keys in Fact table
In fact table we keep measurements.
A row in fact table relates to combination of rows from all multiple dimension tables.
A row in fact table must be identified using primary keys of all dimension tables.
Primary key of fact table must be concatenation of primary keys of all dimension tables.

4. Concatenated Keys in Fact table
Example:
Record of “Sales Analysis” fact table should contain:
Primary key value from Product table (Product_ID).
Primary key value from Time table (Date).
Primary key value from Customer table (Customer_ID).
Primary key value from Sales Representative table (Sales_Rep_ID).
Sales_Analysis_ID is key attribute of fact table which should store a concatenated value of all primary key attributes from dimension tables.

5. Data Grain Level of detail for measurements/metrics in a fact table.
Quantity Ordered for a
Particular product
Certain date
Specific customer
Sales representative
Data to be stored may be at different detail levels.

6. Table Deep not Wide
Fact table contains fewer attributes than dimension table.
Number of records in a fact table is very large than dimension table.
3 products
5 customers
30 days
10 sales representatives
Number of rows in fact table will be 4500
Much larger than dimension table

7. Sparse Data
Some rows of fact table will not contain values for some dimension values.
Value of order totals for calendar dates on holiday will not contain any value.
There can be such data in which there will be more null values in rows of fact table.

8. Degenerate Dimensions
Some attributes of operational database are not related to either fact measures or dimension values.
But they are required to be stored in data warehouse.
Such attributes are called degenerate dimensions.
Example: order_no, order_line_no, invoice_no
Average number of products per order
Products are required to be related to particular order numbers.

9. Star Schema Keys Primary Key
Don’t use primary keys of operational database tables as keys of dimension tables.
Product_code in operational systems is in following format:
Store warehouse code||product id
Data warehouse contains historic data
If product’s store warehouse is changed after some time
Using product_code for dimension table will cause problem.

10. Star Schema Keys
Avoid built-in meanings in primary keys of dimension table.
Customer_code representing a customer associated with a company
Use Surrogate Keys
Surrogate keys are system generated keys/sequence numbers.
Keep keys of operational system as additional attributes in dimension tables.

11. Star Schema Keys Foreign keys Primary Keys of Fact table:
Each dimension table has a one to many relationship with central fact table.
Primary key of a dimension table must be a foreign key in fact table.
Primary Keys of Fact table:
A single compound key whose length is total length of all dimension tables.
A key should be concatenation of all primary keys of dimension tables.
A generated primary key independent of keys of dimension tables.

12. DW Design Steps 1. Choose the business process(es) to model
Sales
2. Choose the granularity of the business process
Items by Store by Promotion by Day
Low granularity is needed
3. Choose the dimensions
Time, Store, …
4. Choose the measures
Dollar_sales, unit_sales, dollar_cost, customer_count

17. Select Lower(‘SQL Course’) ,Upper(‘sql course’) from dual;