SQL Day 2011 - Modelowanie i zasilanie wymiarów hurtowni danych - łukasz grala
1. Modelowanie i zasilanie wymiarów w hurtowniach danych ___________________________________________________________________________________________________________________________________________________________________________ ŁUKASZ GRALA Lider PLSSUG, MCT, MVP SQLDAY 2011 – Czwarta Doroczna Konferencja Polskiej Grupy Użytkowników SQL Server | Wrocław 18 Czerwca 2011, Ośrodek Szkolenia Państwowej Inspekcji Pracy Łukasz Grala – lukasz@grala.biz
2. Łukasz grala Niezależny konsultant, architekt, projektant (bazy i hurtownie danych, data mining, analiza danych, audyty baz danych – SQL Server, BI), SharePoint Trener technologii Microsoft, wykładowca na wyższych uczelniach. Lider Polish SQL Server User Group (PLSSUG) Poznań Prelegent na wielu konferencjach informatycznych Posiada liczne certyfikaty Prowadzi blogi: http://powerpivot.info.pl http://sqlresearch.com Kontakt: lukasz@grala.biz
3. Co to jest hurtownia danych? Co to jest wymiar? Wymiary i hierarchie Zasilanie wymiarów Slowly Changing Dimension 6 postać normalna Mechanizmy w Microsoft SQL Server Podsumowanie Agenda SQLDAY 2011 – Czwarta Doroczna Konferencja Polskiej Grupy Użytkowników SQL Server | Wrocław 18 Czerwca 2011, Ośrodek Szkolenia Państwowej Inspekcji Pracy Łukasz Grala – lukasz@grala.biz
4. Co to jest hurtownia danych? Łukasz Grala – lukasz@grala.biz Hurtownia danych (ang. Data Warehouse) – rodzaj bazy danych, która jest zorganizowana i zoptymalizowana pod kątem pewnego wycinka rzeczywistości Najważniejsze cechy hurtowni danych: Wyższy poziom abstrakcji Dane do odczytu Zintegrowane dane z wielu źródeł Olbrzymia ilość danych Dane historyczne
5. Co to jest hurtownia danych? Łukasz Grala – lukasz@grala.biz Hurtownie danych OLAP OLTP Struktury operacyjne Kostki/ struktury użytkownika Struktury hurtowni danych Dane operacyjne Dane ujednolicone Wybrane dane
6. Co to jest hurtownia danych? 5,005,000 Łukasz Grala – lukasz@grala.biz
7. Co to jest wymiar? Wymiar jest to logiczne grupowanie danych przechowywanych w tabelach faktów hurtowni danych Łukasz Grala – lukasz@grala.biz
8. Co to jest wymiar? Tabele faktów Łukasz Grala – lukasz@grala.biz
9. Co to jest wymiar? Tabele wymiaru Łukasz Grala – lukasz@grala.biz
10. Co to jest wymiar? Hierarchia i agregacja Łukasz Grala – lukasz@grala.biz
11. Co to jest wymiar? Schemat gwiazdy (ang. Star schema) centralna tabela faktów powiązana z tabelami wybiarów Łukasz Grala – lukasz@grala.biz
12. Co to jest wymiar? Łukasz Grala – lukasz@grala.biz
13. Co to jest wymiar? Schemat płatka śniegu (ang. Snowflake schema) Znormalizowana postać schematu gwiazdy Łukasz Grala – lukasz@grala.biz Schemat konstelacji faktów (ang. Fact Constellation schema) Tabele wymiarów współdzielone z wieloma tabelami faktów (wykorzystywany model płatka lub gwiazy)
14. Zasilanie danych Mechanizm ETL (ang Extracttion-Transformation-Load) Ekstrakacja danych Czyszczenie danych Transformacja danych Ładowanie danych Replikacja danych Analiza danych (wykrywanie nieprawidłowości) Kontrola jakości danych Łukasz Grala – lukasz@grala.biz
15. Data Marts Staging Area Client Access Manual Cleansing 9: Delivering BI enables a process of continuous business improvement 1: Clients need access to data 2: Clients may access data sources directly 3: Data sources can be mirrored/replicated to reduce contention 4: The data warehouse manages data for analyzing and reporting 5: Data warehouse is periodically populated from data sources 6: Staging areas may simplify the data warehouse population 7: Manual cleansing may be required to cleanse dirty data 8: Clients use various tools to query the data warehouse Data Warehouse Data Sources Client Access Łukasz Grala – lukasz@grala.biz
16. Slowly Changing Dimension Łukasz Grala – lukasz@grala.biz Śledzenie i zapisywanie zachodzących zmian danych w wymiarach hurtowni danych
17. Wszystkie typy SCD? Łukasz Grala – lukasz@grala.biz Typ 0 – Brak podjęcia działań Typ 1 – Nadpisanie zmian Typ 2 – Wstawienie nowego i unieważnienie istniejacego Typ 3 – Zmiana w dodatkowej kolumnie Typ 4 – Dodatkowa tabela (historyczna) Typ 6/Hybrid – Połączenie typu 1 z 2 i 3.
18. Slowly Changing Dimensions Type 1 Istniejące rekordy są nadpisywane Historia zmian nie jest przechowywana LastName update to Valdez-Smythe Łukasz Grala – lukasz@grala.biz
19. Slowly Changing Dimensions Type 2 Istniejący rekord traci wazność i jest wstawiany nowy Historia zmian jest przechowywana Wiele metod implementacji SalesTerritoryKey update to 10 Łukasz Grala – lukasz@grala.biz
20. Slowly Changing Dimensions Istniejący rekord jest nadpisywany Ograniczona historia jest przechowywana Trudna implementacja Type 3 SalesTerritoryKey update to 10 Łukasz Grala – lukasz@grala.biz
27. Kreator SCD w SSIS Step 1 Select the target dimension table Configure the relationship between the source data and the dimension table
28. Kreator SCD w SSIS Step 2 Select the participating columns and their change type: Fixed (Type 0) Changing (Type 1) Historical (Type 2)
29. Kreator SCD w SSIS Step 3 Configure the behavior if Fixed attributes change Configure whether Changing attributes should update the current record or all matching records
30. Kreator SCD w SSIS Step 4 Configure how Historical attributes identify current and expired records: Single Boolean column, or Start and End date columns Łukasz Grala – lukasz@grala.biz
31. Kreator SCD w SSIS Step 5 If inferred members are stored in the dimension table, define how they are identified: When all columns with a change type are null, or By a single Boolean column Łukasz Grala – lukasz@grala.biz
32. Kreator SCD w SSIS Wizard Output Based on your configuration, the wizard completes the downstream data flow Łukasz Grala – lukasz@grala.biz
33. 6 postać normalna (6NF) Baza danych znajduje się w postaci 6NF wtedy i tylko wtedy gdy nie zawiera żadnych nietrywialnych zależności złączeń Cechy 6NF Reprezentacja danych tymczasowych Zależność czasowa Brak wsparcia w Microsoft SQL Server 2008R2 (i wcześniejszych) Przykład implementacj: Dejan Sarka (MVP) – Inside Micorosft SQL Server 2008 – TSQL Programming Łukasz Grala – lukasz@grala.biz
34. Mechanizmy SQL Server SQL Server Integration Services 2008/2008R – SCD (komponent i kreator) SQL Server Analysis Services 2008/2008R2 (wymiary) TSQL Merge SQL Server Change Tracking SQL Server Change Data Capture Łukasz Grala – lukasz@grala.biz
36. Dziękuję! Strefa ATE 10.15-10.35 12.10-13.00 SQLDAY 2011 – Czwarta Doroczna Konferencja Polskiej Grupy Użytkowników SQL Server | Wrocław 18 Czerwca 2011, Ośrodek Szkolenia Państwowej Inspekcji Pracy Łukasz Grala – lukasz@grala.biz Lubię to!
37. NASTĘPNA SESJA - 10:35 Collation MAREK ADAMCZUK SQLDAY 2011 – Czwarta Doroczna Konferencja Polskiej Grupy Użytkowników SQL Server | Wrocław 18 Czerwca 2011, Ośrodek Szkolenia Państwowej Inspekcji Pracy Łukasz Grala – lukasz@grala.biz
Use this animated slide to demystify how results are retrieved from cubes. Point out that in reality cubes are more than just three dimensions; this example is greatly simplified.
The dimensional model is called a star schema because (with some imagination) it looks like a star. The terms dimensional model and star schema can be used interchangeably.This slide effectively illustrates how the model looks like a star. Emphasize that the star schema is a relational database schema organized around a central table known as a fact table. The points on the star are the dimension tables. Briefly provide examples of both types of tables and point out the dimension keys and measures in the fact table. But reserve a more complete discussion of them for the following slides.
Spend time building up this slide. Note that the main points on this slide will be covered in the slides that follow.Build 1: Introduces source systems and client access. Mention a common requirement for information workers to analyze and report on this data.Build 2: Should the information workers connect directly to these systems? Remind students of the points on the slide about common information problems: Performance impact, availability, cleanliness, historical context preservation, and end user skills and tools.Build 3: Focuses on source system mirroring. Mention that database mirroring (an availability feature introduced with SQL Server 2008) could make a read-only copy of the database available to reduce the impact on the source database.Build 4: Introduces the data warehouse, which consists of data marts, a multidimensional database, data mining models and data feeds. The data warehouse system can overcome many of the issues raised in Build 2, but it implies that the data must be copied from the source systems…Build 5: Highlights the ETL process. Mention that the data from the source systems needs to be periodically extracted and loaded into the data marts. These data marts commonly have a particular schema design optimized for querying, so the data will need to be transformed. Introduce the term ETL—extract, transform, and load.Build 6: Introduces the staging systems. Performing the ETL in one process may be difficult to achieve because of the complexity of transformations or the need to cleanse the data. Mention that staging systems are optional and that the technologies introduced in this course (e.g., SSIS) may challenge this traditional need. Note that staging is still an important design consideration because it provides convenient restartability of the ETL process without the need to disturb the source systems.Build 7: Manual cleansing may be required to fix problematic data. This is expensive in terms of human resources and time. Mention that the technologies introduced in this course (e.g., SSIS) may be able to address this problem.Build 8: Client access can take many forms—for example, via browsing tools, reports, spreadsheets, dashboards, and so on.. Stress that, ideally, clients extract their data from the “one version of the truth.” Discuss the different types of users: power users, analysts and their different needs.Build 9: Emphasize that this is a continuous process of monitoring, analyzing and planning.
Slowly changing dimension Type 1 restates history. An in-place change records that the member has always been that way. Note that no surrogate keys are required to manage this type (but are still recommended for other reasons discussed earlier).
Slowly changing dimension Type 2 tracks history with versioning. It is more complex to manage but provides accurate historical reporting.
Slowly changing dimension Type 3 provides limited history. It is difficult to manage when there are many changes and is also difficult to query from. For these reasons, this type is rarely implemented.
Step 1: The dimension table needs to be selected and the business key(s) configured. This allows the transformation to correlate the data.
Step 2: Select the columns that must have their changes managed. Be sure to clarify the terms that the wizard uses for the different types.
Step 3: Configure what the transformation does if Fixed attributes change (the check box is disabled in this slide because no columns were configured as Fixed attributes). A Fixed Attribute Output is available to isolate the records. If Changing attributes change, you can configure the update to affect all records (relevant where Type 2 changes are managed on the table) or just the current record. Essentially, the update statement that changes the record will have its WHERE clause set to either the business key or surrogate key, respectively.
Step 4: If Historical changes have been configured, define how the current row can be isolated: as a Boolean column or as Start/End dates. The latter is considered the best practice because it provides richer information that may be useful in later analysis and for updating historical fact records.
Step 5: If inferred members are stored in the table, configure how they will be identified. This is important because late-arriving dimension details should not be interpreted to be a Type 2 change! Once the late-arriving details are updated, then during subsequent loads, updates can be managed according to the change configurations.
Upon completing, the wizard completes the downstream data flow that may be modified if required. Note that it is possible to rerun the wizard, and it will remember your configuration, but it will overwrite the downstream data flow. Take care to document any customizations beyond the wizard configuration if you decide to rerun the wizard.