Database
 sql >> Baza danych >  >> RDS >> Database

Schemat gwiazdy kontra schemat płatka śniegu

W poprzednich dwóch artykułach rozważyliśmy dwa najpopularniejsze modele hurtowni danych:schemat gwiaździsty i schemat płatka śniegu. Dzisiaj przyjrzymy się różnicom między tymi dwoma schematami i wyjaśnimy, kiedy lepiej użyć jednego, czy drugiego.

Schemat gwiaździsty i schemat płatka śniegu to sposoby organizowania hurtowni danych lub całych hurtowni danych przy użyciu relacyjnych baz danych. Obaj używają tabeli wymiarów aby opisać dane zebrane w tabeli faktów .

Każdy coś sprzedaje, czy to wiedzę, produkt, czy usługę. Potrzebne jest również przechowywanie tych informacji w systemie operacyjnym lub w systemie raportowania. Możemy więc spodziewać się, że znajdziemy jakiś model sprzedaży w hurtowni danych prawie każdej firmy.

Przyjrzyjmy się jeszcze raz modelowi sprzedaży zarówno w schemacie gwiazdy, jak i płatka śniegu.

Schemat gwiazdy



Najbardziej oczywistą cechą schematu gwiaździstego jest to, że tabele wymiarów nie są znormalizowane. W powyższym modelu różowy fact_sales tabela przechowuje zagregowane dane utworzone z naszych operacyjnych baz danych. Jasnoniebieskie tabele to tabele wymiarów. Zdecydowaliśmy się na użycie tych pięciu wymiarów, ponieważ musimy tworzyć raporty, używając ich jako parametrów. Granulacja w każdym wymiarze zależy również od naszych potrzeb w zakresie raportowania.

Na podstawie tego modelu możemy łatwo zobaczyć, dlaczego ten schemat nazywa się „schematem gwiaździstym”:wygląda jak gwiazda, a tabele wymiarów otaczają centralną tabelę faktów.

Schemat płatka śniegu



Ten schemat płatka śniegu przechowuje dokładnie te same dane, co schemat gwiaździsty. Tabela faktów ma takie same wymiary, jak w przykładzie schematu gwiazdy. Najważniejszą różnicą jest to, że tabele wymiarów w schemacie płatka śniegu są znormalizowane. Co ciekawe, proces normalizacji tabel wymiarów nazywa się płatkiem śniegu.

Po raz kolejny wizualnie schemat płatka śniegu przypomina nam swojego imiennika, z kilkoma warstwami tabel wymiarów tworzących nieregularny kształt przypominający płatek śniegu.

Pierwsza różnica:normalizacja

Jak wspomniano, normalizacja jest kluczową różnicą między schematami gwiazd i płatków śniegu. W związku z tym należy wiedzieć kilka rzeczy:

  • Schematy płatka śniegu będą zajmowały mniej miejsca do przechowywania tabel wymiarów. Dzieje się tak, ponieważ z reguły każda znormalizowana baza danych tworzy znacznie mniej zbędnych rekordów.
  • Zdenormalizowane modele danych zwiększają prawdopodobieństwo wystąpienia problemów z integralnością danych. Te problemy również skomplikują przyszłe modyfikacje i konserwację.
  • Doświadczonym projektantom danych schemat płatka śniegu wydaje się bardziej logicznie zorganizowany niż schemat gwiaździsty. (To moja osobista opinia, a nie twardy fakt. :) )

Przejdźmy do drugiej głównej różnicy między tymi dwoma schematami.

Druga różnica:złożoność zapytań

W naszych pierwszych dwóch artykułach przedstawiliśmy zapytanie, którego można użyć w modelu sprzedaży, aby uzyskać liczbę wszystkich produktów typu telefon sprzedanych w berlińskich sklepach w 2016 r.

Zapytanie o schemat gwiazdy wygląda tak:

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

Aby uzyskać ten sam wynik ze schematu płatka śniegu, musimy użyć tego zapytania:

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_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Oczywiście zapytanie schematu płatka śniegu jest bardziej złożone. Ponieważ tabele wymiarów są znormalizowane, musimy sięgnąć głębiej, aby uzyskać nazwę typu produktu i miasta. Musimy dodać kolejne JOIN dla każdego nowego poziomu w tym samym wymiarze.

W schemacie gwiaździstym łączymy tylko tabelę faktów z tymi tabelami wymiarów, których potrzebujemy. Co najwyżej będziemy mieć tylko jeden JOIN na tabelę wymiarów. A jeśli nie używamy tabeli wymiarów, nawet nie musimy się nią przejmować. W zapytaniu dotyczącym schematu płatka śniegu nie wiemy, jak głęboko będziemy musieli przejść, aby uzyskać odpowiedni poziom wymiaru, co komplikuje proces pisania zapytań.

