SSAS 在处理成 Cube 之前编译数据
从头开始从事我的第一个 SSAS 项目，希望得到一些指导。 我见过将数据放入多维数据集的不同方法，并且想知道哪种方法是首选（如果有的话）。
我所经历的大多数示例都只是指向特定数据库中的表/模式（例如 7 或 8 个特定销售相关表），定义度量和维度，并基于这些进行处理。然而，我也看到一些生产系统运行一个或多个 SP，将 7 或 8 个销售相关表中的数据编译成一两个更接近所需事实表的数据。那么立方体数据视图就是基于这些的。
是否有推荐的特定方法等？
提前致谢。
Working on my first SSAS project from scratch and hoping for some guidance.
I have seen different approaches to bringing data into a cube and wondering which is the preferred if any.
Most of the examples i go through simply point to the tables/schemas (say 7 or 8 particular sales related tables) in a particular database, define measures and dimensions, and process based on those. However i have also seen some production systems that run one or more SP to compile the data from the 7 or 8 sales related tables tables into one or two that match closer to the required Fact tables. Then the cube data views are based on these.
Is there a particular approach that is recommended etc?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，我们有某种使用 sp-s 或 SSIS 构建的 ETL（提取、转换、加载）流程，该流程从源读取、进行操作，然后将数据写入专用的数据集市星型模式。
这种方法有很多优点，唯一的缺点是与之相关的精力、时间和成本。例如，您可以处理 ETL 中的数据质量问题，分配适当的代理维度键（例如 int 键）并对 M2M 关系等进行建模。
话虽如此，我也看到许多商店在其规范化之上构建多维数据集架构。您可以按照您提到的方式执行此操作 - 通过在 SSAS 中使用多个表，或者通过构建视图，将所有内容混合在星型架构中，然后在 DSV 中使用这些视图，随后在 SSAS 中使用这些视图。我通常会推荐这种方法用于概念验证项目，或者用于实际上不需要构建自己的模式的事物，因为规范化表已经具有合适格式的数据。
如果您正在构建合适的 SSAS 解决方案并且您有时间和技能来做到这一点 - 您绝对应该采用第一种方法。但是，如果这些因素有些不确定，而您只是尝试一下、摆弄一下等等，那么您可以从视图开始，然后用适当的模式替换它们。这样您就可以学习如何做到这一点，而无需维护复杂的 ETL（即您更加灵活）。请记住，SSAS 确实更喜欢某种格式的数据，并且仅构建视图或使用直表会在一定程度上限制您 - 当您觉得需要时，您应该创建自己的架构。
Typically we have some sort of an ETL (Extract, Transform, Load) process built either with sp-s, or in SSIS, which reads from the source, does manipulations and then writes the data in a dedicated datamart star-like schema.
There are advantages to this approach and the only disadvantage is the effort, time and cost associated with it. For example, you can take care of data quality issues in the ETL, assign proper surrogate dimension keys (e.g. int keys) and model things like M2M relationships, etc.
Having said that, I also see many shops building cubes on top of their normalised schema. You can do this either as you mentioned - by using multiple tables in SSAS, or by building views, which mash up everything in a star-like schema and then use those views in the DSV and subsequently in SSAS. I would typically recommend this approach for proof of concept projects, or for things which really do not require their own schema to build as the normalised tables already have the data in a suitable format.
If you are building a proper SSAS solution and you have the time and skills to do it - you should definitely go for the first approach. However, if these factors are somewhat uncertain and you are just trying it out, playing with it, etc - you can start with views and later on replace them with a proper schema. This way you can learn how to do it without having to maintain a complex ETL (i.e. you are more flexible). Keep in mind that SSAS does prefer the data in a certain format and just building views, or using straight tables constrain you somewhat - when you feel the need you should create your own schema.