我正在考虑向我们的最终用户推出基于 Web 的 SSRS 报表生成器，以允许他们根据我们的生产应用程序数据库创建自己的报表。从我目前看到的情况来看，这个工具比 VS Biz Intel Studio 报表设计器更容易使用，而且它更容易安装，并且部署报表对于最终用户来说更容易理解（另外最大的一点是没有 SQL我猜）。
是否有人对赋予用户这种权力的陷阱有任何想法或经验？现在，我们收到很多将数据导出到平面文件的请求，以便他们可以读取它，然后在 Access 中针对它构建报告，所以我认为 SSRS 会比 Accesss 更好......
【问题讨论】：
标签： ms-access reporting-services usability reportbuilder
报表模型设计的一些技巧：
1.构建数据集市
有多种工具，例如 Report Builder：Business Objects、Oracle Discoverer 等等。它们都有元数据层，可以为您提供一些最终用户报告工具的方法，但是它们仍然需要以合适的格式提供数据，以便产生有效的解决方案。这意味着您确实需要考虑构建某种数据集市。
如果没有干净的数据，这些工具将暴露生产数据库中的所有问题，因此用户必须了解这些问题才能获得正确的结果。这意味着报告应该真正来自干净的数据源。
您对这些工具生成的 SQL 的控制几乎为零，因此它们非常有能力生成会使您的生产数据库突出的查询。这意味着您的报告应在单独的服务器上进行。对 ad-hoc 工具友好的模式（例如星型模式）将缓解最严重的潜在性能问题。
2。清理数据
没有开发人员参与使用 ad-hoc 工具，因此用户会在不知道数据问题是什么的情况下天真地使用该工具。 不准确的查询结果将始终被视为工具的故障。为了可信度，需要从工具上游的数据集中消除这些陷阱。
3.使导航功能强大且防白痴
报表生成器可以设置从一个实体移动到另一个实体的限制。如果没有这些，就可以将多个表以 m:m 关系连接在一起。这称为Fan Trap，将返回不正确的总数。您需要设置模型，以便在公共维度上聚合各个事实表 - 即在加入之前汇总。做到这一点可以消除一类错误。大多数工具都有一些防止这种情况发生的机制。
4.进行数据聚合
您可以从 Business Objects 免费获得此功能，但您必须使用 Report Builder 明确地对每个基本度量放置一个聚合度量。隐藏基本度量并公开聚合。这意味着系统会将数据汇总到用户选择的维度的粒度。
结论
将临时工具直接放在生产数据库上不太可能正常工作。数据将有太多陷阱，并且架构不适合报告。这意味着您准备好构建一个数据集市来清理数据并为该工具做好准备。如果您花费大量时间构建临时数据提取，那么可能有一个商业案例只是在开发人员的时间，这将在以后节省。
编辑： 报表模型向导（像大多数这样的东西）在运行时会变得一团糟。您必须调整设置，例如限制不相关聚合的生成。在过去，我通过生成总和、隐藏所有基本度量并像它们是基本度量一样公开聚合来获得很好的结果。这提供了很像 Business Objects 的行为。在特定情况下，您可能还想公开计数、最小值/最大值或平均值。
我正在考虑的特定实例是一个相当大的报表模型，其中包含大约 1,500 个字段，因此从向导生成的聚合 fest 总共有 10,000 多个字段是无法管理的。您还可以像 Analysis Services 一样设置文件夹结构，并使用这些结构来组织字段。最后，如果在最终用户工具中将鼠标悬停在该字段上，该字段上的描述将显示为工具提示。
【讨论】：
总的来说，“垃圾进垃圾出”这句老话当然适用。如果您的数据不干净，那么 Report Builder 或其他临时报告工具只会让这一点更加明显。
亚伦·迈耶斯【讨论】：