Pergunta

Eu estou olhando para a idéia de implantar-se a SSRS Report Builder baseado na web para nossos usuários finais, que lhes permitam criar seus próprios relatórios contra nossos bancos de dados de aplicativos de produção. Pelo que tenho visto até agora, esta ferramenta é mais fácil de usar do que o designer de relatórios VS Biz Intel Studio, além de que é mais fácil de instalar e implementar os relatórios é muito mais compreensível para o usuário final (mais a coisa mais importante é não SQL eu acho).

Alguém tem alguma ideia ou experiência sobre as armadilhas de dar aos usuários esse tipo de poder? Agora, temos um monte de pedidos para exportar os dados para um arquivo plano para que eles possam lê-lo e, em seguida, criar relatórios no Access contra ela, então eu acho SSRS seria melhor do que Accesss ...

Foi útil?

Solução

Algumas dicas para o projeto modelo de relatório:

1. Construir um data mart

Existem várias ferramentas como o Report Builder: Business Objects, Oracle Discoverer para citar alguns. Todos eles têm camadas de metadados que você obtenha algum do caminho para uma ferramenta de relatórios do usuário final, no entanto eles ainda realmente precisa ser dados alimentados com colher em um formato adequado a fim de produzir uma solução eficaz. Isso significa que você realmente precisa pensar em termos de construção de algum tipo de data-mart bem.

Sem dados limpos, as ferramentas irá expor todas as pegadinhas no banco de dados de produção, de modo que os usuários terão que entender estes para obter resultados corretos para fora. Isto significa que a comunicação deve realmente vir fora de uma fonte de dados limpo.

Você tem aproximadamente zero controle sobre o SQL que estas ferramentas produzem, então eles são capazes de produzir consultas que irá hérnia seu banco de dados de produção. Isto significa que a sua comunicação deve ocorrer em um servidor separado. Um esquema que é amigável para ferramentas ad-hoc (como um esquema em estrela) irá atenuar o pior dos problemas potenciais com o desempenho.

2. Limpe os dados

Não há programador no circuito com ferramentas ad-hoc, para que os usuários ingenuamente usar a ferramenta sem saber o que são os problemas de dados. resultados da consulta imprecisas será sempre visto como a falha da ferramenta . Para a credibilidade, essas armadilhas precisam ser eliminados do montante conjunto de dados da ferramenta.

3. Faça o robusto e à prova de idiotas de navegação

Report Builder pode configurar restrições ao movimento de uma entidade para outra. Sem estes, é possível juntar várias tabelas juntos em uma m: relacionamento m. Isso é chamado de Fan Armadilha e vai voltar totais incorretos. Você precisa configurar o modelo para que as tabelas de fatos individuais são agregados às dimensões comuns - ou seja enrolado antes de serem unidas. Obtendo este direito elimina uma classe de erros. A maioria das ferramentas têm algum mecanismo para impedir isso.

4. Tornar os dados agregados

Você tem isso de graça a partir da Business Objects, mas você terá que colocar uma medida agregada sobre cada medida básica explicitamente com o Report Builder. Esconder as medidas básicas e expor os agregados. Isto significa que o sistema vai rolar até os dados para o grão das dimensões que o usuário tenha escolhido.

Conclusão

Colocar uma ferramenta ad-hoc diretamente sobre um banco de dados de produção não é susceptível de funcionar bem. Os dados terá muitas armadilhas e o esquema não se prestará a geração de relatórios. Isso significa que você for para algum trabalho de construção de um data mart para esfregar os dados e prepará-lo para a ferramenta. Se você está gastando tempo significativo a construção de extratos ad-hoc, pode haver um caso de negócios simplesmente no tempo desenvolvedor este iria salvar mais tarde.

EDIT: O relatório de Assistente de modelo (como a maioria das coisas) faz uma bagunça quando for executado. Você vai ter que ajustar as configurações como restringir a geração de agregados irrelevantes. No passado, eu tive resultados muito bons gerando somas, escondendo todas as medidas básicas e expondo os agregados como se fossem medidas básicas. Isso deu um comportamento muito parecido com Business Objects. Em casos específicos, você também pode querer expor contagem, min / max ou médias também.

O caso particular eu estou pensando era bastante um grande modelo de relatório com cerca de 1.500 campos na mesma, de modo que o agregado-fest gerado a partir do assistente era un-gerenciável com mais de 10.000 campos no total. Você também pode configurar estruturas de pastas um pouco como Analysis Services e usá-los para organizar os campos. Finalmente, se entrou a descrição no campo vai aparecer como uma dica, se você passar o mouse sobre ele na ferramenta de usuário final.

Outras dicas

Apenas alguns comentários sobre a resposta anterior:
1. O modelo de consulta semântica usada pelo SQL Server Reporting Services Report Builder foi concebido com a intenção explícita de prevenir Fan armadilhas / totais incorretos em m: m relacionamentos. Nenhum esforço extra é necessário para habilitar essa funcionalidade; é inerente à estrutura de consultas gerados pelo Report Builder.
2. O assistente de modelo cria medidas agregadas sobre os campos numéricos, por padrão, de modo que nenhum esforço extra é necessário para expor agregados. Você pode personalizar o modelo adicionando ou removendo cálculos agregados conforme apropriado.

No geral, o velho ditado "lixo no lixo para fora" certamente se aplica. Se os dados não é limpa, em seguida, Report Builder ou outras ferramentas de relatórios ad hoc só vai fazer com que mais aparente.

Aaron Meyers
Engenheiro de Desenvolvimento de Software, SQL Server Reporting Services
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top