Wymiar (hurtownia danych) - Dimension (data warehouse)

Ten artykuł dotyczy wymiaru w hurtowni danych . Inne zastosowania, patrz wymiar (ujednoznacznienie) .
Tabela wymiarów w kostce OLAP ze schematem gwiazdy

Wymiar jest strukturą, która klasyfikuje fakty i środki w celu umożliwienia użytkownikom odpowiedzi na pytania biznesowe. Powszechnie używanymi wymiarami są ludzie, produkty, miejsce i czas. (Uwaga: ludzie i czas czasami nie są modelowane jako wymiary.)

W hurtowni danych wymiary dostarczają uporządkowanych informacji o etykietach do nieuporządkowanych w inny sposób miar liczbowych. Wymiar to zbiór danych składający się z pojedynczych, nienakładających się elementów danych . Podstawowe funkcje wymiarów są trojakie: zapewnienie filtrowania, grupowania i etykietowania.

Funkcje te są często określane jako „ plaster i kostka ”. Typowy przykład hurtowni danych obejmuje sprzedaż jako miarę, a wymiary klienta i produktu. W każdej sprzedaży klient kupuje produkt. Dane można pokroić, usuwając wszystkich klientów z wyjątkiem badanej grupy, a następnie pokroić w kostkę, grupując według produktów.

Element danych wymiarowych jest podobny do zmiennej kategorialnej w statystyce.

Zazwyczaj wymiary w hurtowni danych są zorganizowane wewnętrznie w co najmniej jedną hierarchię. „Data” to wspólny wymiar z kilkoma możliwymi hierarchiami:

  • „Dni (są pogrupowane w) Miesiące (które są pogrupowane w) Lata”,
  • „Dni (są pogrupowane w) Tygodnie (które są pogrupowane w) Lata”
  • „Dni (pogrupowane na) Miesiące (pogrupowane na) Kwartały (pogrupowane na) Lata”
  • itp.

Rodzaje

Zgodny wymiar

Wymiar zgodny to zestaw atrybutów danych, do których fizycznie odniesiono się w wielu tabelach bazy danych przy użyciu tej samej wartości klucza w odniesieniu do tej samej struktury, atrybutów, wartości domen, definicji i pojęć. Zgodny wymiar przecina wiele faktów.

Wymiary są zgodne, gdy są albo dokładnie takie same (w tym klucze), albo jeden jest właściwym podzbiorem drugiego. Co najważniejsze, nagłówki wierszy utworzone w dwóch różnych zestawach odpowiedzi z tego samego określonego wymiaru (wymiarów) muszą być idealnie dopasowane”.

Zgodne wymiary są albo identycznymi, albo ścisłymi matematycznymi podzbiorami najbardziej szczegółowego, szczegółowego wymiaru. Tabele wymiarów nie są zgodne, jeśli atrybuty są oznaczone inaczej lub zawierają różne wartości. Odpowiednie wymiary występują w kilku różnych smakach. Na najbardziej podstawowym poziomie wymiary zgodne oznaczają dokładnie to samo z każdą możliwą tabelą faktów, z którą są połączone. Tabela wymiarów daty połączona z faktami sprzedaży jest identyczna z wymiarem daty połączonym z faktami magazynowymi.

Wymiar śmieci

Wymiar śmieciowy to wygodne grupowanie flag i wskaźników o typowo niskiej kardynalności. Tworząc wymiar abstrakcyjny, te flagi i wskaźniki są usuwane z tabeli faktów, jednocześnie umieszczając je w użytecznych ramach wymiarowych. Wymiar niepotrzebny to tabela wymiarów składająca się z atrybutów, które nie należą do tabeli faktów ani do żadnej z istniejących tabel wymiarów. Charakter tych atrybutów to zazwyczaj tekst lub różne flagi, np. nieogólne komentarze lub po prostu proste wskaźniki tak/nie lub prawda/fałsz. Tego rodzaju atrybuty zwykle pozostają, gdy wszystkie oczywiste wymiary w procesie biznesowym zostały zidentyfikowane, a zatem projektant staje przed wyzwaniem, gdzie umieścić te atrybuty, które nie należą do innych wymiarów.

Jednym z rozwiązań jest utworzenie nowego wymiaru dla każdego z pozostałych atrybutów, ale ze względu na ich charakter może być konieczne utworzenie ogromnej liczby nowych wymiarów, co skutkuje powstaniem tabeli faktów z bardzo dużą liczbą kluczy obcych. Projektant może również zdecydować o pozostawieniu pozostałych atrybutów w tabeli faktów, ale może to spowodować niepotrzebne zwiększenie długości wiersza tabeli, jeśli na przykład atrybut jest długim ciągiem tekstowym.

