W tabeli faktów w Autonomous Data Warehouse są składowane dane kostki Essbase mającej partycję federowaną. Jeśli nie istnieje tabela faktów spełniająca wymagania dotyczące partycji federowanych, należy ją utworzyć. Należy także zrozumieć, czym jest wymiar przestawny, co umożliwi wybranie go z kostki Essbase.
Przed rozpoczęciem tej sekcji należy utworzyć aplikację i kostkę Essbase, o ile nie zostały już utworzone.
Gdy są używane partycje federowane, w tabeli faktów są składowane wartości danych kostki Essbase. Jeśli w Autonomous Data Warehouse nie znajduje się wymagana tabela faktów, należy ją utworzyć.
Przed rozpoczęciem należy upewnić się, że jest dostępny pusty schemat dla tabeli faktów. Zob. Tworzenie schematu dla partycji federowanych.
Tabela faktów musi mieć format obsługiwany przez Essbase, co oznacza, że musi spełniać następujące wymagania dotyczące zawartości i kształtu:
Każdy z wymiarów (nieatrybutowych) kostki musi reprezentować nagłówek jednej kolumny. Nie dotyczy to jednego z wymiarów kostki (zazwyczaj jest to wymiar zawierający miary/konta), który musi zostać przestawiony tak, aby odpowiadał co najmniej dwóm kolumnom.
Uwaga:
W innych miejscach w dokumentacji wymiar, który został przestawiony, będzie nazywany wymiarem przestawnym.
Tabela faktów musi składać się z unikatowych rekordów (bez duplikatów), które mają jeden wiersz na sekwencję części wspólnych komórek Essbase.
Użytkownicy zaznajomieni z eksportami danych Essbase zauważą, że kształt tabeli faktów jest dokładnie taki sam jak kształt eksportu kolumn Essbase.
Podobnie jak eksport kolumn, tabela faktów musi zawierać:
jedną kolumnę dla każdego wymiaru (nieatrybutowego) struktury (z wyjątkiem wymiaru przestawnego)
po jednej kolumnie dla każdego ze składowanych elementów wymiaru przestawnego
Poniżej znajduje się przykład tabeli faktów, w której wymiar miar został przestawiony, co oznacza, że jest wymiarem przestawnym. Wymiar przestawny ma wpływ na kształt tabeli faktów, ponieważ składowane elementy tego wymiaru stają się nagłówkami kolumn: SALES, COGS, MARKETING, PAYROLL, MISC, INTITIAL_INVENTORY i ADDITIONS.
Tabelę faktów można skonstruować przy użyciu języka SQL, ale można też utworzyć ją na podstawie eksportu danych Essbase. Dane można załadować do tabeli faktów za pomocą narzędzi Autonomous Data Warehouse lub funkcji ładowania danych Essbase.
Dodatkowe wytyczne dotyczące konstruowania tabeli faktów:
Tabela faktów musi mieć mniej niż 1000 kolumn.
Nie można uwzględniać kolumn, które będą mapowane w Essbase na wymiary atrybutów.
Precyzja tabeli faktów nie może być niższa niż IEEE binary64 (liczba podwójna).
Tabela faktów musi zawierać międzynarodowe napisy odpowiadające elementom wymiarów. Te napisy muszą być typu NVARCHAR2 o 1024-bitowej długości znaków.
Przykład tworzenia tabeli faktów
Aby utworzyć tabelę faktów w Autonomous Data Warehouse, można użyć języka SQL.
Używając narzędzia SQL Developer lub innego wybranego narzędzia, zalogować się do Autonomous Data Warehouse jako właściciel schematu (z kroku Tworzenie schematu dla partycji federowanych).
W przypadku braku tabeli faktów utworzyć taką tabelę, używając języka SQL.
Na przykład poniższy kod SQL umożliwia utworzenie tabeli faktów na podstawie eksportu danych z kostki Essbase o nazwie "Sample Basic".
CREATE TABLE "SAMP_FACT" ( "PRODUCT" NVARCHAR2(1024), "MARKET" NVARCHAR2(1024), "YEAR" NVARCHAR2(1024), "SCENARIO" NVARCHAR2(1024), "SALES" NUMBER(38,0), "COGS" NUMBER(38,0), "MARKETING" NUMBER(38,0), "PAYROLL" NUMBER(38,0), "MISC" NUMBER(38,0), "INITIAL_INVENTORY" NUMBER(38,0), "ADDITIONS" NUMBER(38,0) ) NOCOMPRESS LOGGING PARALLEL 4;
Uwagi
W powyższym przykładzie tabela faktów ma nazwę SAMP_FACT i jest oparta na kostce "Sample Basic".
W celu zapewnienia możliwie najlepszej wydajności wszystkie kolumny nieliczbowe w tabeli faktów powinny być typu NVARCHAR2(1024), a wszystkie kolumny liczbowe - typu NUMBER.
Oracle zaleca włączenie równoległego tworzenia indeksu w Autonomous Data Warehouse przez dodanie podpowiedzi PARALLEL 4.
Kolumny metadanych nie mogą zezwalać na uwzględnianie wartości NULL.
Oracle zaleca używanie klauzuli NOCOMPRESS, jeśli kostka jest używana na potrzeby procesów generowania danych, takich jak przyrostowe ładowanie danych lub aktualizacje skryptów wsadowych. Jeśli kostka ma być używana głównie do wykonywanie operacji odczytu, należy użyć klauzuli COMPRESS w celu zoptymalizowania tabeli faktów pod kątem raportowania.
Jeśli podczas tworzenia tabeli faktów pojawi się poniższy komunikat o błędzie, to należy usunąć wiersze z wartością Null.
ORA-18265: fact table key column ("<DIM_NAME>") with value ('') not in dimension("<Name_of_Column") star table key column
Aby uzyskać najwyższą wydajność, należy zrezygnować z dodawania jakichkolwiek ograniczeń w tabeli, chyba że jest to naprawdę konieczne.
W powyższym przykładzie nazwa tabeli faktów została utworzona na podstawie kostki "Sample Basic", która jest dostępna w sekcji galerii w Katalogu plików Essbase. Można wyeksportować dane z tej przykładowej kostki lub dowolnej innej kostki Essbase i załadować je w celu skonstruowania tabeli faktów. Aby można było to zrobić, należy skonfigurować uwierzytelnienia umożliwiające ładowanie danych do aplikacji z partycją federowaną. Zob. Ładowanie danych partycji federowanej, aby skonfigurować uwierzytelnienia i dowiedzieć się, jak eksportować dane do formatu DBMS przy użyciu polecenia DATAEXPORT.
W ramach procesu projektowania partycji federowanej należy wybrać wymiar przestawny. Wymiar przestawny to wymiar wyznaczany ze struktury kostki Essbase, aby reprezentował liczbowe wartości danych.
Wymiar przestawny może, ale nie musi być wymiarem "Konta" lub "Miary".
Wszystkie elementy składowane wymiaru przestawnego muszą się mapować na kolumny tabeli faktów reprezentujące wartości danych liczbowych w Autonomous Data Warehouse.
Jeśli planowane jest uruchamianie skryptów obliczeń dotyczących wolumenu blokowego (BSO) w Essbase, jako wymiar przestawny należy wybrać wymiar gęsty. Skrypty obliczeń nie są obsługiwane w przypadku partycji federowanych, jeśli wymiar przestawny jest wymiarem rzadkim.
Wymiar przestawny musi mieć stosunkowo stałe nazwy elementów i nie może zawierać zbyt dużej liczby elementów. Przyczyna: Zmiana wymiaru przestawnego w strukturze kostki Essbase (na przykład przez dodanie składowanych elementów lub zmianę ich nazw) wymaga wykonania odpowiednich ręcznych aktualizacji w tabeli faktów w Autonomous Data Warehouse, a ponadto powoduje konieczność ponownego utworzenia partycji federowanej.
Wymiary Essbase, w których są zawarte elementy wymagające złożonych, dynamicznych formuł (takie jak "Opening Inventory" i "Ending Inventory" z przykładowej kostki Sample Basic), nie powinny być wybierane jako wymiar przestawny.
Wybrany wymiar przestawny podaje się podczas tworzenia partycji federowanej.
W bazach danych Oracle obowiązuje limit 1000 kolumn i jest on dziedziczony przez wymiar przestawny. Liczbę odpowiednich elementów kolumn w wymiarze przestawnym należy ustalić w taki sposób, aby nie przekroczyć tego limitu. Liczba potencjalnych kombinacji składowanych elementów w wymiarze przestawnym oraz liczba wymiarów w kostce nie mogą łącznie przekroczyć 1000.
W przypadku kostek stanowiących magazyn agregacji nie można wybierać wymiarów zawierających wielopoziomowe hierarchie elementów składowanych jako wymiarów przestawnych. Należy wybrać wymiar przestawny z hierarchiami dynamicznymi albo z hierarchią składowaną, która jest płaska i jednopoziomowa (gdzie wszystkie elementy są elementami składowanymi poziomu 0).