Łączenie dwóch tabel zajmuje trochę czasu, ponieważ DMBS zajmuje więcej czasu na przetworzenie żądania. dim_store i dim_city tabele są umieszczone blisko siebie w naszym modelu, ale nie mogą znajdować się nigdzie blisko siebie na dysku. Istnieje większe prawdopodobieństwo, że dane będą fizycznie bliżej na dysku, jeśli znajdują się w tej samej tabeli.

Zasadniczo zapytanie uruchomione w bazie danych schematu płatka śniegu będzie wykonywane wolniej. Ale w większości przypadków nie będzie to stanowić problemu:nie ma większego znaczenia, czy otrzymamy wynik w ciągu jednej milisekundy czy jednej sekundy.

Przyspieszenie działania

Aby przyspieszyć raportowanie, możemy:

  • Agregacja danych do poziomu, którego potrzebujemy w raportach. Spowoduje to znaczne skompresowanie danych. Będziemy musieli stworzyć procedury, które przekształcą nasze aktualne dane, aby pasowały do ​​struktury schematu raportowania (proces ETL).
  • Zbuduj centralny obszar przechowywania dla wszystkich zagregowane dane firmy, a nie tylko dane sprzedaży.
  • Podawaj użytkownikom tylko te dane, których potrzebują do analiz i raportów.

Schemat płatek śniegu a gwiazda:których należy użyć?

Teraz, gdy przyjrzeliśmy się teorii i szybkości zapytań, przejdźmy od razu do sedna sprawy:skąd wiesz, którego schematu użyć w danym projekcie?

Rozważ użycie schematu płatka śniegu :

  • W hurtowniach danych. Ponieważ magazyn jest centrum danych dla firmy, możemy w ten sposób zaoszczędzić dużo miejsca.
  • Gdy tabele wymiarów wymagają znacznej ilości miejsca do przechowywania. W większości przypadków tabele faktów zajmą większość miejsca. Prawdopodobnie będą też rosły znacznie szybciej niż tabele wymiarów. Ale są pewne sytuacje, w których to nie ma zastosowania. Na przykład tabele wymiarów mogą zawierać wiele zbędnych, ale potrzebnych atrybutów. W naszym przykładzie użyliśmy miasto atrybut opisujący miasto, w którym znajduje się sklep. Co by było, gdybyśmy chcieli dużo bardziej szczegółowego opisu miasta, w tym liczby ludności, kodu pocztowego, danych demograficznych itp.? Opisywanie innych wymiarów podrzędnych – na przykład sklep , region , stan i kraj – przy większej liczbie atrybutów zmieniłbym dim_store tabelę wymiarów w jedną dużą tabelę z dużą nadmiarowością.
  • Jeśli używasz narzędzi, które wymagają schematu płatka śniegu w tle. (Na szczęście większość nowoczesnych narzędzi obsługuje zarówno schematy, jak i schemat galaktyki).

Rozważ użycie schematu gwiazdy :

  • W hurtowniach danych. Bazy danych to podzbiory danych pobrane z centralnej hurtowni danych. Są one zwykle tworzone dla różnych działów i nie zawierają nawet wszystkich danych historycznych. W tym ustawieniu oszczędzanie miejsca nie jest priorytetem.

    Z drugiej strony schemat gwiazdy upraszcza analizę. Nie chodzi tylko o wydajność zapytań, ale także o uproszczenie przyszłych działań dla użytkowników biznesowych. Mogą rozumieć bazy danych i wiedzieć, jak pisać zapytania, ale po co komplikować rzeczy i dołączać więcej złączeń, jeśli możemy tego uniknąć? Użytkownik biznesowy może mieć szablonowe zapytanie, które łączy tabelę faktów ze wszystkimi tabelami wymiarów. Następnie wystarczy dodać odpowiednie selekcje i grupy. (To podejście jest zbliżone do tabel przestawnych programu Excel).

  • Jeśli używasz narzędzi, które wymagają schematu gwiazdy w tle. (Ponownie, to zwykle nie stanowi problemu).

Zarówno schemat gwiaździsty, jak i schemat płatka śniegu są modelami relacyjnymi używanymi do organizowania hurtowni danych i/lub hurtowni danych. Bez względu na to, jak bardzo są podobni, demonstrują dwa różne podejścia i mają swoje zalety i wady. Osobiście skorzystałbym ze schematu płatka śniegu podczas wdrażania hurtowni danych (aby zaoszczędzić miejsce na dysku) oraz ze schematem gwiaździstym dla hurtowni danych (aby ułatwić życie użytkownikom biznesowym).


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. AKTUALIZACJA SQL dla początkujących

  2. Halloweenowy problem – część 3

  3. Używanie Jenkinsa z Kubernetes AWS, część 3

  4. Dlaczego same statystyki oczekiwania nie wystarczą

  5. Operatory SQL