Rozwiązaniem tego wyzwania jest zidentyfikowanie wszystkich atrybutów, a następnie umieszczenie ich w jednym lub kilku niepotrzebnych wymiarach. Jeden wymiar śmieci może zawierać kilka wskaźników prawda/fałsz lub tak/nie, które nie są ze sobą skorelowane, więc wygodnie byłoby przekonwertować wskaźniki na bardziej opisujący atrybut. Przykładem może być wskaźnik tego, czy paczka dotarła: zamiast wskazywać to jako „tak” lub „nie”, zostanie ona zamieniona na „przybyła” lub „oczekuje” w wymiarze śmieci. Projektant może zdecydować się na zbudowanie tabeli wymiarów, aby w końcu zawierała wszystkie wskaźniki występujące z każdym innym wskaźnikiem, aby wszystkie kombinacje zostały uwzględnione. Ustawia to stały rozmiar samej tabeli, który byłby 2 x wierszami, gdzie x jest liczbą wskaźników. To rozwiązanie jest odpowiednie w sytuacjach, w których projektant spodziewałby się napotkać wiele różnych kombinacji i gdy możliwe kombinacje są ograniczone do akceptowalnego poziomu. W sytuacji, gdy liczba wskaźników jest duża, tworząc w ten sposób bardzo dużą tabelę lub gdy projektant spodziewa się napotkać tylko kilka możliwych kombinacji, bardziej odpowiednie byłoby zbudowanie każdego wiersza w wymiarze śmieci, ponieważ napotykane są nowe kombinacje . Aby ograniczyć rozmiar tabel, wiele wymiarów śmieci może być odpowiednich w innych sytuacjach, w zależności od korelacji między różnymi wskaźnikami.

Niepotrzebne wymiary są również odpowiednie do umieszczania atrybutów, takich jak nieogólne komentarze z tabeli faktów. Takie atrybuty mogą składać się z danych z opcjonalnego pola komentarza, gdy klient składa zamówienie i w rezultacie prawdopodobnie w wielu przypadkach będą puste. Dlatego wymiar śmieci powinien zawierać jeden wiersz reprezentujący puste pola jako klucz zastępczy, który będzie używany w tabeli faktów dla każdego wiersza zwróconego z pustym polem komentarza.

Wymiar zdegenerowany

Wymiar zdegenerowany to klucz, taki jak numer transakcji, numer faktury, numer biletu lub numer konosamentu, który nie ma atrybutów i dlatego nie łączy się z rzeczywistą tabelą wymiarów. Zdegenerowane wymiary są bardzo powszechne, gdy ziarno tabeli faktów reprezentuje pojedynczy element transakcji lub element wiersza, ponieważ zdegenerowany wymiar reprezentuje unikalny identyfikator elementu nadrzędnego. Wymiary zdegenerowane często odgrywają integralną rolę w kluczu podstawowym tabeli faktów.

Wymiar fabularny

Wymiary są często odtwarzane dla wielu aplikacji w tej samej bazie danych. Na przykład wymiar „Data” może być użyty jako „Data sprzedaży”, a także „Data dostawy” lub „Data wynajmu”. Często określa się to mianem „wymiaru odgrywania ról”. Można to zaimplementować za pomocą widoku w tej samej tabeli wymiarów.

Wymiar wysięgnika

Zwykle tabele wymiarów nie odwołują się do innych wymiarów za pomocą kluczy obcych. W takim przypadku wymiar, do którego się odnosi, nazywany jest wymiarem podpory . Wymiary zewnętrzne należy traktować jako antywzorc hurtowni danych: uważa się, że lepszą praktyką jest użycie niektórych tabel faktów, które wiążą te dwa wymiary.

Zmniejszony wymiar

O wymiarach zgodnych mówi się, że są wymiarami skróconymi, gdy zawierają podzbiór wierszy i/lub kolumn oryginalnego wymiaru.

Wymiar daty kalendarza

Do reprezentowania dat z dokładnością do dnia można użyć specjalnego typu wymiaru. Daty w tabeli faktów będą się odwoływać jako klucze obce do wymiaru daty. Klucz podstawowy wymiaru daty może być kluczem zastępczym lub liczbą w formacie RRRRMMDD.

Wymiar daty może zawierać inne atrybuty, takie jak tydzień roku lub flagi reprezentujące dni robocze, święta itp. Może również zawierać specjalne wiersze reprezentujące: daty nieznane lub jeszcze nie zdefiniowane. Wymiar daty powinien zostać zainicjowany wszystkimi wymaganymi datami, na przykład następne 10 lat dat lub więcej, jeśli jest to wymagane, lub daty przeszłe, jeśli obsługiwane są zdarzenia z przeszłości.

