1. 3.Planning & Project management
2/23/2012
3.Planning & Project management/D.S.Jagli

2. 3.Planning & Project management: topics to be covered
How is it different?
Life-cycle approach
The Development Phases
Dimensional Analysis
Dimensional Modeling
Star Schema
Snowflake Scheme
2/23/2012
3.Planning & Project management/D.S.Jagli

3. 3.Planning & Project management
Reasons for DWH projects failure
Improper planning
Inadequate project management
Planning for Data ware house is necessary.
Key issues needs to be planned
Value and expectation
Risk assessment
Top-down or bottom –up
Build or Buy
Single vender or best of breed
Business requirement ,not technology
Top management support
Justification
2/23/2012
3.Planning & Project management/D.S.Jagli

4. 3.Planning & Project management
Example for DWH Project
Outline for overall plan
Introduction
Mission statement
Scope
Goals& objectives
Key issues & Options
Value& expectations
Justification
Executive sponsorship
Implementation Strategy
Tentative schedule
Project authorization
2/23/2012
3.Planning & Project management/D.S.Jagli

5. 3.1 How is it different?
DWH Project Different from OLTP System Project
DWH Distinguish features and Challenges for Project Management
Data Acquisition
Data Storage –
Info . Delivery-
2/23/2012
3.Planning & Project management/D.S.Jagli

6. 2/23/2012
3.Planning & Project management/D.S.Jagli

7. 3.2 The life-cycle Approach
Fig: DW functional components and SDLC
2/23/2012
3.Planning & Project management/D.S.Jagli

8. DWH Project Plan: Sample outline
2/23/2012
3.Planning & Project management/D.S.Jagli

9. 3.3 DWH Development Phases
2/23/2012
3.Planning & Project management/D.S.Jagli

10. 3.3 DWH Development Phases
Project plan
Requirements definition
Design
Construction
Deployment
Growth and maintenance
Interleaved within the design and construction phases are the three tracks along with the definition of the architecture and the establishment of the infrastructure
2/23/2012
3.Planning & Project management/D.S.Jagli

11. 3.4 Dimensional Analysis
A data warehouse is an information delivery system.
It is not about technology, but about solving users’ problems and providing strategic information to the user.
In the phase of defining requirements, you need to concentrate on what information the users need, not on how you are going to provide the required information.
2/23/2012
3.Planning & Project management/D.S.Jagli

12. Dimensional Analysis Usage of Information Unpredictable
In providing information about the requirements for an operational system, the users are able to give you precise details of the required functions, information content, and usage patterns
Dimensional Nature of Business Data
Even though the users cannot fully describe what they want in a data warehouse, they can provide you with very important insights into how they think about the business.
2/23/2012
3.Planning & Project management/D.S.Jagli

13. Managers think in business dimensions : example
2/23/2012
3.Planning & Project management/D.S.Jagli

14. Dimensional Nature of Business Data
2/23/2012
3.Planning & Project management/D.S.Jagli

15. Dimensional Nature of Business Data
2/23/2012
3.Planning & Project management/D.S.Jagli

16. Examples of Business Dimensions
2/23/2012
3.Planning & Project management/D.S.Jagli

17. Examples of Business Dimensions
2/23/2012
3.Planning & Project management/D.S.Jagli

18. INFORMATION PACKAGES—A NEW CONCEPT
a novel idea is introduced for determining and recording information requirements for a data warehouse.
This concept helps us to give a concrete form to the various insights, nebulous thoughts, and opinions expressed during the process of collecting requirements.
The information packages, put together while collecting requirements, are very useful for taking the development of the data warehouse to the next phases.
2/23/2012
3.Planning & Project management/D.S.Jagli

19. Requirements Not Fully Determinate
Information packages enable us to:
Define the common subject areas
Design key business metrics
Decide how data must be presented
Determine how users will aggregate or roll up
Decide the data quantity for user analysis or query
Decide how data will be accessed
Establish data granularity
Estimate data warehouse size
Determine the frequency for data refreshing
Ascertain how information must be packaged
2/23/2012
3.Planning & Project management/D.S.Jagli

20. An information package.
2/23/2012
3.Planning & Project management/D.S.Jagli

21. Business Dimensions
business dimensions form the underlying basis of the new methodology for requirements definition.
Data must be stored to provide for the business dimensions.
The business dimensions and their hierarchical levels form the basis for all further phases.
2/23/2012
3.Planning & Project management/D.S.Jagli

