【发布时间】：2014-01-18 21:30:44
【问题描述】：
对于这篇文章的冗长，我提前道歉。我不知道什么是重要的，所以我通常写得比需要的多。
一点背景
我有一个半星期的时间来创建一个 POC，以便在面向客户的报告后面使用 OLAP。我们不致力于报告工具，而且我们有大量数据，所以 OLAP 似乎很有意义（？）。现在我们使用 SSRS 2005 来处理一个有些扁平化的报告数据库，但我们有一个新客户要求我们快速变得成熟。
我在 10 年前使用 SSAS - 用它们构建了多维数据集和简单的数据透视表 - 没有 MDX。我精通 SSRS，但反对关系资源。我们没有维度模型，所以我必须模拟一个。我打算在 SSAS 2012 中进行模拟（针对 SQL 2005 DB）。
POC 要求
报告有关医生在多个属性中的表现的信息
尺寸：m>
- 时间（日期/月/年）
- 内科医生
- 医师专业（1:M 与医师）
- 隶属关系 1 > 隶属关系 2 > 隶属关系 3（层次结构，1:M 与医师）
- Registry > HEDIS Measure (hierarchy, M:M with Physician, HEDIS 以下是因为“Measure”得到 令人困惑）
措施（最低粒度是医师/日期/HEDIS - 有时需要钻取患者数据）：
- 患者人群
- 看过的患者（部分患者）
- 分数（这是我们的 KPI - 就诊患者/患者的商百分比 人口）
- 四分位数（基于分数；针对医师、附属机构 1、2 和 3，跨日/月/年的 HEDIS 和专业）
我创建了一个包含所有维度和两个附加度量（患者人数和已见患者）的功能立方体。我去添加分数和四分位数并冻结。现在我处于分析瘫痪模式和恐慌。我不知道 MDX 如此不直观（或者我可能只是密集），而且计算四分位数会是个问题！
所以现在我试图将一些东西与视图和静态表一起放入数据库中。在维度建模方面，我还很初级。我需要设计表格以实现最快、最简单的多维数据集开发和报告周转。它不需要完美，但我还没有看到这样的项目，我希望得到一些关于如何避免在多维数据集和报告开发过程中由于糟糕的数据库设计选择而遇到明显“陷阱”的建议.有人可以给我一个概括的“你会在我的鞋子里做什么”吗？
以下是我的一些问题/疑虑，以精神呕吐的形式出现
所以我有完全加法和非加法的措施，对吗？ （我什至不确定 Score 是什么——我认为它不符合半加法的条件？）。无论如何，我对是否将这些非完全相加指标存储在 Measure Dimension 或多个不同粒度的事实表中感到困惑。
似乎走事实表路线可能不那么令人困惑，但是每个事实表是否都有自己的多维数据集并向下钻取/跨越将通过 Excel 或 SSRS 中的某种链接来完成？例如，您正在查看按年度 HEDIS 四分位数划分的 YTD 医师分数……如果它们在不同的立方体中，您如何按每月 HEDIS 四分位数深入查看 MTD 医师分数？或者他们可能会在不同度量组的同一个多维数据集中......？或者，如果我使用 Measure Dimension 并使用单个多维数据集，我如何保护用户免受上述情况的影响……他们正在按年度 HEDIS 四分位数查看 YTD 医师分数，然后将年度 HEDIS 四分位数替换为每月 HEDIS 四分位数- 这样的事情是怎么阻止的？或者这种情况是否合法？
我很想把它扔到 SSRS 中，在那里我可以通过参数控制事物，但是对于 OLAP 源来说这样的难度有多大？更不用说交互式图表了？
我现在很困惑，我什至不知道这些问题是否有意义。任何帮助（甚至是您认为有用的简洁文档的链接）都会很棒！
【问题讨论】：
-
如果它真的是 POC，那么你不应该太担心设计，将其用作学习过程并展示最好的部分......除非它是伪装成 POC 的真正工作，因为他们不想付钱。您需要与利益相关者确定后端设计不会保持这种状态，因为它只是一个 POC。实际上，有时您必须在多维数据集中做一些看起来很疯狂的事情，以便您可以根据它构建报告，因为实际上，很多业务还不够成熟，无法使用多维数据集。
-
...重申 POC 意味着证明它可以做到，而不是构建和设计它。您无法在一周内构建和设计完美的东西。如果您与预售中的任何人交谈，您就会知道这一切都只是虚无缥缈。
-
谢谢，我知道你是对的。你理性的声音很有帮助。
标签： sql-server database-design reporting-services ssas data-warehouse