Chiavi e vincoli primari

Question

Nel mio nuovissimo data warehouse creato (ovviamente) dal database OLTP, ho eliminato tutte le colonne IDENTITY e le ho cambiate in colonne INT.

Quali sono le migliori pratiche in merito a quanto segue, soprattutto dal momento che il magazzino è denormalizzato:

1. Chiave primaria
   - > questa potrebbe ora essere una chiave composita perché diverse tabelle si sono unite
   - > devo seguire la struttura chiave di OLTP?
   
   
2. Vincoli
   - > ci sono alcuni vincoli (NON NULL) con valori predefiniti (0) per le colonne di bit
   

Answer 1

Per la tua chiave primaria, considera l'utilizzo di una chiave surrogata o alternativa; dovrai provvedere alle dimensioni che cambiano lentamente, ad es. se negli ultimi 5 anni stai facendo un rapporto sulle vendite medie per venditore sposato / non sposato, ti consigliamo di registrare il fatto che qualcuno non è stato sposato per 2 anni, quindi sposato per gli ultimi 3. Ciò significa che il tuo data warehouse hanno due righe della tabella delle dimensioni per la stessa persona. Seguire la struttura OLTP per questo sarà difficile :)

I vincoli sono meno problematici; I DW sono ottimizzati in modo massiccio per le letture (supponendo che tu stia popolando come un batch) e i vincoli non tengono conto delle operazioni di lettura. In genere è possibile aggirare eventuali problemi di vincolo con il lavoro di compilazione DW e gestire i valori null ecc. Nello strumento di reporting, se necessario. È molto più importante assicurarsi che i valori predefiniti si adattino al modello di dati concettuali e non introdurre problemi negli strumenti client DW.

Answer 2

Per le tabelle dimensioni :

• Conserva PK surrogato di autoincremento (identità), ad eccezione della dimensione data (vedi sotto).
• Assicurati di avere una "chiave naturale" alternativa " per consentire la modifica lenta delle dimensioni (tipo 2).
• Nessun valore nullo consentito nelle tabelle delle dimensioni, sostituirle con verbose " n / a, non immesse, sconosciute .. "
• Se possibile, modifica i flag booleani (1/0) in verbose "Sì, No", per renderlo facile da usare / aziendale.
• Sbarazzati dei campi calcolati e sostituiscili con i valori, o almeno persisti il ??campo calcolato - dipende da un db.
• Se possibile, implementa lo schema a stella, scambia spazio per la velocità. Fiocco di neve solo se necessario.
• Controlla le tue query, se esiste una funzione nella clausola WHERE , aggiungi una colonna alla tabella delle dimensioni e calcola i valori.
• È facile partizionare la dimensione della data se il PK è simile a 20090619.
• Elimina i vincoli di controllo e le impostazioni predefinite, spostalo nella fase conforme del processo ETL. I controlli e le impostazioni predefinite rallentano il caricamento e, una volta terminato il caricamento, non svolgono alcun ruolo.

Per le tabelle :

• Considera di avere un PK surrogato con autoincremento (identità) per consentire un facile partizionamento, se usi un PK composito, puoi invece creare un unico composito non cluster.

• Disponi degli script per le tue chiavi esterne in un luogo sicuro, è pratica comune rilasciare le chiavi prima di caricare le tabelle dei fatti per velocizzare il caricamento. Alcune persone eseguono DW con chiavi esterne che sono "solo logiche", usano "cerca orfani" query dopo il caricamento.

ETL

• Progetta il tuo processo ECCD (ETL) in tutte le fasi: estrarre, pulire, conformare, consegnare.
• Se possibile, conservare i risultati intermedi (file) dopo ogni fase a fini di controllo e debug.
• Documenta l'ETL e se usi gli script usa un controllo di versione in modo da poter abbinare le versioni degli script con file archiviati (intermedi).
• Avere un grafico di derivazione dei dati, Excel è meglio di niente. Mantieni anche le versioni.

Answer 3

Direi circa 2 .: Colonne di bit - > lavora come bool cols - > consentito solo 1/0 (vero / falso) - > Vincolo ok