Schemat gwiazdy

Dziś raporty i analityka są prawie tak samo ważne jak podstawowa działalność. Raporty można budować na podstawie aktualnych danych; często takie podejście załatwia sprawę małym i średnim firmom bez dużej ilości danych. Ale kiedy sprawy stają się większe – lub ilość danych zaczyna gwałtownie rosnąć – nadszedł czas, aby pomyśleć o rozdzieleniu systemów operacyjnych i raportowania.

Zanim zajmiemy się podstawowym modelowaniem danych, potrzebujemy trochę informacji na temat zaangażowanych systemów. Systemy możemy z grubsza podzielić na dwie kategorie:systemy operacyjne i raportowe. Systemy operacyjne są często nazywane Online Transaction Processing (OLTP). Systemy raportowania i analizy określane są jako przetwarzanie analityczne online (OLAP). Systemy OLTP wspierają procesy biznesowe. Pracują z „żywymi” danymi operacyjnymi, są w wysokim stopniu znormalizowane i bardzo szybko reagują na działania użytkowników. Z drugiej strony podstawowym celem systemów OLAP jest analityka. Systemy te wykorzystują dane sumaryczne, które są zwykle umieszczane w zdenormalizowanej strukturze hurtowni danych, takiej jak schemat gwiaździsty. (Co to jest denormalizacja? Mówiąc najprościej, ma nadmiarowe rekordy danych ze względu na lepszą wydajność. Czytaj więcej.)

Teraz, gdy wiemy trochę o systemach, zacznijmy badać hurtownię danych oraz jej elementy i procesy.

Hurtowni danych a hurtownie danych

Hurtownia danych (DWH) to system służący do przechowywania informacji do wykorzystania w analizie danych i raportowaniu. Terminy danych to obszary hurtowni danych służące do przechowywania informacji potrzebnych pojedynczemu działowi lub nawet indywidualnemu użytkownikowi. (Pomyśl o DWH jako budynku, a bazach danych jako biurach wewnątrz budynku.)

Dlaczego potrzebne są hurtownie danych? Wszystkie istotne dane są przechowywane w firmie DWH. Większość użytkowników potrzebuje jednak dostępu tylko do określonych podzbiorów danych, takich jak te dotyczące sprzedaży, produkcji, logistyki lub marketingu. Zbiory danych są ważne zarówno z punktu widzenia bezpieczeństwa (ograniczenie niepotrzebnego dostępu), jak i użytkownika (nie chcemy ich mylić ani zmuszać do przedzierania się przez obce dane).

Istnieją dwa różne podejścia do relacji hurtowni danych z hurtownią danych:

Od góry do dołu :Bazy danych są tworzone z hurtowni danych. (Jest to coś, z czym zgodziłby się Bill Inmon, „ojciec hurtowni danych”, wraz z ideą, że hurtownie powinny być w 3NF.)
Od dołu do góry :Bazy danych są tworzone jako pierwsze, a następnie łączone w hurtownię danych. (To podejście jest bliższe temu, co zaleca Ralph Kimball, ekspert ds. hurtowni danych i modelowania wymiarowego).

Proces ETL służy do regularnego dodawania „nowych” danych do systemu OLAP. ETL to skrót od Extract, Transform and Load. Jak sama nazwa wskazuje, wyodrębnimy dane z jednej lub więcej operacyjnych baz danych, przekształcimy je tak, aby pasowały do naszej struktury magazynu i załadujemy dane do DWH.

Modelowanie wymiarowe , który jest częścią projektowania hurtowni danych, skutkuje stworzeniem modelu wymiarowego. W grę wchodzą dwa rodzaje tabel:

Tabele wymiarów służą do opisu danych, które chcemy przechowywać. Na przykład:sprzedawca detaliczny może chcieć przechowywać datę, sklep i pracownika zaangażowanego w konkretny zakup. Każda tabela wymiarów jest własną kategorią (data, pracownik, sklep) i może mieć jeden lub więcej atrybutów . Dla każdego sklepu możemy zapisać jego lokalizację na poziomie miasta, regionu, województwa i kraju. Dla każdej daty możemy przechowywać rok, miesiąc, dzień miesiąca, dzień tygodnia itp. Jest to związane z hierarchią atrybutów w tabeli wymiarów.