Zamiast tego czas jest zwykle najlepiej reprezentowany jako znacznik czasu w tabeli faktów .

Stosowanie terminów reprezentacji ISO

Podczas odwoływania się do danych z rejestru metadanych, takiego jak ISO/IEC 11179 , jako wymiary zazwyczaj używane są terminy reprezentacji, takie jak „Wskaźnik” (wartość logiczna prawda/fałsz), „Kod” (zestaw niepokrywających się wartości wyliczanych). Na przykład przy użyciu National Information Exchange Model (NIEM) nazwa elementu danych będzie miała postać „PersonGenderCode”, a wartościami wyliczonymi mogą być „mężczyzna”, „kobieta” i „nieznane”.

Tabela wymiarów

W hurtowni danych , wykorzystując stół wymiar jest jednym z zestawu tabel towarzysz w tabeli faktów .

Tabela faktów zawiera fakty biznesowe (lub miary ) oraz klucze obce, które odwołują się do kluczy kandydujących (zwykle kluczy podstawowych ) w tabelach wymiarów.

W przeciwieństwie do tabel faktów, tabele wymiarów zawierają opisowe atrybuty (lub pola), które są zazwyczaj polami tekstowymi (lub dyskretnymi liczbami, które zachowują się jak tekst). Te atrybuty mają służyć dwóm krytycznym celom: ograniczaniu i/lub filtrowaniu zapytań oraz etykietowaniu zbioru wyników zapytania.

Atrybuty wymiaru powinny być:

  • Verbose (etykiety składające się z pełnych słów)
  • Opisowy
  • Kompletny (bez brakujących wartości)
  • Dyskretnie wyceniony (mający tylko jedną wartość na wiersz tabeli wymiarów)
  • Zapewniona jakość (bez błędów pisowni lub niemożliwych wartości)

Wiersze tabeli wymiarów są jednoznacznie identyfikowane przez pojedyncze pole klucza. Zaleca się, aby pole klucza było prostą liczbą całkowitą, ponieważ wartość klucza jest bez znaczenia i jest używana tylko do łączenia pól między tabelami faktów i wymiarów. Tabele wymiarów często używają kluczy podstawowych, które są również kluczami zastępczymi. Klucze zastępcze są często generowane automatycznie (np. „kolumna tożsamości” Sybase lub SQL Server, numer seryjny PostgreSQL lub Informix, Oracle SEQUENCE lub kolumna zdefiniowana za pomocą AUTO_INCREMENT w MySQL).

Korzystanie z kluczy wymiarów zastępczych ma kilka zalet, w tym:

  • Wydajność . Przetwarzanie złączeń jest znacznie wydajniejsze dzięki zastosowaniu pojedynczego pola ( klucza zastępczego )
  • Buforowanie z praktyk zarządzania kluczami operacyjnymi. Zapobiega to sytuacjom, w których usunięte wiersze danych mogą pojawić się ponownie, gdy ich naturalne klucze zostaną ponownie użyte lub ponownie przypisane po długim okresie uśpienia
  • Mapowanie w celu zintegrowania różnych źródeł
  • Obsługa nieznanych lub nieistotnych połączeń
  • Śledzenie zmian wartości atrybutów wymiaru

Chociaż użycie klucza zastępczego obciąża system ETL , przetwarzanie potokowe można ulepszyć, a narzędzia ETL mają wbudowane ulepszone przetwarzanie kluczy zastępczych.

Celem tabeli wymiarów jest tworzenie ustandaryzowanych, zgodnych wymiarów, które mogą być współużytkowane w środowisku hurtowni danych przedsiębiorstwa i umożliwiają łączenie z wieloma tabelami faktów reprezentującymi różne procesy biznesowe.

Zgodne wymiary są ważne dla korporacyjnego charakteru systemów DW/BI, ponieważ promują:

  • Spójność. Każda tabela faktów jest konsekwentnie filtrowana, dzięki czemu odpowiedzi na zapytania są konsekwentnie oznaczane etykietami.
  • Integracja. Zapytania mogą oddzielnie drążyć różne tabele faktów procesu, a następnie łączyć wyniki we wspólnych atrybutach wymiarów.
  • Skrócony czas opracowywania na rynek. Wspólne wymiary są dostępne bez ich ponownego tworzenia.

Z biegiem czasu atrybuty danego wiersza w tabeli wymiarów mogą ulec zmianie. Na przykład adres wysyłki firmy może ulec zmianie. Kimball określa to zjawisko jako powoli zmieniający się wymiar . Strategie radzenia sobie z tego rodzaju zmianami dzielą się na trzy kategorie:

  • Wpisz jeden: po prostu nadpisz stare wartości.
  • Wpisz dwa: Dodaj nowy wiersz zawierający nowe wartości i rozróżnij wiersze przy użyciu technik krotek .
  • Wpisz trzy: Dodaj nowy atrybut do istniejącego wiersza.