22. Dimension Hierarchies/Categories
Examples:
Product: Model name, model year, package styling, product line, product category, exterior color, interior color, first model year
Dealer: Dealer name, city, state, single brand flag, date first operation
Customer demographics: Age, gender, income range, marital status, household size, vehicles owned, home value, own or rent
Payment method: Finance type, term in months, interest rate, agent
Time: Date, month, quarter, year, day of week, day of month, season, holiday flag
2/23/2012
3.Planning & Project management/D.S.Jagli

23. Key Business Metrics or Facts
The numbers the users analyze are the measurements or metrics that measure the success of their departments.
These are the facts that indicate to the users how their departments are doing in fulfilling their departmental objectives.
2/23/2012
3.Planning & Project management/D.S.Jagli

24. Example: automobile sales
The set of meaningful and useful metrics for analyzing automobile sales is as follows:
Actual sale price
MSRP sale price
Options price
Full price
Dealer add-ons
Dealer credits
Dealer invoice
Amount of down payment
Manufacturer proceeds
Amount financed
2/23/2012
3.Planning & Project management/D.S.Jagli

25. 3.5 DIMENSIONAL MODELING Star Schema Snowflake Scheme 2/23/2012
3.Planning & Project management/D.S.Jagli

26. FROM REQUIREMENTS TO DATA DESIGN
The requirements definition completely drives the data design for the data warehouse.
A group of data elements form a data structure.
Logical data design includes determination of the various data elements that are needed and combination of the data elements into structures of data.
Logical data design also includes establishing the relationships among the data structures.
2/23/2012
3.Planning & Project management/D.S.Jagli

27. FROM REQUIREMENTS TO DATA DESIGN
The information package diagrams form the basis for the logical data design for the data warehouse.
The data design process results in a dimensional data model
2/23/2012
3.Planning & Project management/D.S.Jagli

28. From requirements to data design.
2/23/2012
3.Planning & Project management/D.S.Jagli

29. Dimensional Modeling Basics: Formation of the automaker sales fact table.
2/23/2012
3.Planning & Project management/D.S.Jagli

30. Formation of the automaker dimension tables.
2/23/2012
3.Planning & Project management/D.S.Jagli

31. Concept of Keys for Dimension table
Surrogate Keys
A surrogate key is the primary key for a dimension table and is independent of any keys provided by source data systems.
Surrogate keys are created and maintained in the data warehouse and should not encode any information about the contents of records;
Automatically increasing integers make good surrogate keys.
The original key for each record is carried in the dimension table but is not used as the primary key. Surrogate keys provide the means to maintain data warehouse information when dimensions change.
Business Keys
Natural keys
Will have a meaning and can be generated out of the data from source system or can be used as is from source system field

32. The criteria for combining the tables into a dimensional model.
The model should provide the best data access.
The whole model must be query-centric.
It must be optimized for queries and analyses.
The model must show that the dimension tables interact with the fact table.
It should also be structured in such a way that every dimension can interact equally with the fact table.
The model should allow drilling down or rolling up along dimension hierarchies.
2/23/2012
3.Planning & Project management/D.S.Jagli

33. The dimensional model :a STAR schema
With these requirements, we find that a dimensional model with the fact table in the middle and the dimension tables arranged around the fact table satisfies the condition
2/23/2012
3.Planning & Project management/D.S.Jagli

34. Case study: STAR schema for automaker sales.
2/23/2012
3.Planning & Project management/D.S.Jagli

35. E-R Modeling Versus Dimensional Modeling
DW meant to answer questions on overall process
DW focus is on how managers view the business
DW focus business trends
Information is centered around a business process
Answers show how the business measures the process
The measures to be studied in many ways along several business dimensions
OLTP systems capture details of events transactions
OLTP systems focus on individual events
An OLTP system is a window into micro-level transactions
Picture at detail level necessary to run the business
Suitable only for questions at transaction level
Data consistency, non-redundancy, and efficient data storage critical
2/23/2012
3.Planning & Project management/D.S.Jagli

36. E-R Modeling Versus Dimensional Modeling
Dimensional modeling for the data warehouse.
E-R modeling for OLTP systems
2/23/2012
3.Planning & Project management/D.S.Jagli

37. THE STAR SCHEMA
2/23/2012
3.Planning & Project management/D.S.Jagli

