Obsługa wartości null w Datawarehouse

Question

Chciałbym zapytać o dane wejściowe na temat najlepszej praktyki w zakresie obsługi zerowych lub pustych wartości danych, jeśli dotyczą one hurtowni danych i SSIS/SSAS.

Mam kilka tabel faktów i wymiarów, które zawierają wartości null w różnych wierszach.

Dodatkowo:

1) Jaki jest najlepszy sposób obsłużyć zerowe daty/godziny wartości? Czy powinienem wstawić "domyślny" wiersz w moim czasie lub terminie i wskazać SSIS do domyślnego wiersza, gdy zostanie znaleziona wartość NULL?

2) Jaki jest najlepszy sposób postępowania z wartościami zerowymi/pustymi wartościami w danych wymiaru. Przykład: Mam kilka wierszy w wymiarach "Konta", które mają puste (nie NIŻE) wartości w kolumnie Nazwa konta. Czy należy przekonwertować te puste lub puste wartości wewnątrz kolumny na określoną wartość domyślną?

3) Podobny do punktu 1 powyżej - Co należy zrobić, jeśli kończy się z Facttable wiersza, który nie ma rekord w jednej z kolumn wymiaru? Czy potrzebne są domyślne rekordy wymiarów dla każdego wymiaru, na wypadek gdyby tak się stało?

4) Wszelkie sugestie lub porady dotyczące sposobu obsługi tych operacji w usługach integracyjnych serwera SQL (SSIS)? Najlepsze konfiguracje przepływu danych lub najlepsze obiekty transformacji do użycia będą pomocne.

Dzięki :-)

Answer 1

W poprzedniej odpowiedzi wskazuje, że może być wiele różnych znaczeń dołączone NULL wartości wymiaru, nieznane, nie dotyczy, nie wiadomo itd. Jeśli jest to przydatne, aby móc odróżnić je w swojej aplikacji, dodając " pomocne mogą być pseudo-wymiarowe wpisy.

W każdym razie unikałbym posiadania kluczy obłędnych lub wymiarów o wartości Null, a nawet pojedyncza "nieznana" wartość wymiaru pomoże użytkownikom zdefiniować zapytania zawierające grupowanie grupowe, w których jakość danych nie jest równa 100 % (i nigdy nie jest).

Jedna bardzo prosta sztuczka, której używałem do tej pory i jeszcze mnie nie ugryzła, to zdefiniowanie moich wymiarów zastępczych kluczy za pomocą int TOŻSAMOŚĆ (1,1) w T-sql (początek z 1 i przyrost o 1 na rząd). Klucze Pseudo ("Niedostępne", "Nieprzypisane", "Nie dotyczy") są zdefiniowane jako negatywne int i zapełniane przez procedurę przechowywaną uruchamianą na początku procesu ETL.

Przykładowo Tabela utworzona jako

    CREATE TABLE [dbo].[Location] 
    (
     [LocationSK] [int] IDENTITY(1,1) NOT NULL, 
     [Name] [varchar](50) NOT NULL, 
     [Abbreviation] [varchar](4) NOT NULL, 
     [LocationBK] [int] NOT NULL, 
     [EffectiveFromDate] [datetime] NOT NULL, 
     [EffectiveToDate] [datetime] NULL, 
     [Type1Checksum] [int] NOT NULL, 
     [Type2Checksum] [int] NOT NULL, 
    ) ON [PRIMARY] 

i procedury przechowywanej wypełniania stół

Insert Into dbo.Location (LocationSK, Name, Abbreviation, LocationBK, 
         EffectiveFromDate, Type1Checksum, Type2Checksum) 
      Values (-1, 'Unknown location', 'Unk', -1, '1900-01-01', 0,0) 

dokonaniu to regułę mieć co najmniej taką jedną pseudosferyczną wiersz na wymiar, który jest stosowane w przypadkach, gdy wyszukiwanie wymiarów nie powiedzie się i tworzenie raportów wyjątków w celu śledzenia liczby faktów przypisanych do takich wierszy.

Answer 2

1. Albo NULL lub zarezerwowanym id z datą wymiar z odpowiednim znaczeniem. Pamiętaj, że NULL naprawdę może mieć wiele różnych znaczeń, może być nieznany, nieważny, nieprawidłowy itp.

