Schemat płatka śniegu - Snowflake schema

Schemat płatka śniegu jest odmianą schematu gwiaździstego z normalizacją tabel wymiarów.

W informatyce , wykorzystując schemat płatka śniegu jest logiczny układ stołów w wielowymiarowej bazie danych , tak że relacja podmiot schemat przypomina płatek śniegu kształt. Schemat płatka śniegu jest reprezentowany przez scentralizowane tabele faktów, które są połączone z wieloma wymiarami . „Płatkowanie śniegu” to metoda normalizacji tabel wymiarów w schemacie gwiaździstym . Gdy jest całkowicie znormalizowany wzdłuż wszystkich tabel wymiarów, wynikowa struktura przypomina płatek śniegu z tabelą faktów pośrodku. Zasadą płatka śniegu jest normalizacja tabel wymiarów poprzez usunięcie atrybutów o niskiej kardynalności i utworzenie oddzielnych tabel.

Schemat płatka śniegu jest podobny do schematu gwiazdy. Jednak w schemacie typu płatek śniegu wymiary są normalizowane do wielu powiązanych tabel, podczas gdy wymiary schematu gwiaździstego są denormalizowane, a każdy wymiar jest reprezentowany przez pojedynczą tabelę. Złożony kształt płatka śniegu pojawia się, gdy wymiary schematu płatka śniegu są rozbudowane i mają wiele poziomów relacji, a tabele podrzędne mają wiele tabel nadrzędnych („rozwidlenia dróg”).

Typowe zastosowania

Schematy gwiazdy i płatka śniegu są najczęściej spotykane w magazynach danych wymiarowych i bazach danych, w których szybkość pobierania danych jest ważniejsza niż wydajność manipulacji danymi. W związku z tym tabele w tych schematach nie są zbytnio znormalizowane i często są projektowane na poziomie normalizacji krótszym niż trzecia forma normalna .

Normalizacja i przechowywanie danych

Normalizacja dzieli dane, aby uniknąć nadmiarowości (duplikacji), przenosząc często powtarzające się grupy danych do nowych tabel. W związku z tym normalizacja zwykle zwiększa liczbę tabel, które muszą zostać połączone w celu wykonania danego zapytania, ale zmniejsza przestrzeń wymaganą do przechowywania danych i liczbę miejsc, w których należy je zaktualizować w przypadku zmiany danych.

Z punktu widzenia pamięci masowej tabele wymiarowe są zazwyczaj małe w porównaniu do tabel faktów. Często neguje to potencjalne korzyści związane z przestrzenią dyskową schematu gwiaździstego w porównaniu ze schematem płatka śniegu. Przykład: Jeden milion transakcji sprzedaży w 300 sklepach w 220 krajach dałby 1 000 300 rekordów w schemacie gwiaździstym (1 000 000 rekordów w tabeli faktów i 300 rekordów w tabeli wymiarów, gdzie każdy kraj byłby wyraźnie wymieniony dla każdego sklepu w tym kraju). Bardziej znormalizowany schemat płatka śniegu z kluczami krajów odnoszącymi się do tabeli krajów składałby się z tej samej tabeli faktów z 1 000 000 rekordów, tabeli zawierającej 300 rekordów z odwołaniami do tabeli krajów zawierającej 220 rekordów. W tym przypadku schemat gwiaździsty, chociaż jeszcze bardziej zdenormalizowany, zmniejszyłby liczbę rekordów tylko o (nieistotny) współczynnik ~0,9998 (=[1 000 000+300] podzielone przez [1 000 000+300+220])

Niektórzy deweloperzy baz danych narażają się na kompromis, tworząc bazowy schemat płatka śniegu z widokami zbudowanymi na jego bazie, które wykonują wiele sprzężeń niezbędnych do symulowania schematu gwiaździstego. Zapewnia to korzyści związane z przechowywaniem uzyskane dzięki normalizacji wymiarów z łatwością wykonywania zapytań zapewnianych przez schemat gwiazdy. Kompromis polega na tym, że wymaganie od serwera automatycznego wykonywania podstawowych sprzężeń może spowodować spadek wydajności podczas wykonywania zapytań, a także dodatkowe sprzężenia do tabel, które mogą nie być konieczne do wykonania niektórych zapytań.

