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