38. Star Schemas
Data Modeling Technique to map multidimensional decision support data into a relational database.
Current Relational modeling techniques do not serve the needs of advanced data requirements
2/23/2012
3.Planning & Project management/D.S.Jagli

39. Star Schema Facts Dimensions Attributes Attribute Hierarchies
4 Components
Facts
Dimensions
Attributes
Attribute Hierarchies
2/23/2012
3.Planning & Project management/D.S.Jagli

40. Facts
Numeric measurements (values) that represent a specific business aspect or activity.
Stored in a fact table at the center of the star scheme.
Contains facts that are linked through their dimensions.
Updated periodically with data from operational databases
2/23/2012
3.Planning & Project management/D.S.Jagli

41. Dimensions
Qualifying characteristics that provide additional perspectives to a given fact
DSS data is almost always viewed in relation to other data
Dimensions are normally stored in dimension tables
2/23/2012
3.Planning & Project management/D.S.Jagli

42. Attributes Dimension Tables contain Attributes
Attributes are used to search, filter, or classify facts
Dimensions provide descriptive characteristics about the facts through their attributed
Must define common business attributes that will be used to narrow a search, group information, or describe dimensions. (ex.: Time / Location / Product)
No mathematical limit to the number of dimensions (3-D makes it easy to model)
2/23/2012
3.Planning & Project management/D.S.Jagli

43. Attribute Hierarchies
Provides a Top-Down data organization
Aggregation
Drill-down / Roll-Up data analysis
Attributes from different dimensions can be grouped to form a hierarchy
2/23/2012
3.Planning & Project management/D.S.Jagli

44. Concept of Keys for Star schema
Surrogate Keys
The surrogate keys are simply system-generated sequence numbers and is independent of any keys provided by source data systems.
They do not have any built-in meanings.
Surrogate keys are created and maintained in the data warehouse and should not encode any information about the contents of records;
Automatically increasing integers make good surrogate keys.
The original key for each record is carried in the dimension table but is not used as the primary key.
Business Keys
Primary Keys
Each row in a dimension table is identified by a unique value of an attribute designated as the primary key of the dimension.
Foreign Keys
Each dimension table is in a one-to-many relationship with the central fact table. So the primary key of each dimension table must be a foreign key in the fact table.

45. Star Schema for Sales Dimension Tables Fact Table 2/23/2012
3.Planning & Project management/D.S.Jagli

46. Star Schema Representation
Fact and Dimensions are represented by physical tables in the data warehouse database.
Fact tables are related to each dimension table in a Many to One relationship (Primary/Foreign Key Relationships).
Fact Table is related to many dimension tables
The primary key of the fact table is a composite primary key from the dimension tables.
Each fact table is designed to answer a specific DSS question
2/23/2012
3.Planning & Project management/D.S.Jagli

47. Star Schema
The fact table is always the larges table in the star schema.
Each dimension record is related to thousand of fact records.
Star Schema facilitated data retrieval functions.
DBMS first searches the Dimension Tables before the larger fact table
2/23/2012
3.Planning & Project management/D.S.Jagli

48. Star Schema : advantages
Easy to understand
Optimizes Navigation
Most Suitable for Query Processing
2/23/2012
3.Planning & Project management/D.S.Jagli

49. THE SNOWFLAKE SCHEMA 2/23/2012
3.Planning & Project management/D.S.Jagli

50. THE SNOWFLAKE SCHEMA
Snowflaking” is a method of normalizing the dimension tables in a STAR schema.
2/23/2012
3.Planning & Project management/D.S.Jagli

51. Sales: a simple STAR schema.
2/23/2012
3.Planning & Project management/D.S.Jagli

52. Product dimension: partially normalized
2/23/2012
3.Planning & Project management/D.S.Jagli

53. When to Snowflake
The principle behind snowflaking is normalization of the dimension tables by removing low cardinality attributes and forming separate tables.
In a similar manner, some situations provide opportunities to separate out a set of attributes and form a subdimension.
2/23/2012
3.Planning & Project management/D.S.Jagli

54. Advantages and Disadvantages
Small savings in storage space
Normalized structures are easier to update and maintain
Disadvantages
Schema less intuitive and end-users are put off by the complexity
Ability to browse through the contents difficult
Degraded query performance because of additional joins
2/23/2012
3.Planning & Project management/D.S.Jagli

55. ??? Thank you
2/23/2012
3.Planning & Project management/D.S.Jagli