Korzyści

Schemat płatka śniegu należy do tej samej rodziny, co model logiczny schematu gwiazdy . W rzeczywistości schemat gwiaździsty jest uważany za szczególny przypadek schematu płatka śniegu. Schemat płatka śniegu ma pewne zalety w porównaniu ze schematem gwiaździstym w pewnych sytuacjach, w tym:

  • Niektóre narzędzia do modelowania wielowymiarowych baz danych OLAP są zoptymalizowane pod kątem schematów typu płatek śniegu.
  • Normalizacja atrybutów skutkuje oszczędnością pamięci, a kompromisem jest dodatkowa złożoność łączeń zapytań źródłowych.

Niedogodności

Główną wadą schematu typu płatek śniegu jest to, że dodatkowe poziomy normalizacji atrybutów zwiększają złożoność łączeń zapytań źródłowych w porównaniu ze schematem gwiaździstym .

Schematy płatków śniegu, w przeciwieństwie do płaskich wymiarów pojedynczych stołów, zostały mocno skrytykowane. Zakłada się, że ich celem jest wydajne i kompaktowe przechowywanie znormalizowanych danych, ale odbywa się to kosztem niskiej wydajności podczas przeglądania złączeń wymaganych w tym wymiarze. Ta wada mogła się zmniejszyć w ciągu lat, odkąd została po raz pierwszy rozpoznana, dzięki lepszej wydajności zapytań w narzędziach do przeglądania.

W porównaniu z wysoce znormalizowanym schematem transakcyjnym, denormalizacja schematu płatka śniegu usuwa gwarancje integralności danych zapewniane przez znormalizowane schematy. Ładowanie danych do schematu płatka śniegu musi być ściśle kontrolowane i zarządzane, aby uniknąć aktualizacji i wstawiania anomalii.

Przykłady

Schemat płatka śniegu używany przez przykładowe zapytanie.

Przykładowy schemat pokazany po prawej stronie to śnieżna wersja przykładowego schematu gwiaździstego podanego w artykule o schemacie gwiaździstym .

Poniższe przykładowe zapytanie jest odpowiednikiem przykładowego kodu schematu gwiaździstego, który zwraca łączną liczbę telewizorów sprzedanych według marki i kraju w 1997 r. spełnić nawet proste zapytanie. Zaletą korzystania ze schematu płatka śniegu w tym przykładzie jest to, że wymagania dotyczące przechowywania są mniejsze, ponieważ schemat płatka śniegu eliminuje wiele zduplikowanych wartości z samych wymiarów.

SELECT
	B.Brand,
	G.Country,
	SUM(F.Units_Sold)
FROM Fact_Sales F
INNER JOIN Dim_Date D             ON F.Date_Id = D.Id
INNER JOIN Dim_Store S            ON F.Store_Id = S.Id
INNER JOIN Dim_Geography G        ON S.Geography_Id = G.Id
INNER JOIN Dim_Product P          ON F.Product_Id = P.Id
INNER JOIN Dim_Brand B            ON P.Brand_Id = B.Id
INNER JOIN Dim_Product_Category C ON P.Product_Category_Id = C.Id
WHERE
	D.Year = 1997 AND
	C.Product_Category = 'tv'
GROUP BY
	B.Brand,
	G.Country

Zobacz też

Bibliografia

Bibliografia

  • Anahory S.; D. Murraya. Magazynowanie danych w świecie rzeczywistym: praktyczny przewodnik po budowaniu systemów wspomagania decyzji . Addison Wesley Zawodowiec.
  • Kimball, Ralph (1996). Zestaw narzędzi hurtowni danych . Johna Wileya.

Zewnętrzne linki