Lecture 5 CS.456 DATABASE DESIGN

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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