Generador de informes SSRS: ¿problemas de la experiencia?

Question

Estoy estudiando la idea de implementar el Generador de informes SSRS basado en la web para nuestros usuarios finales para permitirles crear sus propios informes en nuestras bases de datos de aplicaciones de producción. Por lo que he visto hasta ahora, esta herramienta es más fácil de usar que el diseñador de informes VS Biz Intel Studio, además es más fácil de instalar, y la implementación de los informes es mucho más comprensible para un usuario final (además, lo más importante es que no hay SQL Supongo).

¿Alguien tiene alguna idea o experiencia sobre las trampas de dar a los usuarios este tipo de poder? En este momento, recibimos muchas solicitudes para exportar los datos a un archivo plano para que puedan leerlo y luego generar informes en Access, así que creo que SSRS sería mejor que Accesss ...

Answer 1

Algunos consejos para el diseño del modelo de informe:

1. Construye un data mart

Hay varias herramientas como Report Builder: Business Objects, Oracle Discoverer, por nombrar un par. Todos tienen capas de metadatos que le permiten llegar a una herramienta de informes para el usuario final, sin embargo, todavía necesitan datos de cuchara en un formato adecuado para producir una solución efectiva. Esto significa que realmente necesita pensar en términos de construir algún tipo de data mart también.

Sin datos limpios, las herramientas expondrán todas las trampas en la base de datos de producción, por lo que los usuarios deberán comprenderlas para obtener resultados correctos. Esto significa que los informes realmente deberían proceder de una fuente de datos limpia.

Usted tiene aproximadamente cero control sobre el SQL que producen estas herramientas, por lo que son bastante capaces de producir consultas que herniarán su base de datos de producción. Esto significa que su informe debe tener lugar en un servidor separado. Un esquema que sea amigable con las herramientas ad-hoc (como un esquema en estrella) mitigará los peores problemas potenciales con el rendimiento.

2. Limpia los datos

No hay ningún desarrollador en el bucle con herramientas ad-hoc, por lo que los usuarios usarán ingenuamente la herramienta sin saber cuáles son los problemas de datos. Los resultados de consulta inexactos siempre se verán como culpa de la herramienta . Para mayor credibilidad, estos escollos deben eliminarse del conjunto de datos aguas arriba de la herramienta.

3. Haga que la navegación sea robusta y a prueba de idiotas

El generador de informes puede configurar restricciones para moverse de una entidad a otra. Sin estos, es posible unir varias tablas en una relación m: m. Esto se llama Trampa del ventilador y devolverá totales incorrectos. Debe configurar el modelo para que las tablas de hechos individuales se agreguen en dimensiones comunes, es decir, se acumulen antes de unirlas. Hacer esto correctamente elimina una clase de errores. La mayoría de las herramientas tienen algún mecanismo para prevenir esto.

4. Hacer la agregación de datos

Obtiene esto de forma gratuita de Business Objects, pero tendrá que poner una medida agregada sobre cada medida base explícitamente con Report Builder. Ocultar las medidas de base y exponer los agregados. Esto significa que el sistema acumulará los datos al grano de las dimensiones que el usuario haya elegido.

Conclusión

Colocar una herramienta ad-hoc directamente sobre una base de datos de producción no es probable que funcione bien. Los datos tendrán demasiadas trampas y el esquema no se prestará a los informes. Esto significa que está listo para trabajar en la construcción de una despensa de datos para eliminar los datos y prepararlos para la herramienta. Si pasa mucho tiempo creando extractos ad-hoc, puede haber un caso de negocios simplemente en el tiempo del desarrollador que esto ahorraría más adelante.

EDITAR: El Asistente de modelo de informe (como la mayoría de esas cosas) hace un gran desastre cuando se ejecuta. Tendrá que ajustar la configuración, como restringir la generación de agregados irrelevantes. En el pasado, he obtenido resultados bastante buenos al generar sumas, ocultar todas las medidas básicas y exponer los agregados como si fueran medidas básicas. Esto dio un comportamiento muy parecido a Business Objects. En casos específicos, es posible que también desee exponer recuento, mínimo / máximo o promedios.

La instancia particular en la que estoy pensando era un modelo de informe bastante grande con aproximadamente 1,500 campos, por lo que el festival agregado generado por el asistente no era manejable con más de 10,000 campos en total. También puede configurar estructuras de carpetas un poco como Analysis Services y usarlas para organizar los campos. Finalmente, si se ingresa, la descripción en el campo aparecerá como información sobre herramientas si pasa el mouse sobre ella en la herramienta de usuario final.

Answer 2

Solo algunos comentarios sobre la respuesta anterior:
1. El modelo de consulta semántica utilizado por el Generador de informes de SQL Server Reporting Services se diseñó con la intención explícita de evitar trampas de ventilador / totales incorrectos en las relaciones m: m. No se requiere ningún esfuerzo adicional para habilitar esta funcionalidad; es inherente a la estructura de consultas generadas por Report Builder.
2. El asistente de modelo crea medidas agregadas sobre campos numéricos de forma predeterminada, por lo que no se requiere ningún esfuerzo adicional para exponer los agregados. Puede personalizar el modelo agregando o eliminando cálculos agregados según corresponda.

En general, el viejo adagio "basura en basura" Ciertamente se aplica. Si sus datos no están limpios, Report Builder u otras herramientas de informes ad hoc lo harán más evidente.

Aaron Meyers
Ingeniero de Desarrollo de Software, SQL Server Reporting Services