Modelowanie wymiarowe w usłudze Microsoft Fabric Warehouse: tabele faktów
Dotyczy:✅ punkt końcowy analizy SQL i magazyn w usłudze Microsoft Fabric
Uwaga
Ten artykuł stanowi część serii artykułów dotyczących modelowania wymiarowego. Ta seria koncentruje się na wskazówkach i najlepszych rozwiązaniach projektowych związanych z modelowaniem wymiarowym w usłudze Microsoft Fabric Warehouse.
Ten artykuł zawiera wskazówki i najlepsze rozwiązania dotyczące projektowania tabel faktów w modelu wymiarowym. Zawiera praktyczne wskazówki dotyczące magazynu w usłudze Microsoft Fabric, które jest środowiskiem obsługującym wiele funkcji języka T-SQL, takich jak tworzenie tabel i zarządzanie danymi w tabelach. W związku z tym masz pełną kontrolę nad tworzeniem tabel modelu wymiarowego i ładowaniem ich przy użyciu danych.
Uwaga
W tym artykule termin magazyn danych odnosi się do magazynu danych przedsiębiorstwa, który zapewnia kompleksową integrację krytycznych danych w całej organizacji. Z kolei autonomiczny magazyn terminów odnosi się do magazynu sieci szkieletowej, który jest oprogramowaniem jako usługą (SaaS) ofertą relacyjnej bazy danych, której można użyć do zaimplementowania magazynu danych. Aby uzyskać jasność, w tym artykule ten ostatni jest wymieniony jako Magazyn sieci szkieletowej.
Napiwek
Jeśli nie masz doświadczenia z modelowaniem wymiarowym, rozważ tę serię artykułów, które są pierwszym krokiem. Nie jest ona przeznaczona do pełnej dyskusji na temat projektowania modelowania wymiarowego. Aby uzyskać więcej informacji, zapoznaj się bezpośrednio z powszechnie opublikowaną zawartością, na przykład The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (trzeci wydanie, 2013) autorstwa Ralph Kimball i innych.
W modelu wymiarowym tabela faktów przechowuje miary skojarzone z obserwacjami lub zdarzeniami. Może przechowywać zamówienia sprzedaży, salda zapasów, kursy wymiany, odczyty temperatury i nie tylko.
Tabele faktów zawierają miary, które zazwyczaj są kolumnami liczbowymi, takimi jak ilość zamówienia sprzedaży. Zapytania analityczne podsumowują miary (przy użyciu sum, liczby, średniej i innych funkcji) w kontekście filtrów wymiarów i grupowania.
Tabele faktów zawierają również klucze wymiarów, które określają wymiarowość faktów. Wartości klucza wymiaru określają stopień szczegółowości faktów, który jest poziomem atomowym, według którego zdefiniowano fakty. Na przykład klucz wymiaru daty zamówienia w tabeli faktów sprzedaży ustawia stopień szczegółowości faktów na poziomie daty, podczas gdy klucz wymiaru daty docelowej w tabeli faktów docelowych sprzedaży może ustawić stopień szczegółowości na poziomie kwartału.
Uwaga
Chociaż istnieje możliwość przechowywania faktów na wyższym poziomie szczegółowości, nie jest łatwo podzielić wartości miar na niższe poziomy szczegółowości (jeśli jest to wymagane). Sama ilość danych wraz z wymaganiami analitycznymi może stanowić ważny powód przechowywania faktów o wyższym poziomie szczegółowości, ale kosztem szczegółowej analizy.
Aby łatwo zidentyfikować tabele faktów, zazwyczaj prefiksuj ich nazwy za pomocą polecenia f_
lub Fact_
.
Struktura tabeli faktów
Aby opisać strukturę tabeli faktów, rozważmy następujący przykład tabeli faktów sprzedaży o nazwie f_Sales
. W tym przykładzie stosuje się dobre rozwiązania projektowe. Każda z grup kolumn jest opisana w poniższych sekcjach.
CREATE TABLE f_Sales
(
--Dimension keys
OrderDate_Date_FK INT NOT NULL,
ShipDate_Date_FK INT NOT NULL,
Product_FK INT NOT NULL,
Salesperson_FK INT NOT NULL,
<…>
--Attributes
SalesOrderNo INT NOT NULL,
SalesOrderLineNo SMALLINT NOT NULL,
--Measures
Quantity INT NOT NULL,
<…>
--Audit attributes
AuditMissing BIT NOT NULL,
AuditCreatedDate DATE NOT NULL,
AuditCreatedBy VARCHAR(15) NOT NULL,
AuditLastModifiedDate DATE NOT NULL,
AuditLastModifiedBy VARCHAR(15) NOT NULL
);
Klucz podstawowy
Tak jak w przykładzie, przykładowa tabela faktów nie ma klucza podstawowego. Dzieje się tak, ponieważ zwykle nie służy ono do użytecznego celu i niepotrzebnie zwiększałoby rozmiar magazynu tabel. Klucz podstawowy jest często dorozumiany przez zestaw kluczy wymiarów i atrybutów.
Klucze wymiarów
Przykładowa tabela faktów ma różne klucze wymiarów, które określają wymiarowość tabeli faktów. Klucze wymiarów są odwołaniami do kluczy zastępczych (lub atrybutów wyższego poziomu) w powiązanych wymiarach.
Uwaga
Jest to nietypowa tabela faktów, która nie zawiera co najmniej jednego klucza wymiaru daty.
Tabela faktów może odwoływać się do wymiaru wiele razy. W tym przypadku jest to znany jako wymiar odgrywania ról. W tym przykładzie tabela faktów zawiera klucze wymiarów OrderDate_Date_FK
i .ShipDate_Date_FK
Każdy klucz wymiaru reprezentuje odrębną rolę, ale istnieje tylko jeden wymiar daty fizycznej.
Dobrym rozwiązaniem jest ustawienie każdego klucza wymiaru jako NOT NULL
. Podczas ładowania tabeli faktów można użyć specjalnych składowych wymiarów do reprezentowania brakujących, nieznanych, N/A lub stanów błędów (w razie potrzeby).
Atrybuty
Przykładowa tabela faktów ma dwa atrybuty. Atrybuty zawierają dodatkowe informacje i określają stopień szczegółowości danych faktów, ale nie są to ani klucze wymiarów, ani atrybuty wymiaru, ani miary. W tym przykładzie kolumny atrybutów przechowują informacje o zamówieniach sprzedaży. Inne przykłady mogą obejmować numery śledzenia lub numery biletów. W celach analizy atrybut może utworzyć wymiar degeneracji.
Miary
Przykładowa tabela faktów zawiera również miary, takie jak kolumna Quantity
. Kolumny miar są zwykle liczbowe i często dodawane (co oznacza, że można je sumować i sumować przy użyciu innych agregacji). Aby uzyskać więcej informacji, zobacz Typy miar w dalszej części tego artykułu.
Atrybuty inspekcji
Przykładowa tabela faktów zawiera również różne atrybuty inspekcji. Atrybuty inspekcji są opcjonalne. Umożliwiają one śledzenie, kiedy i jak rekordy faktów zostały utworzone lub zmodyfikowane, i mogą zawierać informacje diagnostyczne lub rozwiązywania problemów zgłaszane podczas procesów wyodrębniania, przekształcania i ładowania (ETL). Na przykład chcesz śledzić, kto (lub jaki proces) zaktualizował wiersz i kiedy. Atrybuty inspekcji mogą również pomóc zdiagnozować trudny problem, na przykład gdy proces ETL zostanie nieoczekiwanie zatrzymany.
Rozmiar tabeli faktów
Tabele faktów różnią się w zależności od rozmiaru. Ich rozmiar odpowiada wymiarowości, szczegółowości, liczbie miar i ilości historii. W porównaniu z tabelami wymiarów tabele faktów są bardziej wąskie (mniej kolumn), ale duże lub nawet ogromne pod względem wierszy (ponad miliardy).
Pojęcia dotyczące projektowania faktów
W tej sekcji opisano różne pojęcia dotyczące projektowania faktów.
Typy tabel faktów
Istnieją trzy typy tabel faktów:
- Tabele faktów transakcji
- Okresowe tabele faktów migawek
- Zbieranie tabel faktów migawek
Tabele faktów transakcji
Tabela faktów transakcji przechowuje zdarzenia biznesowe lub transakcje. Każdy wiersz przechowuje fakty pod względem kluczy wymiarów i miar oraz opcjonalnie innych atrybutów. Wszystkie dane są w pełni znane podczas wstawiania i nigdy nie zmieniają się (z wyjątkiem błędów).
Zazwyczaj tabele faktów transakcji przechowują fakty na najniższym możliwym poziomie szczegółowości i zawierają miary, które są dodawane we wszystkich wymiarach. Tabela faktów sprzedaży, która przechowuje każdy wiersz zamówienia sprzedaży, jest dobrym przykładem tabeli faktów transakcji.
Okresowe tabele faktów migawek
Okresowa tabela faktów migawki przechowuje miary w wstępnie zdefiniowanym czasie lub określonych interwałach. Zawiera podsumowanie kluczowych metryk lub wskaźników wydajności w czasie, dlatego przydatne jest analizowanie trendów i monitorowanie zmian w czasie. Miary są zawsze pół addytywne (opisane w dalszej części).
Tabela faktów spisu jest dobrym przykładem okresowej tabeli migawek. Jest ładowany codziennie z końcowym bilansem zapasów każdego produktu.
Tabele migawek okresowych mogą być używane zamiast tabeli faktów transakcji podczas rejestrowania dużych ilości transakcji jest kosztowne i nie obsługuje żadnych przydatnych wymagań analitycznych. Na przykład w ciągu dnia mogą istnieć miliony ruchów akcji (które mogą być przechowywane w tabeli faktów transakcji), ale analiza dotyczy tylko trendów poziomów zapasów na koniec dnia.
Zbieranie tabel faktów migawek
Skumulowana tabela faktów migawek przechowuje miary, które gromadzą się w dobrze zdefiniowanym okresie lub przepływie pracy. Często rejestruje stan procesu biznesowego na różnych etapach lub kamieniach milowych, co może potrwać kilka dni, tygodni, a nawet miesięcy.
Wiersz faktów jest ładowany wkrótce po pierwszym zdarzeniu w procesie, a następnie wiersz jest aktualizowany w przewidywalnej kolejności za każdym razem, gdy wystąpi zdarzenie punktu kontrolnego. Aktualizacje będą kontynuowane do momentu zakończenia procesu.
Zebranie tabeli faktów migawki ma wiele kluczy wymiarów daty, z których każdy reprezentuje zdarzenie punktu kontrolnego. Niektóre klucze wymiarów mogą rejestrować stan N/A, dopóki proces nie zostanie osiągnięty w określonym kamieniu milowym. Miary zwykle rejestrują czasy trwania. Czasy trwania między kamieniami milowymi mogą zapewnić cenny wgląd w biznesowy przepływ pracy lub proces zestawów.
Typy miar
Miary są zwykle liczbowe i często dodawane. Jednak niektóre miary nie zawsze mogą być dodawane. Te miary są klasyfikowane jako częściowo addytywne lub nie addytywne.
Miary addytywne
Miara dodawania może być sumowana w dowolnym wymiarze. Na przykład wielkość zamówienia i przychód ze sprzedaży to miary addytywne (dostarczanie przychodów jest rejestrowane dla jednej waluty).
Miary częściowo addytywne
Miara pół addytywne może być sumowana tylko w niektórych wymiarach.
Oto kilka przykładów miar pół addytywnych.
- Żadna miara w okresowej tabeli faktów migawki nie może być sumowana w innych okresach. Na przykład nie należy sumować wieku elementu zapasów próbkowanego w nocy, ale możesz zsumować wiek wszystkich przedmiotów zapasów na półce każdej nocy.
- Miara salda zapasów w tabeli faktów zapasów nie może być sumowana w innych produktach.
- Przychód ze sprzedaży w tabeli faktów sprzedaży, który ma klucz wymiaru waluty, nie może być sumowany w różnych walutach.
Miary nie addytywne
Nie można sumować miary nie addytywnej w żadnym wymiarze. Jednym z przykładów jest odczyt temperatury, który z natury nie ma sensu dodawać do innych odczytów.
Inne przykłady obejmują stawki, takie jak ceny jednostkowe i współczynniki. Jednak uważa się, że lepszym rozwiązaniem jest przechowywanie wartości używanych do obliczenia współczynnika, co umożliwia obliczenie proporcji w razie potrzeby. Na przykład procent rabatu faktu sprzedaży może być przechowywany jako miara kwoty rabatu (która ma zostać podzielona przez miarę przychodu ze sprzedaży). Lub wiek elementu zapasów na półce nie powinien być sumowany w czasie, ale może być obserwowany trend w średnim wieku elementów zapasów.
Chociaż niektóre miary nie mogą być sumowane, nadal są to prawidłowe miary. Można je agregować przy użyciu funkcji count, distinct count, minimum, maximum, average i innych. Ponadto miary nie addytywne mogą stać się addytywne, gdy są używane w obliczeniach. Na przykład cena jednostkowa pomnożona przez ilość zamówienia generuje przychody ze sprzedaży, co jest dodatkiem.
Tabele faktów bez faktów
Jeśli tabela faktów nie zawiera żadnych kolumn miar, jest nazywana tabelą faktów bez faktów. Tabela faktów bez faktów zwykle rejestruje zdarzenia lub wystąpienia, takie jak uczniowie uczęszczający na zajęcia. Z perspektywy analizy pomiar można osiągnąć przez zliczanie wierszy faktów.
Agregowanie tabel faktów
Tabela faktów agregacji reprezentuje zestawienie tabeli faktów podstawowych do niższej wymiarowości i/lub wyższego stopnia szczegółowości. Jego celem jest przyspieszenie wydajności zapytań dla często zapytanych wymiarów.
Uwaga
Semantyczny model usługi Power BI może generować agregacje zdefiniowane przez użytkownika w celu osiągnięcia tego samego wyniku lub użyć tabeli faktów agregujących magazynu danych przy użyciu trybu przechowywania DirectQuery.
Powiązana zawartość
W następnym artykule z tej serii dowiesz się więcej o wskazówkach i projektowaniu najlepszych rozwiązań dotyczących ładowania tabel modelu wymiarowego.