2. Wolałbym pusty ciąg (i nie NULLABLE), ale w projekcie, nad którym teraz pracuję, konwertuje pusty ciąg na NULL i pozwala im w bazie danych. Potencjalnym problemem, który należy omówić, jest to, że pusty środkowy inicjał (nie ma drugiego imienia, więc środkowy inicjał jest pusty) różni się od nieznanego środkowego inicjału lub podobnej semantyki. Dla pieniędzy nasz model dopuszcza NULL - mam na ten temat duży problem, ponieważ zazwyczaj powinny one wynosić 0, zawsze są używane jako 0 i zawsze muszą być opakowane za pomocą ISNULL(). Ale z powodu zasady ETL konwersji pustego ciągu na NULL, zostały one ustawione na NULL - ale był to tylko artefakt formatu pliku transportu o stałej szerokości, który miał spacje zamiast 0 z niektórych systemów źródłowych.

3. Nasze fakt tabele mają zwykle PK na podstawie wszystkich wymiarach, więc to nie będzie mogła - byłoby połączone z manekina lub nieznanego wymiaru

4. w SSIS zrobiłem element wykończenia, który trymuje spacje od końców wszystkich strun. Zazwyczaj musieliśmy przeprowadzić wiele walidacji i konwersji dat w SSIS, co byłoby najlepsze w komponencie.

Answer 3

Dzięki za wejście,

dwie rzeczy zrobiłem na moim najnowszym projekcie są:

1) Używane sugestia Steve'a o negatywnych klucze identyfikacyjne dla szczególnych wartości wymiarów Nieznany /. To działało doskonale i nie pojawiły się żadne problemy podczas procesu budowania kostek SSAS.

2) Utworzono transformacje, aby sprawdzić, czy wartość jest pusta, a jeśli tak, przekonwertuj na -1 (nieznany rekord w wymiarze) LUB jeśli jest to wartość zmierzona, przekonwertuj na 0. Wyrażenia są pokazane poniżej jako przykłady (Kiedyś te w Derived przemian kolumn):

ISNULL(netWeight) ? 0 : netWeight // This is an example of a Measure column 
ISNULL(completeddateid) ? -1 : completeddateid // This is an example of a dimension key column 

mam nadzieję, że to pomoże ktoś w przyszłości ;-)

Answer 4

Innym rozwiązaniem i może sugerować, że jest w trakcie ETL-step stół transfer jest zdefiniowane, do którego importowane rekordy są tymczasowo przechowywane PO wszystkich niezbędnych transformacjach. Dodałbym kilka dodatkowych atrybutów do tej tabeli transferu, pozwalając komuś; obok oryginalnych atrybutów wartości, które mogą mieć wartość NULL lub inną niepożądaną wartość; wstawić "zakodowaną" wartość identyfikującą problem z jednej strony i nazwę-atrybutu, w którym wystąpiła błędna wartość.

Po wykonaniu tej czynności nadal mogę zdecydować, jak wykorzystać zdenormalizowane i przesłane dane w późniejszym kroku ... ewentualnie odfiltrowując błędne wartości lub wymieniając je w osobnym wymiarze błędu, aby uwzględnić je w raportach stwierdzających, które wartości były odbiegające od normy oraz jak mogą/mogłyby wpłynąć na zagregowane wartości.

np.

error-code attribute= -1 = NULL date -2 = NULL numerical value -3 = NULL PK -4 = NULL text value 

a drugi atrybut = IdOrder, BirthDate, OrderAmount itp

Oczywiście, że jesteś w dużo więcej kłopotów jeśli rekordy mogą mieć więcej niż 1 błędną wartość (null), ale w tym przypadku można albo zwiększyć liczbę atrybutów "śledzenia", albo "wrócić do źródła" i dowiedzieć się, gdzie i dlaczego zaistniał problem (wraz z dep dep.)

Jest to dość skomplikowany krok, jednak ze względu na kompletność i poprawność uważam, że jest to nieuniknione i konieczne, ponieważ w przeciwnym razie można by skonfrontować się z bardzo zagregowanymi informacjami.

Może to też ktoś pomoże;)