The document outlines an orderly approach for data warehouse construction, beginning with planning and project management. It discusses key phases in development including requirements definition, design, construction, deployment, and growth/maintenance. Dimensional analysis and modeling are covered, including star schemas and snowflake schemas. The document provides examples of how to develop dimensional models from requirements and discusses best practices for dimensional modeling in a data warehouse.
Introduction to Data Warehouse. Summarized from the first chapter of 'The Data Warehouse Lifecyle Toolkit : Expert Methods for Designing, Developing, and Deploying Data Warehouses' by Ralph Kimball
Introduction to Data Warehouse. Summarized from the first chapter of 'The Data Warehouse Lifecyle Toolkit : Expert Methods for Designing, Developing, and Deploying Data Warehouses' by Ralph Kimball
this is the ppt this contains definition of data ware house , data , ware house, data modeling , data warehouse architecture and its type , data warehouse types, single tire, two tire, three tire .
Data Warehouse, Data Warehouse Architecture, Data Warehouse Concept, Data Warehouse Modeling, OLAP, OLAP Operations, Data Cube, Data Processing, Data Cleaning, Data Reduction, Data Integration, Data Transformation
What’s The Difference Between Structured, Semi-Structured And Unstructured Data?Bernard Marr
There are three classifications of data: structured, semi-structured and unstructured. While structured data was the type used most often in organizations historically, artificial intelligence and machine learning have made managing and analysing unstructured and semi-structured data not only possible, but invaluable.
FellowBuddy.com is an innovative platform that brings students together to share notes, exam papers, study guides, project reports and presentation for upcoming exams.
We connect Students who have an understanding of course material with Students who need help.
Benefits:-
# Students can catch up on notes they missed because of an absence.
# Underachievers can find peer developed notes that break down lecture and study material in a way that they can understand
# Students can earn better grades, save time and study effectively
Our Vision & Mission – Simplifying Students Life
Our Belief – “The great breakthrough in your life comes when you realize it, that you can learn anything you need to learn; to accomplish any goal that you have set for yourself. This means there are no limits on what you can be, have or do.”
Like Us - https://www.facebook.com/FellowBuddycom
Data warehousing Demo PPTS | Over View | Introduction Kernel Training
Module 1:
Introduction to Data Warehouse & Business Intelligence
Module 2: Data Warehouse Architecture
Module 3: Warehouse: D & F – Dimension & Fact Tables
Module 4: Data Modeling
Module 5: Building Data Warehouse with ER Win
Module 6: Introduction to Open Source ETL Tool – Talend DI Open Studio 5.x
Module 7: Building ETL Project with Talend DI Open Studio 5.x
Module 8: Introduction to Data Visualization BI Tool – Tableau 9.x
Module 9: Building Data Visualization BI Project With Tableau 9.x
Module 10: An Integrated Data Ware Housing & BI Project
Which Case-Studies will be a part of data warehousing and business intelligence online training?
Learn Data warehousing and business intelligence online training by real time expert. Be a part of live sessions. Data warehousing and business intelligence classes by Expert.
this is the ppt this contains definition of data ware house , data , ware house, data modeling , data warehouse architecture and its type , data warehouse types, single tire, two tire, three tire .
Data Warehouse, Data Warehouse Architecture, Data Warehouse Concept, Data Warehouse Modeling, OLAP, OLAP Operations, Data Cube, Data Processing, Data Cleaning, Data Reduction, Data Integration, Data Transformation
What’s The Difference Between Structured, Semi-Structured And Unstructured Data?Bernard Marr
There are three classifications of data: structured, semi-structured and unstructured. While structured data was the type used most often in organizations historically, artificial intelligence and machine learning have made managing and analysing unstructured and semi-structured data not only possible, but invaluable.
FellowBuddy.com is an innovative platform that brings students together to share notes, exam papers, study guides, project reports and presentation for upcoming exams.
We connect Students who have an understanding of course material with Students who need help.
Benefits:-
# Students can catch up on notes they missed because of an absence.
# Underachievers can find peer developed notes that break down lecture and study material in a way that they can understand
# Students can earn better grades, save time and study effectively
Our Vision & Mission – Simplifying Students Life
Our Belief – “The great breakthrough in your life comes when you realize it, that you can learn anything you need to learn; to accomplish any goal that you have set for yourself. This means there are no limits on what you can be, have or do.”
Like Us - https://www.facebook.com/FellowBuddycom
Data warehousing Demo PPTS | Over View | Introduction Kernel Training
Module 1:
Introduction to Data Warehouse & Business Intelligence
Module 2: Data Warehouse Architecture
Module 3: Warehouse: D & F – Dimension & Fact Tables
Module 4: Data Modeling
Module 5: Building Data Warehouse with ER Win
Module 6: Introduction to Open Source ETL Tool – Talend DI Open Studio 5.x
Module 7: Building ETL Project with Talend DI Open Studio 5.x
Module 8: Introduction to Data Visualization BI Tool – Tableau 9.x
Module 9: Building Data Visualization BI Project With Tableau 9.x
Module 10: An Integrated Data Ware Housing & BI Project
Which Case-Studies will be a part of data warehousing and business intelligence online training?
Learn Data warehousing and business intelligence online training by real time expert. Be a part of live sessions. Data warehousing and business intelligence classes by Expert.
These slides describe the various steps for project planning. It was prepared by a group of students studying Bachelor of Public Health at Maharajgunj Medical Campus, Institute of Medicine, Nepal.
Advanced data visualization (ADV) is a rapidly emerging concept in business and society and has a lofty goal of transforming data into information. But how do we get there?
Big Data triggered furthered an influx of research and prospective on concepts and processes pertaining previously to the Data Warehouse field. Some conclude that Data Warehouse as such will disappear;others present Big Data as the natural Data Warehouse evolution (perhaps without identifying a clear division between the two); and finally, some others pose a future of convergence, partially exploring the
possible integration of both. In this paper, we revise the underlying technological features of Big Data and Data Warehouse, highlighting their differences and areas of convergence. Even when some differences exist, both technologies could (and should) be integrated because they both aim at the same purpose: data exploration and decision making support. We explore some convergence strategies, based on the common elements in both technologies. We present a revision of the state-of-the-art in integration proposals from the point of view of the purpose, methodology, architecture and underlying technology, highlighting the
common elements that support both technologies that may serve as a starting point for full integration and we propose a proposal of integration between the two technologies.
Big Data triggered furthered an influx of research and prospective on concepts and processes pertaining previously to the Data Warehouse field. Some conclude that Data Warehouse as such will disappear; others present Big Data as the natural Data Warehouse evolution (perhaps without identifying a clear division between the two); and finally, some others pose a future of convergence, partially exploring the possible integration of both. In this paper, we revise the underlying technological features of Big Data and Data Warehouse, highlighting their differences and areas of convergence. Even when some differences exist, both technologies could (and should) be integrated because they both aim at the same purpose: data exploration and decision making support. We explore some convergence strategies, based on the common elements in both technologies. We present a revision of the state-of-the-art in integration proposals from the point of view of the purpose, methodology, architecture and underlying technology, highlighting the common elements that support both technologies that may serve as a starting point for full integration and we propose a proposal of integration between the two technologies.
Big Data triggered furthered an influx of research and prospective on concepts and processes pertaining
previously to the Data Warehouse field. Some conclude that Data Warehouse as such will disappear;
others present Big Data as the natural Data Warehouse evolution (perhaps without identifying a clear
division between the two); and finally, some others pose a future of convergence, partially exploring the
possible integration of both. In this paper, we revise the underlying technological features of Big Data and
Data Warehouse, highlighting their differences and areas of convergence.
No matter how hard we try, planning is not perfect, and sometimes .docxhenrymartin15260
No matter how hard we try, planning is not perfect, and sometimes plans fail. Typical reasons
include:
● Corporate goals are not understood at the lower organizational levels.
● Plans encompass too much in too little time.
● Financial estimates are poor.
● Plans are based on insufficient data.
● No attempt is being made to systematize the planning process.
● Planning is performed by a planning group.
● No one knows the ultimate objective.
● No one knows the staffing requirements.
● No one knows the major milestone dates, including written reports.
● Project estimates are best guesses, and are not based on standards or history.
● Not enough time has been given for proper estimating.
● No one has bothered to see if there will be personnel available with the necessary skills.
● People are not working toward the same specifications.
● People are consistently shuffled in and out of the project with little regard for
schedule.
Stopping Projects 549
Why do these situations occur? If corporate goals are not understood, it is because corporate
executives have been negligent in providing the necessary strategic information and
feedback. If a plan fails because of extreme optimism, then the responsibility lies with both
the project and line managers for not assessing risk. Project managers should ask the line
managers if the estimates are optimistic or pessimistic, and expect an honest answer.
Erroneous financial estimates are the responsibility of the line manager. If the project fails
because of a poor definition of the requirements, then the project manager is totally at fault.
Sometimes project plans fail because simple details are forgotten or overlooked.
Examples of this might be:
● Neglecting to tell a line manager early enough that the prototype is not ready and
that rescheduling is necessary.
● Neglecting to see if the line manager can still provide additional employees for the
next two weeks because it was possible to do so six months ago.
Sometimes plans fail because the project manager “bites off more than he can chew,”
and then something happens, such as his becoming ill. Many projects have failed because
the project manager was the only one who knew what was going on and then got sick.
11.20 STOPPING PROJECTS
There are always situations in which projects have to be stopped. Nine
reasons for stopping are:
● Final achievement of the objectives
● Poor initial planning and market prognosis
● A better alternative is found
● A change in the company interest and strategy
● Allocated time is exceeded
● Budgeted costs are exceeded
● Key people leave the organization
● Personal whims of management
● Problem too complex for the resources available
Today most of the reasons why projects are not completed on time and within cost are
behavioral rather than quantitative. They include:
● Poor morale
● Poor human relations
● Poor labor productivity
● No commitment by those involved in the project
The last item appears to be the cause of the first three ite.
A project involves investment of considerable amount of time, money and energy. While the act of doing a project offers a big learning opportunity for stakeholders, the effectiveness with which these lessons are learnt, recorded and utilized varies. Lessons learnt are important organizational process asset inputs to project planning and management.
This paper proposes a framework for actively managing project learning by bringing learning into the forefront of project management.
A project involves investment of considerable amount of time, money and energy. While the act of doing a project offers a big learning opportunity for stakeholders, the effectiveness with which these lessons are learned, recorded and utilized varies. Lessons learned are important organizational process asset inputs to project planning and management.
This paper proposes a framework for actively managing project learning by bringing learning into the forefront of project management.
How To Develop A Project Management PlanOrangescrum
For project managers, a successful outcome is always preceded by a well-prepared project management plan. A lot of effort is put into planning which helps you prepare a better Project Management Plan.
This is the Dissertation Part-I in support of my intended research work. It has presentation in support of my research methodology, timelines and expected results
Enabling a Bimodal IT Framework for Advanced Analytics with Data VirtualizationDenodo
Watch: https://bit.ly/2FLc5I2
Being able to maintain a well managed and curated Data Warehouse, along with keeping up with all of the demands of a very sophisticated consumer group can be a challenge. The new user wants access to data, they want to experiment, fail fast and if they do find usable insights/algorithms they want them productionized. This puts pressure on an IT organization and pushes them closer to a Bimodal operation where the regular IT processes that are highly curated, well defined and managed contrast sharply with the demands of the more sophisticated user.
In the recently published TDWI Best Practices Report ,“Data Management for Advanced Analytics”, Philip Russom, DM for Advanced Analytics some of these newer requirements for the more sophisticated user are discussed in some length. How can IT support traditional demands around traditional BI and Reporting, whilst enabling the business with more demand for data and Advanced Analytics in mind?
Attend and learn:
- How data virtualization enables this Bi-Modal approach to Data Management.
- How data virtualization enables compelling use cases for data management and advanced analytics
- How we can achieve this important balance with process and technology.
Adapting to Uncertain and Evolving Requirements: The Case of Business-Driven ...Eric Yu
What happened to "business-driven" BI? Why did the initial attempts not work? How did BI vendors respond? How did user organizations and IT departments adapt? What kinds of modeling can help understand the evolving situation and suggest next steps?
"Adapting to Uncertain and Evolving Requirements: The Case of Business-Driven Business Intelligence" Presentation at the RCIS 2013 conference. Eric Yu, Alexei Lapouchnian, and Stephanie Deng.
Sabrion was built around our Product Lifecycle Management (PLM) Practice and our professional PLM consultants have on the average of 15 years experience implanting enterprise solutions with on the average of 6 years implementing PLM solutions. Our consultants have implemented PLM solutions to well over 150 companies. Our primary purpose is to provide services that deliver projects driven by experience and commitment. We build value through the strength of our customers' satisfaction and by consistently producing superior results. The Sabrion objective is to present value in the consulting practice especially with modern PLM technology and principals. Our methodology is based around implementing our PLM solution with multi-skilled consultants ensuring that we staff the project with smaller teams to keep the costs down for our customers.
SABRION has a long track record of successful software implementations. We have taken our vast experience in eProcurement and Enterprise Resource Planning engagements and applied that knowledge and skill into the Product Lifecycle Management environment. Throughout all phases of an implementation, we address the key issues and produce deliverables that lead to a successful product launch. Finally, we work with the client before, during, and after the engagement to ensure their complete satisfaction with our results, and help to formulate follow-on plans.
For more information or additional project documents to support your transformation, please contact us on our website at www.sabrion-digital.com
In our day today life we often need to manage project for various reasons. For efficiently
managing a project, project analysis, monitoring team development, controlling, Gantt chart,
critical paths, life cycles, consequences, administration panel are the crucial part. Project
administration is the craft of dealing with the undertaking and its deliverables with a perspective
to create completed items or administration. There are numerous routes in which a task can be
completed and the path in which it is executed is undertaking administration.
Similar to planning & project management for DWH (20)
1. Orderly Approach for DWH construction
2/23/2012 3.Planning & Project management/D.S.Jagli 1
2. Topics to be covered
1. How is it different?
2. Life-cycle approach
3. The Development Phases
4. Dimensional Analysis
5. Dimensional Modeling
i. Star Schema
ii. Snowflake Scheme
2/23/2012 3.Planning & Project management/D.S.Jagli 2
3. 3.Planning & Project management
Reasons for DWH projects failure
1. Improper planning
2. Inadequate project management
Planning for Data ware house is necessary.
I. Key issues needs to be planned
1. Value and expectation
2. Risk assessment
3. Top-down or bottom –up
4. Build or Buy
5. Single vender or best of breed
II. Business requirement ,not technology
III. Top management support
IV. Justification
2/23/2012 3.Planning & Project management/D.S.Jagli 3
5. 3.1 How is it different?
DWH Project Different from OLTP System Project
DWH Distinguish features and Challenges for Project
Management
1. Data Acquisition
2. Data Storage
3. Information Delivery
2/23/2012 3.Planning & Project management/D.S.Jagli 5
10. 3.3 DWH Development Phases
1) Project plan
2) Requirements definition
3) Design
4) Construction
5) Deployment
6) 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 10
11. 3.4 Dimensional Analysis
A data warehouse is an information delivery system.
It is not about technology, but about solving users’ problems.
It is providing strategic information to the user.
In the phase of defining requirements, need to concentrate on
what information the users need, not on how we are going to
provide the required information.
2/23/2012 3.Planning & Project management/D.S.Jagli 11
12. Dimensional Nature of DWH
1. 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.
2. 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 12
13. Managers think in business dimensions : example
2/23/2012 3.Planning & Project management/D.S.Jagli 13
14. Dimensional Nature of Business Data
2/23/2012 3.Planning & Project management/D.S.Jagli 14
15. Dimensional Nature of Business Data
2/23/2012 3.Planning & Project management/D.S.Jagli 15
16. Examples of Business Dimensions
2/23/2012 3.Planning & Project management/D.S.Jagli 16
17. Examples of Business Dimensions
2/23/2012 3.Planning & Project management/D.S.Jagli 17
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,
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 18
19. Requirements Not Fully Determinate
Information packages enable us to:
1. Define the common subject areas
2. Design key business metrics
3. Decide how data must be presented
4. Determine how users will aggregate or roll up
5. Decide the data quantity for user analysis or query
6. Decide how data will be accessed
7. Establish data granularity
8. Estimate data warehouse size
9. Determine the frequency for data refreshing
10. Determine how information must be packaged
2/23/2012 3.Planning & Project management/D.S.Jagli 19
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 21
22. Dimension Hierarchies/Categories
Examples:
1) Product: Model name, model year, package styling, product line, product category,
exterior color, interior color, first model year
2) Dealer: Dealer name, city, state, single brand flag, date first operation
3) Customer demographics: Age, gender, income range, marital status, household
size, vehicles owned, home value, own or rent
4) Payment method: Finance type, term in months, interest rate, agent
5) Time: Date, month, quarter, year, day of week, day of month, season, holiday flag
2/23/2012 3.Planning & Project management/D.S.Jagli 22
23. Key Business Metrics or Facts
The numbers , 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 23
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 24
26. FROM REQUIREMENTS TO DATA
DESIGN
1. The requirements definition completely drives the data design for the data
warehouse.
2. A group of data elements form a data structure.
3. Logical data design includes determination of the various data elements
,structures of data & establishing the relationships among the data
structures.
4. The information package diagrams form the basis for the logical data
design for the data warehouse.
5. The data design process results in a dimensional data model.
2/23/2012 3.Planning & Project management/D.S.Jagli 26
27. FROM REQUIREMENTS TO DATA DESIGN
2/23/2012 3.Planning & Project management/D.S.Jagli 27
28. Dimensional Modeling Basics: Formation of the automaker sales
fact table.
2/23/2012 3.Planning & Project management/D.S.Jagli 28
29. Formation of the automaker dimension tables.
2/23/2012 3.Planning & Project management/D.S.Jagli 29
30. Concept of Keys for Dimension table
Surrogate Keys
1. A surrogate key is the primary key for a dimension table and
is independent of any keys provided by source data systems.
2. Surrogate keys are created and maintained in the data
warehouse and should not encode any information about the
contents of records.
3. Automatically increasing integers make good surrogate keys.
4. The original key for each record is carried in the dimension
table but is not used as the primary key.
5. Surrogate keys provide the means to maintain data warehouse
information when dimensions change.
30
31. Concept of Keys for Dimension table
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
31
32. The criteria for combining the tables into a
dimensional model.
1. The model should provide the best data access.
2. The whole model must be query-centric.
3. It must be optimized for queries and analyses.
4. The model must show that the dimension tables interact with
the fact table.
5. It should also be structured in such a way that every
dimension can interact equally with the fact table.
6. The model should allow drilling down or rolling up along
dimension hierarchies.
2/23/2012 3.Planning & Project management/D.S.Jagli 32
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 33
34. Case study: STAR schema for automaker
sales.
2/23/2012 3.Planning & Project management/D.S.Jagli 34
35. E-R Modeling Versus Dimensional
Modeling
1. OLTP systems capture details of
events transactions 1. DW meant to answer questions on
overall process
2. OLTP systems focus on
individual events 2. DW focus is on how managers
view the business
3. An OLTP system is a window
into micro-level transactions 3. DW focus business trends
4. Picture at detail level necessary 4. Information is centered around a
to run the business business process
5. Suitable only for questions at 5. Answers show how the business
transaction level measures the process
6. Data consistency, non- 6. The measures to be studied in
redundancy, and efficient data many ways along several business
storage critical dimensions
2/23/2012 3.Planning & Project management/D.S.Jagli 35
36. E-R Modeling Versus Dimensional
Modeling
Dimensional modeling for the data
E-R modeling for OLTP warehouse.
systems
2/23/2012 3.Planning & Project management/D.S.Jagli 36
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.
4 Components
Facts
Dimensions
Attributes
Attribute Hierarchies
2/23/2012 3.Planning & Project management/D.S.Jagli 38
39. Facts
1. Numeric measurements (values) that represent a specific
business aspect or activity.
2. Stored in a fact table at the center of the star scheme.
3. Contains facts that are linked through their dimensions.
4. Updated periodically with data from operational databases
2/23/2012 3.Planning & Project management/D.S.Jagli 39
40. Dimensions
1. Qualifying characteristics that provide additional
perspectives to a given fact
DSS data is almost always viewed in relation to other data
2. Dimensions are normally stored in dimension tables
2/23/2012 3.Planning & Project management/D.S.Jagli 40
41. Attributes
1. Dimension Tables contain Attributes.
2. Attributes are used to search, filter, or classify facts.
3. Dimensions provide descriptive characteristics about the facts through
their attributed.
4. Must define common business attributes that will be used to narrow a
search, group information, or describe dimensions. (ex.: Time / Location /
Product).
5. 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 41
42. Attribute Hierarchies
1. Provides a Top-Down data organization
Aggregation
Drill-down / Roll-Up data analysis
2. Attributes from different dimensions can be grouped to
form a hierarchy
2/23/2012 3.Planning & Project management/D.S.Jagli 42
43. 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.
43
44. Star Schema for Sales
Dimension
Tables
Fact Table
2/23/2012 3.Planning & Project management/D.S.Jagli 44
45. 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 45
46. 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 46
47. Star Schema : advantages
1. Easy to understand
2. Optimizes Navigation
3. Most Suitable for Query Processing
2/23/2012 3.Planning & Project management/D.S.Jagli 47
49. 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 49
50. Sales: a simple STAR schema.
2/23/2012 3.Planning & Project management/D.S.Jagli 50
52. 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 52
53. Advantages and Disadvantages
Advantages
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 53
54. ???
Thank you
2/23/2012 3.Planning & Project management/D.S.Jagli 54