Gestione dei valori null nel Datawarehouse

Question

Vorrei chiedere la vostra opinione su cosa la pratica migliore è per il trattamento null o vuoto di valori di dati pertinenti per il data warehousing e SSIS/SSAS.

Ho diverse tabelle di fatto e dimensione che contengono valori null in righe diverse.

Specifiche:

1) Qual è il modo migliore per gestire null data/tempi di valori?Devo fare un 'default' riga nel mio tempo o la data dimensioni e punto di SSIS per riga default quando c'è un null?

2) Qual è il modo migliore per gestire null/valori vuoti all'interno della dimensione dei dati.Ex:Ho alcune righe in un 'Account' quote vuoto (non NULL) valori nella colonna Nome Account.Dovrei convertire questi valori vuoti o null all'interno della colonna per uno specifico valore di default?

3) Simile al precedente punto 1 - Cosa devo fare se io alla fine con un Facttable riga che non ha precedenti in una delle colonne di dimensioni?Ho bisogno della dimensione predefinita record per ogni dimensione nel caso in cui questo accade?

4) Qualsiasi suggerimento o consigli in merito a come gestire queste operazioni in Sql server integration services (SSIS)?Migliore flusso di dati, configurazioni o meglio la trasformazione di oggetti di uso sarebbe utile.

Grazie :-)

Answer 1

Come la precedente risposta afferma ci possono essere molti significati diversi collegati con valori null per una dimensione, sconosciuta, non applicabile, sconosciuto ecc Se è utile essere in grado di distinguere tra di loro nella vostra applicazione aggiunta di voci di quota "pseudo" può aiutare.

In ogni caso vorrei evitare aventi una realtà Null chiavi esterne o campi di quota, avendo anche un solo valore della quota 'sconosciuto' aiuterà gli utenti definiscono le query che includono un catch-all raggruppamento dove la qualità dei dati non è al 100% (e non lo è mai).

Un trucco molto semplice che ho usato per questo e non mi ha morso ancora è quello di definire le dimensioni chiavi surrogate utilizzando int IDENTITY (1,1) in T-SQL (inizio alle 1 e l'incremento dell'1 per riga ). chiavi Pseudo ( "non disponibile", "Non assegnato", "Non applicabile") sono definiti come interi negativi e popolato da una stored procedure corse all'inizio del processo di ETL.

Per esempio una tabella creata da

    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]

E una stored procedure popolare la tabella con

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

Ho fatto una regola di avere almeno uno di questi pseudo fila per dimensione che viene utilizzato nei casi in cui la ricerca non riesce dimensione e di costruire relazioni sulle eccezioni per tenere traccia del numero di fatti che sono assegnati a tali righe.

Answer 2

1. NULL o riservato id dalla data dimensione, con un appropriato senso.Ricordate NULL davvero può avere molti significati diversi, potrebbe essere sconosciuto, inapplicabile, voci, etc.

2. Io preferirei la stringa vuota (e non NULLable), ma il progetto a cui sto lavorando ora converte una stringa vuota a NULL e permette loro nel database.Un potenziale problema da discutere è che un vuoto iniziale (senza secondo nome, così l'iniziale è noto per essere vuoto) è diverso da uno sconosciuto iniziale o simili semantica.Per i soldi, il nostro modello consente valori Null - io ho un grosso problema con questo, nei fatti, dal momento che in genere, che in realtà dovrebbe essere 0, vengono sempre utilizzati come 0 e hanno sempre essere avvolto con ISNULL().Ma a causa di ETL politica di conversione stringa vuota NULL, sono stati impostati a NULL - ma questo era solo un artefatto della larghezza fissa di trasporto formato di file che aveva spazi invece di 0 da alcuni sistemi di origine.

3. Il nostro tabelle dei fatti di solito hanno un PK sulla base di tutte le dimensioni, in modo che questo non sarebbe consentito, sarebbe legato a un manichino o dimensione sconosciuta

4. In SSIS ho fatto un assetto componente che accorcia gli spazi di estremità di tutte le stringhe.Noi di solito dovuto fare un sacco di data di convalida e di conversione in SSIS, che sarebbe stato meglio in un componente.

Answer 3

Grazie per l'ingresso,

Due cose che ho fatto sul mio ultimo progetto sono:

1) Usato suggerimento di Steve su tasti ID negative per i valori dimensione sconosciuta / speciali. Questo ha funzionato perfettamente e senza problemi sorti durante il processo di costruzione del cubo SSAS.

2) trasformazioni creati per verificare se un valore è nullo, e se così, convertono a uno -1 (Risultati Unknown nella dimensione) o se è un valore di misura, convertono a 0. Le espressioni sono riportati di seguito come esempi (I usato questi in trasformazioni di colonna derivati):

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

Speriamo che questo aiuta qualcun altro in futuro; -)

Answer 4

Un'altra soluzione che posso suggerire è che durante la ETL-step un tavolo di trasferimento è definito in cui importare i record sono memorizzati temporaneamente dopo che tutte le trasformazioni necessarie. Vorrei aggiungere un paio di attributi extra a quel tavolo di trasferimento che permette a qualcuno; vicino al valore attributi originali che può essere nullo o qualche altro valore non-desiderato; per inserire un valore di "codice" che identifica il problema da un lato, e il nome di attributo in cui si è verificato il valore errato.

Dopo aver fatto che ho potuto ancora decidere come utilizzare i dati denormalizzati e trasferiti in un passaggio successivo ... forse filtrando i valori errati o menzionare in un errore dimensione separata per l'inclusione in rapporti affermando che i valori erano devianti e come possono / potrebbero eventualmente influenzare i valori aggregati.

per es.

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

e l'altro attributo = IdOrder, BirthDate, OrderAmount, ecc.

Naturalmente ci si trova in un sacco più problemi se i record può avere più di 1 valore errato (NULL), ma in quel caso si potrebbe o espandere il numero di "tracciare" attributi o "ritorno alla fonte" e scoprire dove e perché il problema si è verificato (insieme a dep sviluppo.)

E 'un po' un passo coinvolto, tuttavia per ragioni di completezza e correttezza Suppongo che sia inevitabile e necessaria, perché altrimenti si potrebbe essere di fronte ad informazioni aggregate male.

Forse anche questo contribuirà a qualcuno;)