Wspólne wzorce

Data i godzina

Ponieważ wiele tabel faktów w hurtowni danych to szeregi czasowe obserwacji, często potrzebny jest jeden lub więcej wymiarów daty. Jednym z powodów posiadania wymiarów dat jest umieszczenie wiedzy kalendarza w hurtowni danych zamiast zakodowania jej na stałe w aplikacji. Chociaż prosty znacznik daty/czasu SQL jest przydatny do dostarczania dokładnych informacji o czasie zarejestrowania faktu, nie może on zawierać informacji o świętach, okresach obrachunkowych itp. Data/czas SQL może nadal być przydatny do przechowywania w tabeli faktów, ponieważ pozwala na precyzyjne obliczenia.

Posiadanie zarówno daty, jak i godziny w tym samym wymiarze, może z łatwością skutkować ogromnym wymiarem z milionami wierszy. Jeśli potrzebna jest duża ilość szczegółów, zwykle dobrym pomysłem jest podzielenie daty i godziny na dwa lub więcej oddzielnych wymiarów. Wymiar czasu z ziarnem sekund w ciągu dnia będzie miał tylko 86400 wierszy. W zależności od potrzeb można wybrać mniej lub bardziej szczegółowe ziarno dla wymiarów daty/czasu. Na przykład, wymiary daty mogą być dokładne z dokładnością do roku, kwartału, miesiąca lub dnia, a wymiary czasu mogą być z dokładnością do godzin, minut lub sekund.

Z reguły wymiar pory dnia powinien być tworzony tylko wtedy, gdy potrzebne są hierarchiczne grupowanie lub jeśli istnieją sensowne opisy tekstowe dla okresów czasu w ciągu dnia (np. „wieczorny szczyt” lub „pierwsza zmiana”).

Jeśli wiersze w tabeli faktów pochodzą z kilku stref czasowych, przydatne może być przechowywanie daty i godziny zarówno w czasie lokalnym, jak i standardowym. Można to zrobić, mając dwa wymiary dla każdego potrzebnego wymiaru daty/czasu – jeden dla czasu lokalnego, a drugi dla czasu standardowego. Przechowywanie daty/czasu zarówno w czasie lokalnym, jak i standardowym, pozwoli na analizę, kiedy fakty są tworzone w warunkach lokalnych, jak i globalnych. Wybrany czas standardowy może być globalnym czasem standardowym (np. UTC ), może to być czas lokalny siedziby firmy lub jakakolwiek inna strefa czasowa, której użycie ma sens.

Zobacz też

Bibliografia

  1. ^ „ Przewodnik hurtowni danych Oracle ”, Oracle Corporation, pobrane 9 czerwca 2014 r.
  2. ^ Definicja: Wymiar „Zarządzanie danymi wyszukiwania, TechTarget, pobrane 9 czerwca 2014 r.
  3. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: Kompletny przewodnik po modelowaniu wymiarowym, wydanie drugie, Wiley Computer Publishing, 2002. ISBN  0471-20024-7 , strony 82-87, 394
  4. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: Kompletny przewodnik po modelowaniu wymiarowym, wydanie drugie, Wiley Computer Publishing, 2002. ISBN  0471-20024-7 , strony 202, 405
  5. ^ Kimball, Ralph i in. (2008): Zestaw narzędzi do cyklu życia hurtowni danych, wydanie drugie, Wiley Publishing Inc., Indianapolis, IN. Strony 263-265
  6. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: Kompletny przewodnik po modelowaniu wymiarowym, wydanie drugie, Wiley Computer Publishing, 2002. ISBN  0471-20024-7 , strony 50, 398
  7. ^ Ralph Kimball; Margy Ross (2013). Wydanie trzecie zestawu narzędzi Data Warehouse Toolkit . Wileya. P. 50. Numer ISBN  978-1-118-53080-1.
  8. ^ Ralph Kimball; Margy Ross (2013). Wydanie trzecie zestawu narzędzi Data Warehouse Toolkit . Wileya. P. 51. Numer ISBN  978-1-118-53080-1.
  9. ^ Ralph Kimball; Margy Ross (2013). Wydanie trzecie zestawu narzędzi Data Warehouse Toolkit . Wileya. P. 48. Numer ISBN  978-1-118-53080-1.
  10. ^ Ralph Kimball, The Data Warehouse Toolkit, wydanie drugie, Wiley Publishing, Inc., 2008. ISBN  978-0-470-14977-5 , strony 253-256