W schemacie gwiaździstym zwykle stwierdzamy, że niektóre atrybuty są podzbiorem innych atrybutów w tym samym rekordzie. Ta redundancja jest celowa i wykonywana w imię lepszej wydajności. Moglibyśmy użyć wymiarów daty, lokalizacji i agenta sprzedaży do agregacji (część przekształcania procesu ETL) i przechowywania danych w DWH. W modelowaniu wymiarowym bardzo ważne jest zdefiniowanie odpowiednich wymiarów i wybór odpowiedniej granulacji.
Tabele faktów zawierają dane, które chcemy uwzględnić w raportach, zagregowane na podstawie wartości w powiązanych tabelach wymiarów. Tabela faktów zawiera tylko kolumny, które przechowują wartości i klucze obce odwołujące się do tabel wymiarów. Połączenie wszystkich kluczy obcych tworzy klucz podstawowy tabeli faktów. Na przykład tabela faktów może przechowywać liczbę kontaktów i liczbę sprzedaży wynikających z tych kontaktów.

Mając te informacje, możemy teraz zagłębić się w model danych schematu gwiazdy.

Schemat gwiazdy

Schemat gwiazdy to najprostszy model stosowany w DWH. Ponieważ tabela faktów znajduje się na środku schematu, a wokół niej znajdują się tabele wymiarów, wygląda z grubsza jak gwiazda. Jest to szczególnie widoczne, gdy tabela faktów jest otoczona pięcioma tabelami wymiarów. Wariant schematu gwiaździstego schemat stonogi , gdzie tabela faktów jest otoczona dużą liczbą małych tabel wymiarów.

Schematy gwiaździste są bardzo często używane w hurtowniach danych. Możemy je powiązać z podejściem odgórnego modelu danych. Przeanalizujemy dwa schematy gwiaździste (markety danych), a następnie połączymy je w jeden model.

Przykład schematu gwiazdek:sprzedaż

Raport sprzedaży to jeden z najczęstszych raportów w dzisiejszych czasach. Jak wspomnieliśmy wcześniej, w większości przypadków mogliśmy generować raporty sprzedaży z systemu live. Ale gdy rozmiar danych lub firmy sprawia, że jest to zbyt uciążliwe, będziemy musieli zbudować hurtownię danych lub hurtownię danych, aby usprawnić proces. Po zaprojektowaniu naszego schematu gwiazdy ETL proces pobierze dane z operacyjnych baz danych, przekształci dane do odpowiedniego formatu dla DWH i załaduje dane do hurtowni.

Przedstawiony powyżej model zawiera jedną tabelę faktów (w kolorze jasnoczerwonym) oraz pięć tabel wymiarów (w kolorze jasnoniebieskim). Tabele w modelu to:

fact_sales – Ta tabela zawiera odniesienia do tabel wymiarów oraz dwa fakty (cena i sprzedana ilość). Zwróć uwagę, że wszystkie pięć kluczy obcych razem tworzy klucz podstawowy tabeli.
dim_sales_type – Jest to tabela wymiarów typu sprzedaży z tylko jednym atrybutem „type_name ”.
dim_employee – To jest tabela wymiarów pracowników, która przechowuje podstawowe atrybuty pracownika:imię i nazwisko oraz rok urodzenia.
dim_product – To jest tabela wymiarów produktu z tylko dwoma atrybutami (innymi niż klucz podstawowy):nazwa produktu i typ produktu.
dim_time – Ta tabela obsługuje wymiar czasu. Zawiera pięć atrybutów oprócz klucza podstawowego. Dane najniższego poziomu to sprzedaż według daty (action_date ). action_week atrybut jest numerem tygodnia w danym roku (tj. pierwszy tydzień stycznia otrzymałby liczbę 1; ostatni tydzień grudnia otrzymałby liczbę 52 itd.) actual_month i actual_year atrybuty przechowują miesiąc i rok kalendarzowy, w którym nastąpiła sprzedaż. Można je pobrać z action_date atrybut. action_weekday atrybut przechowuje nazwę dnia, w którym miała miejsce sprzedaż.
dim_store – To wymiar sklepu. Dla każdego sklepu zapiszemy miasto, region, stan i kraj, w którym się znajduje. Tutaj możemy wyraźnie zauważyć, że schemat gwiazdy jest zdenormalizowany.

