我正在研究将基于Web的SSRS报表生成器推广给最终用户的想法,以允许他们针对我们的生产应用程序数据库创建自己的报表.从我到目前为止看到的,这个工具比VS Biz Intel Studio报表设计器更容易使用,而且它更容易安装,并且最终用户更容易理解部署报表(最重要的是没有SQL)我猜).
有没有人对给用户这种权力的陷阱有任何想法或经验?现在,我们收到很多请求将数据导出到平面文件,以便他们可以读取它,然后在Access中构建报告,所以我认为SSRS会比Access更好...
报告模型设计的一些提示:
1.构建数据集市
有一些工具,如Report Builder:Business Objects,Oracle Discoverer等.它们都具有元数据层,可以为您提供最终用户报告工具的一些方法,但是它们仍然需要以合适的格式提供勺子数据才能生成有效的解决方案.这意味着你真的需要考虑构建某种数据集市.
如果没有干净的数据,这些工具将公开生产数据库中的所有问题,因此用户必须了解这些问题才能获得正确的结果.这意味着报告应该真正脱离干净的数据源.
您对这些工具生成的SQL几乎没有控制权,因此它们能够生成追踪生产数据库的查询.这意味着您的报告应该在单独的服务器上进行.对ad-hoc工具(例如星型模式)友好的模式将缓解性能最严重的潜在问题.
2.清理数据
循环中没有开发人员使用ad-hoc工具,因此用户可以在不知道数据问题的情况下天真地使用该工具. 不准确的查询结果将始终被视为工具的错误.为了可靠性,需要从工具上游的数据集中消除这些缺陷.
3.使导航健壮,防止傻瓜
报表生成器可以设置从一个实体移动到另一个实体的限制.没有这些,就可以在am:m关系中将多个表连接在一起.这称为扇形陷阱,将返回错误的总计.您需要设置模型,以便在常见维度上聚合各个事实表 - 即在加入之前汇总.正确使用可以消除一类错误.大多数工具都有一些防止这种情况的机制
4.使数据汇总
您可以从Business Objects免费获得此功能,但您必须使用报表生成器明确地对每个基本度量进行聚合度量.隐藏基本度量并公开聚合.这意味着系统会将数据汇总到用户选择的维度.
结论
直接在生产数据库上放置临时工具不太可能正常工作.数据将有太多陷阱,架构不适合报告.这意味着您需要构建数据集市以清理数据并为该工具准备数据.如果您花费大量时间构建临时提取,那么可能只是在开发人员时间有一个商业案例,这将在以后保存.
编辑:报表模型向导(像大多数这样的东西)运行时相当混乱.您必须调整设置,例如限制无关聚合的生成.在过去,通过生成总和,隐藏所有基本度量并将聚合暴露为基本度量,我已经取得了相当不错的结果.这给了很像Business Objects的行为.在特定情况下,您可能还希望公开计数,最小/最大或平均值.
我正在考虑的特定实例是一个相当大的报表模型,其中包含大约1,500个字段,因此从向导生成的聚合效果是无法管理的,总共有10,000多个字段.您还可以像Analysis Services一样设置文件夹结构,并使用它们来组织字段.最后,如果输入,如果您将鼠标悬停在最终用户工具上,该字段上的说明将显示为工具提示.
总的来说,古老的格言"垃圾中的垃圾"当然适用.如果您的数据不干净,那么报表生成器或其他临时报表工具将使这一点更加明显.
Aaron Meyers