Why OLAP? How OLAP.
•Download as PPTX, PDF•
3 likes•2,137 views
201202 - Session 1 Why OLAP? How OLAP. Gogula Aryalingam (@gogula)
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Why OLAP? How OLAP.
- 1. WHY OLAP? HOW OLAP. GOGULA G. ARYALINGAM TECHNICAL LEAD NAVANTIS IT PVT. LTD. LEVEL 200
- 3. OLTP
- 6. OLTP Limitations of OLTP Designed to efficiently stored data Reporting and Analysis suffer
- 7. OLTP Limitations of OLTP Designed to efficiently stored data Reporting and Analysis suffer Stores only current (and recent history) data
- 8. OLTP Limitations of OLTP Designed to efficiently stored data Reporting and Analysis suffer Stores only current (and recent history) data Data structure not intuitive
- 9. ANSWER TO A SIMPLE QUESTION… How many bikes were ordered from Australia on an yearly basis?
- 10. ANSWER TO ANOTHER SIMPLE QUESTION… How many bikes were ordered from Australia on an yearly basis, broken down in months?
- 11. AND THE LIST OF QUESTIONS GO ON…
- 13. CUBES 65 55 75 70 60 45 50 60 55 North Central South March April May Bikes Accessories Clothing
- 14. CUBES ARE MADE OF THESE... Sales Amount Sales Target Product Name Category Color Date Date Month Year Region Name Country Measures Dimensions
- 15. CUBES 65 55 75 70 60 45 50 60 55 North Central South March April May Bikes Accessories Clothing
- 16. BEHIND THE SCENES Data Warehouses or Data Marts Dimensional modeling OLAP (Online Analytical Processing) databases SQL Server Analysis Services (SSAS)
- 17. BEHIND THE SCENES OLTP (Source) Database Data Warehouse or Data Mart OLAP Database ETL Process SQL Server Database Engine SQL Server Integration Services (SSIS) SQL Server Database Engine SQL Server Analysis Services (SSAS) 1
- 18. BEHIND THE SCENES OLTP (Source) Database OLAP Database Process Database Views over OLTP (Source) Database SQL Server Database Engine SQL Server Analysis Services (SSAS) 2
- 19. BEHIND THE SCENES OLTP (Source) Database OLAP Database Process SSAS Data Source Views over OLTP (Source) Database SQL Server Database Engine SQL Server Analysis Services (SSAS) 3
- 20. THIS IS HOW IT’S DONE…
- 21. QUESTIONS
- 22. REFERENCES • Wikipedia • OLAP: http://en.wikipedia.org/wiki/Online_analytical_processing • Cubes: http://en.wikipedia.org/wiki/OLAP_cube • Technet • SQL Server Analysis Services: http://technet.microsoft.com/en-us/library/bb522607.aspx • Analysis Services Tutorial: http://technet.microsoft.com/en- us/library/ms170208.aspx • SSAS Wiki: http://ssas-wiki.com/
- 23. CONTACT • gogulaa@gmail.com • @gogula • http://dbantics.wordpress.com • http://sqlserveruniverse.com
Editor's Notes
- This presentation is divided into two sections: Why OLAP: Why OLAP is necessary How OLAP: What OLAP is and how it can be implemented. The presentation is in Level 200
- Section 1: Why OLAP?
- Online Transaction Processing (OLTP) databases are great for efficient storage of day-to-day transactional data. The database is normalized so that tables go into many levels. For example, you could find the Products entity broken across 3 tables such as Product -> ProductSubcategory -> ProductCategory. This minimizes the amount of data that gets duplicated. A very clever design.
- This presentation is not about OLTP, nor about how great it is; We shall instead, look at its limitations…
- Like I had mentioned two slides ago, an OLTP database is designed for efficient data storage. Then why is this feature listed under “Limitations of OLTP” ?
- This very feature; efficiency in data storage is what kills reporting and analysis (especially when you look at enterprise reporting that spans across large periods of time and great numbers of records). Say you have a database which deals with millions of records each month, and about 30 people work on the database simultaneously, the database handles frequent transactions, and you have to answer the following question through a report: “What is the sales breakdown for each region, month-wise for the current year?” – You will have to pull out a great million records, from your OLTP database, resulting in slow data retrieval due to: many joins, large number of records and locks on data because others are using the database. You will also impose difficulty on the 30 users because of your gigantic need for data.
- Another feature of a (properly designed) OLTP database is that historical data (i.e. old data, such as completed transactions from several years ago) are archived, or in some cases, deleted altogether. This poses problems when you need to perform reporting against 5 years ago, such as “What is my increase in sales from 5 years ago in the eastern region?” – You may have archived data from 5 years ago, which may now have to be fished out from some other location, before you could answer this question.
- Another minor issue is that OLTP database names are usually named in a cryptic form that many business users (the users who do the reporting and analysis) will not understand: you may name a table like this: tbl_sls_prod_hist_det and all tables in a similar manner. Then, since entities are broken down into many layers like tbl_sls_prd_cat -> tbl_sls_prd_subcat -> tbl_sls_prd_prod; figuring out the data structure itself will eat up the business users’ time.
- Take a look at the query on the slide. It tries to answer the question: “How many bikes were ordered from Australia on an yearly basis?” – A business user performing analysis, will not only want this data. He would want to see the same thing with a slight twist: same question but with a monthly breakdown, which would require an alteration of the query into what’s on the next slide…
- When analyzing data, a business user will not just want to look at data from just two slightly varying angles like this. They would want to look at data from so many different sides…
- With so many little variations. They cannot be writing so many different queries…
- In the previous section we looked at some reasons why an OLTP database will not suit certain situations. The answer to those problems is OLAP (OnLine Analytical Processing).
- OLAP deals with cubes. Think of cubes as multi-dimensional tables as opposed to the 2 dimensional tables that you have in OLTP. Data that is spread across multiple tables in OLTP can be put into one cube based on their relationships.
- A cube is made up of two things: Measures and Dimensions. Measures are those values that a business user will want to measure , such as [Sales Amount], [Sales Target], [Quantity Ordered], [Number of Phone Calls Made] etc. Measures are almost always numeric. Measures are also called “Facts” Dimensions are the viewpoints (or perspectives) in which a business user will view or analyze the data. For example, the user will want to look at the [Sales Amount] measure from the [Product] viewpoint, or from the [Date] viewpoint. Another example is when a user wants to see the [Quantity Ordered] according to the [Product] categories, and the Year. Without dimensions the measures will have no much value. Dimensions have attributes, so that a business user can analyze the data using the different attributes. For example, the [Sales Amount] can be analyzed using the [Year] attribute of the [Date] dimension, then by the [Month] attribute, and finally by the [Category] and [Subcategory] attributes of the [Product] dimesions. Dimensions also have hierarchies of attributes, to make analysis even easier. For example, the [Product] dimension can have a hierarchy created as follows: [Category] -> [Subcategory] -> [Product].
- Take a look at the cube above. It has one measure (let’s assume it to be sales quantities) and three dimensions: Region, Products and Date. If a business user wants to find out the sales quantity in the Central region in May for Bikes, she would find it in the cell where all the dimensions intersect.
- Looking at the stuff behind the scenes in OLAP, we have the following: Data Warehouse or Data Marts: These are specially designed databases to support OLAP. These are designed on top of a relational database system, just like an OLTP database, except that the structure for OLAP is different, focusing on faster and more efficient data retrieval Dimensional modeling: Is one of the main methods to design a data warehouse or mart. This method deals with fact tables and dimension tables. This modeling method was advocated by the famous data warehouse guru, Ralph Kimball. OLAP databases: Are special databases for holding cubes SSAS: Is the offering from Microsoft to build OLAP applications. SSAS comes with Microsoft SQL Server. There are a few methods to implement OLAP, which I shall introduce to you at a high level now…
- 1. Build a data warehouse or a data mart. Perform ETL (Extract, transform and load) on the data from the source database and load it onto the data warehouse or data mart on a periodic basis. Perform a process called ‘processing’ to load the data from the DW or DM to the OLAP database. Please note that in a lot of situations the OLTP database will not be the only source of data. Usually, you have multiple different types of source such as Excel files, text files, Oracle databases and more.
- 2. Here, instead of building a DW or DM, we just create database views that would mimic a data warehouse or data mart, on the OLTP database iteself. This set of views will be the source for the OLAP database. ETL is not required. This method is suitable when you have an OLTP with a lower number of transactions, smaller number of concurrent transactions and lesser data load. It is only suitable for situations where the OLTP database is the only source for the cubes.
- 3. This method is similar to the second, except that the views are created in the SSAS development environment itself. This method also supports having multiple different data sources. However, this method too falls under the constraints posed on the previous method (method 2).
- The demo code should be available as a separate download on the site.