Przykład schematu gwiazdy:zamówienia dostaw

Istnieje wiele podobieństw między tym modelem, pokazanym poniżej, a modelem sprzedaży.

Model ten przeznaczony jest do przechowywania historii złożonych zamówień. Mamy jedną tabelę faktów i cztery tabele wymiarów. Tabele wymiarów dim_employee , dim_product i dim_time są dokładnie takie same jak w modelu sprzedaży. Jednak poniższe tabele są różne:

fact_supply_order – zawiera zagregowane dane o złożonych zamówieniach.
dim_supplier – jest tabelą wymiarów, która przechowuje dane dostawcy w taki sam sposób jak dim_store utrzymywał dane sklepu w modelu sprzedaży.

Zalety i wady schematu gwiazdy

Korzystanie ze schematu gwiazdy ma wiele zalet. Tabela faktów jest powiązana z każdą tabelą wymiarów dokładnie jedną relacją i nie potrzebujemy żadnych dodatkowych słowników do opisywania tabel wymiarów. Upraszcza to zapytania i skraca czas wykonania zapytania. Moglibyśmy wygenerować ten sam raport bezpośrednio z naszego systemu OLTP, ale zapytanie byłoby znacznie bardziej złożone i mogłoby wpłynąć na ogólną wydajność systemu. Poniższe przykładowe zapytanie dla modelu sprzedaży zwróci ilość wszystkich produktów typu telefon sprzedanych w berlińskich sklepach w 2016 roku:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Największą wadą schematu gwiazdy jest nadmiarowość. Każdy wymiar jest przechowywany w osobnej tabeli wymiarów, co powoduje denormalizację. W naszym przykładzie miasto należy do regionu lub stanu, który należy do kraju; z reguły nie przechowujemy tej relacji w naszej bazie danych, ale ciągle ją powtarzamy. Oznacza to, że wydamy więcej miejsca na dysku i będziemy mieć ryzyko integralności danych.

Schemat galaktyki

Możemy spojrzeć na dwa poprzednie modele jak na dwie hurtownie danych, jedną dla działu sprzedaży, a drugą dla działu zaopatrzenia. Każda z nich składa się tylko z jednej tabeli faktów i kilku tabel wymiarów. Gdybyśmy chcieli, moglibyśmy połączyć te dwie bazy danych w jeden model. Ten typ schematu, zawierający kilka tabel faktów i udostępniający niektóre tabele wymiarów, nazywa się schematem galaktyki . Udostępnianie tabel wymiarów może zmniejszyć rozmiar bazy danych, zwłaszcza gdy współużytkowane wymiary mają wiele możliwych wartości. Idealnie, w obu hurtowniach danych wymiary są definiowane w ten sam sposób. Jeśli tak nie jest, będziemy musieli dostosować wymiary, aby pasowały do obu potrzeb.

Schemat galaktyki, zbudowany z naszych dwóch przykładowych baz danych, jest pokazany poniżej:

Schemat gwiazdy to jedno z podejść do organizacji hurtowni danych. Jest to bardzo proste i najczęściej używane w data martach. Jeśli nie musimy martwić się o miejsce na dysku i dbamy o integralność danych, schemat gwiaździsty jest opłacalnym pierwszym i najlepszym wyborem. Jeśli nie, powinniśmy pomyśleć o innym podejściu. Jednym z nich jest schemat płatka śniegu, który omówimy w nadchodzącym artykule.