Enterprise Wide Keys [chiuso]

3

Da molto tempo lavoro su un ODS e sul Data Warehouse. Entrambi integrano una vasta gamma di fonti di dati da applicazioni di tubi di stufa. Uno degli usi dell'ODS è quello di fornire dati ad altre applicazioni di tubi di stufa.

Immagina che una app gestisca un database di personale e un'altra app gestisca le vendite di tracciamento. Occasionalmente, l'app di vendita potrebbe aver bisogno di avere un drop down del personale che qualcuno può scegliere, per esempio per accreditare un particolare dipendente con una vendita / commissione.

L'applicazione di vendita può interrogare l'ODS per ottenere l'elenco del personale. Ciò consente all'app personale di modificare la propria struttura dati e l'ODS modifica il processo ETL per adattarsi a tale modifica. Pertanto tutte le altre app che consumano tali dati non saranno influenzate dal cambiamento.

L'app di vendita dovrà salvare un PersonnelID per quel record di vendita / commissione nel proprio database. Tuttavia, la volta successiva che l'ODS viene aggiornato, se utilizza una tecnica a pieno carico, la chiave cambierà. Dal momento che il PersonnelID memorizzato nel database Sales è un database separato, non esiste un modo semplice per sovrapporre tale modifica.

Questo crea una sfida in cui qualsiasi modifica apportata all'ODS deve essere fatta con molta attenzione e può anche limitare determinati progetti perché le applicazioni esterne dipendono da quelle chiavi per non cambiare mai. Eviterei di solito di esporre le chiavi agli utenti, ma in questo caso sembra necessario consentire alle app esterne di fare riferimento a entità aziendali nelle proprie applicazioni.

Lo stesso vale per le tabelle di ricerca che sono disponibili nell'ODS, dove una tabella di ricerca ha chiavi e testo.

Dopo un carico completo di ODS, posso garantire che le chiavi soddisfino l'integrità referenziale all'interno del database, ma non con database esterni che utilizzano tali chiavi. Dato che ci sono alcune parti dell'ODS attualmente codificate come un carico completo, che causerebbe la rigenerazione delle chiavi, avrei bisogno di ricodificare quell'ETL per essere incrementale, in modo che i database esterni possano fare riferimento a quelle chiavi senza temere che cambino.

Quali tecniche vengono utilizzate quando si dispone di un'origine dati di livello aziendale e altre applicazioni consumano tali dati e devono memorizzare le entità di riferimento di chiavi esterne in tali dati? Come si disaccoppiano il più possibile i riferimenti alle chiavi esterne senza complicare l'accesso a tali dati?

Attualmente sto usando le funzioni con valori di tabella per fornire accesso ai dati. Ho scelto questo approccio perché consente parametri, join e disaccoppia l'accesso alle tabelle sottostanti che potrebbero cambiare in seguito.

    
posta AaronLS 03.08.2012 - 22:17
fonte

1 risposta

2

Devi rispettare queste regole:

  1. Le applicazioni OLTP non cambiano le chiavi.

  2. ODS genera le proprie chiavi di Business Intelligence.

  3. Il database Datawarehouse mai fa riferimento a chiavi OLTP e deve utilizzare le chiavi generate da ODS (passaggio 2).

Non c'è modo di orientarsi su nessuna delle regole di cui sopra, a meno che non si faccia un carico completo ogni notte.

Provare a ottenere "delta" (solo dati modificati) da OLTP è di solito un incubo in sistemi aziendali di grandi dimensioni come Siebel, SAP, ecc. a meno che l'ETL non fornisca "connettori" (query predefinite contro ERP e strumenti simili) e tu abbia esperienza nel sistema OLTP di origine. Anche allora, di solito è difficile a causa della complessità di tali schemi aziendali.

Ancora una volta, devi rispettare la regola precedente e molto probabilmente, non c'è altro modo. Kimball, ha una buona serie di libri sull'argomento se ti interessa scavare di più.

    
risposta data 04.08.2012 - 00:00
fonte

Leggi altre domande sui tag