SQL Day 2011 - Modelowanie i zasilanie wymiarów hurtowni danych - łukasz grala

1,237 views
1,100 views

Published on

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,237
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • SQL Day 2011 - Modelowanie i zasilanie wymiarów hurtowni danych - łukasz grala

    1. 1. Modelowanie i zasilanie wymiarów w hurtowniach danych<br />___________________________________________________________________________________________________________________________________________________________________________<br />ŁUKASZ GRALA<br />Lider PLSSUG, MCT, MVP<br />SQLDAY 2011 – Czwarta Doroczna Konferencja Polskiej Grupy Użytkowników SQL Server<br /> | Wrocław 18 Czerwca 2011, Ośrodek Szkolenia Państwowej Inspekcji Pracy<br />Łukasz Grala – lukasz@grala.biz<br />
    2. 2. Łukasz grala<br />Niezależny konsultant, architekt, projektant (bazy i hurtownie danych, data mining, analiza danych, audyty baz danych – SQL Server, BI), SharePoint<br />Trener technologii Microsoft, wykładowca na wyższych uczelniach.<br />Lider Polish SQL Server User Group (PLSSUG) Poznań<br />Prelegent na wielu konferencjach informatycznych<br />Posiada liczne certyfikaty<br />Prowadzi blogi:<br />http://powerpivot.info.pl<br />http://sqlresearch.com<br />Kontakt:<br />lukasz@grala.biz<br />
    3. 3. Co to jest hurtownia danych?<br />Co to jest wymiar?<br />Wymiary i hierarchie<br />Zasilanie wymiarów<br />Slowly Changing Dimension<br />6 postać normalna<br />Mechanizmy w Microsoft SQL Server <br />Podsumowanie<br />Agenda<br />SQLDAY 2011 – Czwarta Doroczna Konferencja Polskiej Grupy Użytkowników SQL Server<br /> | Wrocław 18 Czerwca 2011, Ośrodek Szkolenia Państwowej Inspekcji Pracy<br />Łukasz Grala – lukasz@grala.biz<br />
    4. 4. Co to jest hurtownia danych?<br />Łukasz Grala – lukasz@grala.biz<br />Hurtownia danych (ang. Data Warehouse) – rodzaj bazy danych, która jest zorganizowana i zoptymalizowana pod kątem pewnego wycinka rzeczywistości<br />Najważniejsze cechy hurtowni danych:<br />Wyższy poziom abstrakcji<br />Dane do odczytu<br />Zintegrowane dane z wielu źródeł<br />Olbrzymia ilość danych<br />Dane historyczne<br />
    5. 5. Co to jest hurtownia danych?<br />Łukasz Grala – lukasz@grala.biz<br />Hurtownie danych<br />OLAP<br />OLTP<br />Struktury operacyjne<br />Kostki/ struktury<br />użytkownika<br />Struktury hurtowni danych<br />Dane operacyjne<br />Dane ujednolicone<br />Wybrane<br />dane<br />
    6. 6. Co to jest hurtownia danych?<br />5,005,000<br />Łukasz Grala – lukasz@grala.biz<br />
    7. 7. Co to jest wymiar?<br />Wymiar jest to logiczne grupowanie danych przechowywanych w tabelach faktów hurtowni danych<br />Łukasz Grala – lukasz@grala.biz<br />
    8. 8. Co to jest wymiar?<br />Tabele faktów<br />Łukasz Grala – lukasz@grala.biz<br />
    9. 9. Co to jest wymiar?<br />Tabele wymiaru<br />Łukasz Grala – lukasz@grala.biz<br />
    10. 10. Co to jest wymiar?<br />Hierarchia i agregacja<br />Łukasz Grala – lukasz@grala.biz<br />
    11. 11. Co to jest wymiar?<br />Schemat gwiazdy (ang. Star schema)<br />centralna tabela faktów powiązana z tabelami wybiarów <br />Łukasz Grala – lukasz@grala.biz<br />
    12. 12. Co to jest wymiar?<br />Łukasz Grala – lukasz@grala.biz<br />
    13. 13. Co to jest wymiar?<br />Schemat płatka śniegu (ang. Snowflake schema) <br />Znormalizowana postać schematu gwiazdy<br />Łukasz Grala – lukasz@grala.biz<br />Schemat konstelacji faktów (ang. Fact Constellation schema) <br />Tabele wymiarów współdzielone z wieloma tabelami faktów (wykorzystywany model płatka lub gwiazy)<br />
    14. 14. Zasilanie danych<br />Mechanizm ETL (ang Extracttion-Transformation-Load)<br />Ekstrakacja danych<br />Czyszczenie danych<br />Transformacja danych<br />Ładowanie danych<br />Replikacja danych<br />Analiza danych (wykrywanie nieprawidłowości)<br />Kontrola jakości danych<br />Łukasz Grala – lukasz@grala.biz<br />
    15. 15. Data Marts<br />Staging Area<br />Client Access<br />Manual Cleansing<br /> 9: Delivering BI enables a process of continuous business improvement<br /> 1: Clients need access to data<br /> 2: Clients may access data sources directly<br /> 3: Data sources can be mirrored/replicated to reduce contention<br /> 4: The data warehouse manages data for analyzing and reporting<br /> 5: Data warehouse is periodically populated from data sources<br /> 6: Staging areas may simplify the data warehouse population<br /> 7: Manual cleansing may be required to cleanse dirty data<br /> 8: Clients use various tools to query the data warehouse<br />Data Warehouse<br />Data Sources<br />Client Access<br />Łukasz Grala – lukasz@grala.biz<br />
    16. 16. Slowly Changing Dimension<br />Łukasz Grala – lukasz@grala.biz<br />Śledzenie i zapisywanie zachodzących zmian danych w wymiarach hurtowni danych<br />
    17. 17. Wszystkie typy SCD?<br />Łukasz Grala – lukasz@grala.biz<br />Typ 0 – Brak podjęcia działań<br />Typ 1 – Nadpisanie zmian<br />Typ 2 – Wstawienie nowego i unieważnienie istniejacego<br />Typ 3 – Zmiana w dodatkowej kolumnie<br />Typ 4 – Dodatkowa tabela (historyczna)<br />Typ 6/Hybrid – Połączenie typu 1 z 2 i 3.<br />
    18. 18. Slowly Changing Dimensions<br />Type 1<br />Istniejące rekordy są nadpisywane<br />Historia zmian nie jest przechowywana<br />LastName update to Valdez-Smythe<br />Łukasz Grala – lukasz@grala.biz<br />
    19. 19. Slowly Changing Dimensions<br />Type 2<br />Istniejący rekord traci wazność i jest wstawiany nowy<br />Historia zmian jest przechowywana<br />Wiele metod implementacji<br />SalesTerritoryKey update to 10<br />Łukasz Grala – lukasz@grala.biz<br />
    20. 20. Slowly Changing Dimensions<br />Istniejący rekord jest nadpisywany<br />Ograniczona historia jest przechowywana<br />Trudna implementacja<br />Type 3<br />SalesTerritoryKey update to 10<br />Łukasz Grala – lukasz@grala.biz<br />
    21. 21. Przykłady SCD – Typ 1<br />Łukasz Grala – lukasz@grala.biz<br />
    22. 22. Przykłady SCD – Typ 2<br />Łukasz Grala – lukasz@grala.biz<br />Wersja 1<br />
    23. 23. Przykłady SCD – Typ 2<br />Łukasz Grala – lukasz@grala.biz<br />Wersja 2<br />
    24. 24. Przykłady SCD – Typ 3<br />Łukasz Grala – lukasz@grala.biz<br />
    25. 25. Przykłady SCD – Typ 4<br />Łukasz Grala – lukasz@grala.biz<br />Tabela Handlowcy<br />Tabela Handlowcy_Archiwum<br />
    26. 26. Przykłady SCD – Typ 6<br />Łukasz Grala – lukasz@grala.biz<br />
    27. 27. Kreator SCD w SSIS<br />Step 1<br />Select the target dimension table<br />Configure the relationship between the source data and the dimension table<br />
    28. 28. Kreator SCD w SSIS<br />Step 2<br />Select the participating columns and their change type:<br />Fixed (Type 0)<br />Changing (Type 1)<br />Historical (Type 2)<br />
    29. 29. Kreator SCD w SSIS<br />Step 3<br />Configure the behavior if Fixed attributes change<br />Configure whether Changing attributes should update the current record or all matching records<br />
    30. 30. Kreator SCD w SSIS<br />Step 4<br />Configure how Historical attributes identify current and expired records:<br />Single Boolean column, or<br />Start and End date columns<br />Łukasz Grala – lukasz@grala.biz<br />
    31. 31. Kreator SCD w SSIS<br />Step 5<br />If inferred members are stored in the dimension table, define how they are identified:<br />When all columns with a change type are null, or<br />By a single Boolean column<br />Łukasz Grala – lukasz@grala.biz<br />
    32. 32. Kreator SCD w SSIS<br />Wizard Output<br />Based on your configuration, the wizard completes the downstream data flow<br />Łukasz Grala – lukasz@grala.biz<br />
    33. 33. 6 postać normalna (6NF)<br />Baza danych znajduje się w postaci 6NF wtedy i tylko wtedy gdy nie zawiera żadnych nietrywialnych zależności złączeń<br />Cechy 6NF<br />Reprezentacja danych tymczasowych<br />Zależność czasowa<br />Brak wsparcia w Microsoft SQL Server 2008R2 (i wcześniejszych)<br />Przykład implementacj: Dejan Sarka (MVP) – Inside Micorosft SQL Server 2008 – TSQL Programming<br />Łukasz Grala – lukasz@grala.biz<br />
    34. 34. Mechanizmy SQL Server<br />SQL Server Integration Services 2008/2008R – SCD (komponent i kreator)<br />SQL Server Analysis Services 2008/2008R2 (wymiary)<br />TSQL Merge<br />SQL Server Change Tracking<br />SQL Server Change Data Capture<br />Łukasz Grala – lukasz@grala.biz<br />
    35. 35. DEMO<br />Łukasz Grala – lukasz@grala.biz<br />
    36. 36. Dziękuję!<br />Strefa ATE<br />10.15-10.35<br />12.10-13.00<br />SQLDAY 2011 – Czwarta Doroczna Konferencja Polskiej Grupy Użytkowników SQL Server<br /> | Wrocław 18 Czerwca 2011, Ośrodek Szkolenia Państwowej Inspekcji Pracy<br />Łukasz Grala – lukasz@grala.biz<br />Lubię to!<br />
    37. 37. NASTĘPNA SESJA - 10:35<br />Collation<br />MAREK ADAMCZUK<br />SQLDAY 2011 – Czwarta Doroczna Konferencja Polskiej Grupy Użytkowników SQL Server<br /> | Wrocław 18 Czerwca 2011, Ośrodek Szkolenia Państwowej Inspekcji Pracy<br />Łukasz Grala – lukasz@grala.biz<br />
    38. 38. SPONSORZY I PARTNERZY<br />Łukasz Grala – lukasz@grala.biz<br />

    ×