Astrazione del database in un'applicazione di reporting

Question

In un'applicazione di reporting, è possibile astrarre la logica di reporting e i dettagli dello schema del database?

Ho un'applicazione Reporting Services con una logica di reporting ragionevolmente complessa, sto cercando di migrare l'applicazione su altri database.(Database costruiti per lo stesso scopo ma sviluppati da diverse software-house.)

È una decisione saggia utilizzare un livello di servizi Web/WCF nel mezzo?Quali altre opzioni possono essere prese in considerazione?

Answer 1

Sarebbe difficile fare questo genere di cose in un one-size-fits-all strada nel caso generale, ma si potrebbe provare uno di questi:

• costruire qualche vista sul schema del database e scrivere i sprocs segnalazione contro quelli. Questo significa che avete una certa flessibilità nello schema del database sottostante e può utilizzare i punti di vista come un livello di astrazione.

• Crea una sorta di data warehouse piattaforma e scrivere un processo ETL per popolarla dalle varie fonti di dati. Questo è più flessibile, ma più impegno per costruire e funzionerà solo da un aggiornamento periodico. Se quel grado di latenza è accettabile per la vostra applicazione, allora vorrei suggerire che il sistema di data warehouse è l'approccio migliore.

  Il vantaggio principale di un data warehouse è che è ottimizzato per la segnalazione ed ha un'interfaccia coerente in tutte le fonti di dati - si consolidarli in un unico database con uno schema. I rapporti sono sviluppati nei confronti di tale schema. Aggiunta di nuovi sistemi è ottenuta scrivendo un processo ETL per popolare magazzino; i rapporti continuano a lavorare indipendentemente dalla sorgente dati.

WCF è un sistema di comunicazione di rete. Troverete che è difficile fare questo tipo di architettura di gestire grandi volumi di dati su una transazione per transazione - un processo di ETL in batch di caricamento sarebbe molto più efficiente. Tuttavia, se avete bisogno di un feed in tempo reale (forse per un sistema di trading floor) potrebbe essere in grado di farlo con qualcosa di simile.

Se si Nead un feed a bassa latenza un altro approccio sarebbe quello di indagare su un genere di utensili chiamato Enterprise Information Integration . Forse lo strumento più ampiamente disponibile che può fare questo è un vista origine dati SSIS che ti dà una certa flessibilità nella mappatura fonti di dati arbitrari a uno schema coerente. Non è sofisticato come il migliore di razza strumenti EII, ma si può mettere i pacchetti SSIS su di esso e usare quelli come sorgente di dati per i report, se avete bisogno di trasformare ulteriormente i dati.

Tuttavia, non ho mai costruito un sistema strutturato come questo quindi non posso davvero garantire per come funziona nella pratica. Direi che sarebbe abbastanza fragile e difficile da abbattere in parti che possono essere unità di test, in modo dallo sviluppo e la manutenzione sarà abbastanza tempo per un sistema di complessità non banale.

Se si vuole indagare su altri sistemi EII sul mercato Questo link è un elenco di vari articoli su EII ed alcuni altri fornitori di utensili EII.

Answer 2

Sono d'accordo con il suggerimento del data warehouse di NXC:

• Se si trattasse di un lavoro una tantum no, ma poiché si tratta di una "applicazione di reporting", è molto probabile che molti dei tuoi report si adattino al paradigma OLAP.
• Si tratta ovviamente di un compito fattibile, poiché sul mercato sono disponibili molti strumenti di query OLAP di successo, con vari gradi di complessità
• Schemi OLAP, ad esempio lo standard schema stellare, Sono progettato essere facile da interrogare.Sono di natura piatta, con la tabella dei fatti che si unisce a una o più tabelle delle dimensioni utilizzando semplici chiavi in ​​modo molto diretto.
• i tipi di operazioni che le persone vorranno fare con i report sono prevedibili:filtra, ordina, raggruppa per, aggiungi o rimuovi colonne, esporta in CSV, ecc.
• otterrai un buon livello di flessibilità con i report generati: la capacità di esplorare i dati per varie relazioni crea molto dipendenza
• una volta scritto lo strumento di query, è portatile per essere riutilizzato con qualsiasi altro schema a stella: non male!
• "È possibile astrarre la logica di reporting e i dettagli dello schema del database?" - Sì, gli schemi OLAP sono esattamente per questo - rendono tutti i dati conformi a uno schema standardizzato.Ovviamente questo sposta la logica aziendale nel livello ETL, ma direi che è quello il suo posto.

Pertanto, ti viene richiesto di eseguire ETL con questo approccio: un'opzione è eseguire una qualche forma di ROLAP, ma in pratica ho scoperto che scrivere script ETL è altrettanto facile quanto lo è ottenere buone prestazioni da una configurazione ROLAP.

Answer 3

Una risposta che penso generalmente tornare a mordere voi nella parte posteriore, ma che gli altri So che ti piace, è quello di produrre i dati in formato XML da ogni database. Che ti dà un insieme coerente di dati in una forma che la maggior parte dei prodotti possono maneggiare facilmente.

Se si esegue questa operazione, assicurarsi che la query XPath verrà eseguito su di esso sarà veloce.