Domanda

Sto esaminando l'idea di distribuire SSRS Report Builder basato sul Web ai nostri utenti finali per consentire loro di creare i propri report rispetto ai nostri database delle applicazioni di produzione. Da quello che ho visto finora, questo strumento è più facile da usare rispetto al designer di report Intel Studio VS Biz, inoltre è più facile da installare e la distribuzione dei report è molto più comprensibile per un utente finale (inoltre la cosa più grande non è SQL Immagino).

Qualcuno ha qualche idea o esperienza sulle insidie ??di dare agli utenti questo tipo di potere? In questo momento, riceviamo molte richieste per esportare i dati in un file flat in modo che possano leggerlo e quindi creare report in Access rispetto ad esso, quindi immagino che SSRS sarebbe meglio di Access ...

È stato utile?

Soluzione

Alcuni suggerimenti per la progettazione del modello di report:

1. Crea un data mart

Esistono diversi strumenti come Generatore report: Business Objects, Oracle Discoverer per nominarne un paio. Dispongono tutti di livelli di metadati che consentono di accedere a uno strumento di reporting per l'utente finale, tuttavia devono comunque essere alimentati con dati cucchiaio in un formato adatto per produrre una soluzione efficace. Ciò significa che devi davvero pensare anche in termini di creazione di una sorta di data-mart.

Senza dati puliti, gli strumenti esporranno tutti i gotcha nel database di produzione, quindi gli utenti dovranno capirli per ottenere risultati corretti. Ciò significa che la segnalazione dovrebbe davvero provenire da una fonte di dati pulita.

Hai circa zero controllo sull'SQL prodotto da questi strumenti, quindi sono abbastanza capaci di produrre query che erneranno il tuo database di produzione. Ciò significa che la segnalazione deve avvenire su un server separato. Uno schema che sia amichevole con strumenti ad hoc (come uno schema a stella) mitigherà il peggio dei potenziali problemi con le prestazioni.

2. Pulisci i dati

Non ci sono sviluppatori nel ciclo con strumenti ad-hoc, quindi gli utenti useranno ingenuamente lo strumento senza sapere quali sono i problemi dei dati. Risultati di query imprecisi verranno sempre visualizzati come colpa dello strumento . Per credibilità, queste insidie ??devono essere eliminate dal set di dati a monte dello strumento.

3. Rendi la navigazione solida e idiota

Il generatore di report può impostare restrizioni per il passaggio da un'entità all'altra. Senza questi, è possibile unire più tabelle insieme in una relazione m: m. Questo si chiama Fan Trap e restituirà totali errati. È necessario impostare il modello in modo che le singole tabelle dei fatti siano aggregate su dimensioni comuni, ovvero arrotolate prima che vengano unite. Fare questo bene elimina una classe di errori. La maggior parte degli strumenti ha alcuni meccanismi per impedirlo.

4. Rendi i dati aggregati

Puoi ottenerlo gratuitamente da Business Objects, ma dovrai creare esplicitamente una misura aggregata su ogni misura di base con Generatore report. Nascondere le misure di base ed esporre gli aggregati. Ciò significa che il sistema eseguirà il rollup dei dati in base alla dimensione delle dimensioni scelte dall'utente.

Conclusione

Non è probabile che il posizionamento di uno strumento ad hoc direttamente su un database di produzione funzioni correttamente. I dati avranno troppe insidie ??e lo schema non si presterà alla segnalazione. Ciò significa che sei pronto per un po 'di lavoro nella creazione di un data mart per cancellare i dati e prepararli per lo strumento. Se stai trascorrendo molto tempo a costruire estratti ad hoc, potrebbe esserci un caso aziendale semplicemente nel tempo degli sviluppatori che risparmierebbe in seguito.

MODIFICA: la Procedura guidata modello di report (come la maggior parte di queste cose) crea un bel casino quando viene eseguita. Dovrai modificare le impostazioni come limitare la generazione di aggregati irrilevanti. In passato ho ottenuto risultati abbastanza buoni generando somme, nascondendo tutte le misure di base ed esponendo gli aggregati come se fossero misure di base. Questo ha dato un comportamento molto simile a Business Objects. In casi specifici potresti anche voler esporre conteggio, min / max o medie.

L'istanza particolare a cui sto pensando era un modello di report piuttosto grande con circa 1.500 campi al suo interno, quindi il fest aggregato generato dalla procedura guidata non era gestibile con oltre 10.000 campi in totale. Puoi anche impostare strutture di cartelle un po 'come Analysis Services e usarle per organizzare i campi. Infine, se immessa, la descrizione nel campo verrà visualizzata come descrizione comandi se ci si passa sopra con lo strumento per l'utente finale.

Altri suggerimenti

Solo alcuni commenti sulla risposta precedente:
1. Il modello di query semantica utilizzato dal Generatore report di SQL Server Reporting Services è stato progettato con l'intento esplicito di impedire Fan Trap / totali errati nelle relazioni m: m. Non è necessario alcuno sforzo aggiuntivo per abilitare questa funzionalità; è inerente alla struttura delle query generate da Report Builder.
2. La procedura guidata del modello crea misure aggregate su campi numerici per impostazione predefinita, quindi non è necessario alcun ulteriore sforzo per esporre gli aggregati. È possibile personalizzare il modello aggiungendo o rimuovendo i calcoli aggregati come appropriato.

Nel complesso, il vecchio adagio "immondizia in immondizia" certamente si applica. Se i tuoi dati non sono puliti, Report Builder o altri strumenti di reporting ad hoc lo renderanno più evidente.

Aaron Meyers
Ingegnere di sviluppo software, SQL Server Reporting Services
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top