Sql Server 2005 Business Inteligence
- 1. SQL Server 2005 Business Intelligence Presenter: Steve Schell
- 2. Overview Microsoft Business Intelligence Concepts General Philosophy High Level Data Path Database and Cube Models
- 4. General Philosophy Microsoft holds firm to the standard change management model: Dev / QA / PROD are mutually exclusive BI objects are developed by developers and maintained by analysts. Developers “play” in Dev only Analysts “play” in QA only Users “play” in PROD only
- 5. General Philosophy Microsoft also holds to a client-level development approach. Development is done on a local machine, NOT on the server This allows developers to customize their own version of the Dev environment Though Microsoft also recommends developing off of local versions of Cubes and Databases, we DO NOT follow this recommendation – we develop off the shared databases and Cubes on the server.
- 6. General Philosophy Needless to say, Microsoft takes a “developer-centric” approach to Business Intelligence. Ad-Hoc reporting by users is supported secondarily, though is best done through 3 rd party applications Microsoft also intends development be done using its own toolset – Visual Studio, SQL Server Management Studio and Excel.
- 7. General Philosophy Microsoft Business Intelligence best fits solutions that require a high level of customization. The high level of customization justifies the greater need for developer involvement. Microsoft Business Intelligence also best fits solutions that require a greater level of dynamic modularization Parameters allow for polymorphic reuse of BI objects throughout the solution.
- 8. High Level Data Path
- 9. High Level Data Path Microsoft breaks its Business Intelligence toolset into the following functions: Extraction-Transformation-Load (ETL): SQL Server Integration Services (SSIS) Data Aggregation and Analysis: SQL Server Analysis Services (SSAS) Reporting: SQL Server Reporting Services (SSRS)
- 10. High Level Data Path Extraction-Transformation-Load (ETL): Extraction – the process of obtaining data from an existing data source and staging it for transformation. Transformation – the process of changing the data into a form more useful for the destination data source Load – the process of loading the data into a destination data source, such as a Data Mart, Data Warehouse or OLAP Cube. SQL Server Integration Services provides all levels of ETL.
- 11. High Level Data Path Extraction-Transformation-Load (ETL):
- 12. High Level Data Path Data Aggregation and Analysis: Aggregation – the process of pre-calculating data using anticipated mathematical formulas and storing those pre-calculations for immediate database retrieval. Analysis – the process of employing data mining algorithms to reveal hidden relationships between business entities and transactions. SQL Server Analysis Services (SSAS) provides substantial Data Aggregation support via OLAP Cubes and a wide array of data mining algorithms for Data Analysis.
- 13. High Level Data Path Database Aggregations 400 Jane 100 John 200 Jane 300 John Amount Sales 400 200 300 600 Jane 300 100 200 400 John 400 100 250 1000 Total Maximum Minimum Average Sum Sales
- 14. High Level Data Path Reporting: Presentation – reports must provide organized and attractive layouts for viewing data. Availability – reports must be available on demand at a central location for users. Security – controls must restrict access to reporting data where appropriate. SQL Server Reporting Services (SSRS) provides development and administration for all these needs.
- 15. High Level Data Path
- 16. Database and Cube Models
- 17. Database and Cube Models Online Transaction Processing (OLTP) Database An OLTP database is your normal “working” database. Uses a relational database model, usually up to 3 rd normal form. It is built to support fast and flexible transaction processing. Most tables are designed to hold status information. Historical information is usually purged after 1 to 3 years.
- 18. Database and Cube Models Online Analytical Processing (OLAP) Database An OLAP database is a secondary “reporting” database, built off of your OLTP database. These take the form of Data Marts and/or Data Warehouses. Uses a star or snowflake schema model, which is heavily de-normalized. It is built to support quick retrieval of historical data for reporting purposes. Depending on its reporting uses, data may never be purged.
- 19. Database and Cube Models Star and Snowflake Schemas At the core of a star and snowflake schema are FACT tables FACT tables are basically “the spine of the database animal”. FACT tables detail the historical events recorded in the database, which are referred to as measures. An example of a measure would be a sales amount, a productivity time span, or a referral status. FACT tables are linked by foreign keys to description tables known as DIMENSION tables.
- 20. Database and Cube Models Star and Snowflake Schemas DIMENSION tables describe the entities related to each event recorded in a FACT table. Because the star and snowflake schema is de-normalized, each row in a FACT table will have numerous foreign keys to DIMENSION tables. DIMENSION tables also use “surrogate” keys to record historical changes to database entities. For example, if “John Doe” changed his name to “Jack Doe” in the OLTP database, OLAP will have two entries for each name, each with its own surrogate key. Snowflake schemas are star schemas with multiple layers of DIMENSION tables
- 21. Database and Cube Models Star Schema Example
- 22. Database and Cube Models Snowflake Schema Example
- 23. Database and Cube Models Online Analytical Processing (OLAP) Cube An OLAP Cube is normally a tertiary “reporting” database. It is basically an exploded view of your Data Marts and/or Data Warehouses. It is exploded in that its main purpose is the storage and quick retrieval of pre-calculated data aggregates (sums, averages, etc.). It too follows a star or snowflake schema, but is best used in organizing hierarchical dimensions found in snowflake schemas.
- 24. Database and Cube Models Online Analytical Processing (OLAP) Cube SSAS supports three forms of the OLAP Cube: ROLAP, MOLAP and HOLAP. ROLAP: A less aggregated version of OLAP Has a slower data retrieval rate due to the increased number of data calculations. Requires minimal storage capacity. Best used in models that are highly dependant on relational data for reporting. Processed faster, and in some cases can be setup with real-time updates.
- 25. Database and Cube Models Online Analytical Processing (OLAP) Cube SSAS supports three forms of the OLAP Cube: ROLAP, MOLAP and HOLAP. MOLAP: A highly aggregated version of OLAP Has a faster data retrieval rate due to more pre-calculated data. Requires substantial storage capacity Best used in models that work well within the star/snowflake schema. Processes slower, which is usually done once daily.
- 26. Database and Cube Models Online Analytical Processing (OLAP) Cube SSAS supports three forms of the OLAP Cube: ROLAP, MOLAP and HOLAP. HOLAP: A mid-level hybrid of ROLAP and MOLAP Takes the best of both worlds in retrieval speed, storage capacity and processing time. Of the three forms, MOLAP is preferred for reporting due to faster data retrieval time.
- 27. Questions?
- 28. Thank you!