经过多年的关系数据库开发,我目前正在学习OLAP和MDX.
关于MDX入门的任何提示？学习MDX的最佳书籍和资源是什么？
我正在使用Analysis Services,在设计维度时,我无法确定构建自然层次结构还有多远.
我的意思是我添加了所有真正的属性关系.因此,大多数层次结构都是自然的,但最常请求的层次结构是3个或更多级别,中间级别是缓慢变化的属性.
该方案是跟踪工作.该工作有许多属性都是静态的,但债务人属性(即谁支付发票)可以在工作过程中发生变化.所以层次结构看起来像这样
- Manager -> Debtor -> Job Name
- Director -> Debtor -> Job Name
- Office -> Debtor -> Job Name
- Office -> Manager -> Debtor -> Job Name
因此,在维度内,有许多层次结构以作业的静态属性开始,后面是债务人(缓慢变化),底部是作业名称(维度键).
因此,我们目前所做的"自然化"这些层次结构的是为每个债务人创建"假"属性,这些属性出现在层次结构中,该层次结构是其上方的属性的组合.例如,对于上面的第一个示例,Debtor级别属性将具有Manager和Debtor id的密钥.对于最后一个示例,Manager级别将具有Manager和Office的密钥,而Debtor级别属性将具有Office,Manager和Debtor的密钥.然后,我们隐藏所有这些属性,以便它们仅用于层次结构中.
因此,这使我们的维度变得更加复杂,但我们确实在查询中获得了额外性能的好处.这通常是一个显着的进步.除了复杂性之外,我们经常遇到问题,因为我们现在有多个版本的"债务人",而属性的关键不是债务人的身份.因此,如果我们想要更改某些级别的行为,这会影响钻取和报告操作以及使某些类型的计算更加困难.
我们使用的客户端是Reporting Services,Excel和Office Web Components.
有人告诉我,在SQL 2005的早期版本中,涉及非自然层次结构的复杂查询可能会导致服务器完全绑定,这是我们为避免不自然的层次结构而付出很大努力的另一个原因.
此外,感叹号设计警告在Visual Studio中如此引人注目,以至于拥有不自然的层次结构似乎是一件非常糟糕的事情.
在这些情况下,其他设计师会做些什么？你要走多远才能避免不自然的等级制度？
我有兴趣了解一些不同的方法,用于从Analysis Services检索数据,在代码中的对象中使用,或者用于最终用户报告.
我过去使用过两种不同的方法,一种是使用ADOMD来提取结果并将它们放入数据集中,另一种是使用SQL OPENQUERY来链接SSAS服务器以将结果作为SQL存储过程结果集获取.这两者都有优点和缺点.
多年来我在这一行上看到了各种各样的问题,请原谅我任何重复,但是有什么其他方法可以将SSAS数据转换成其他人的代码可以使用它的格式？
我已经考虑过基于HTTP的SSAS的XML结果集,然后是Linq到XML - 任何人都有这方面的经验吗？
理想情况下,我想要一个带有类型列的数据集,或者具有属性的对象,但我对一般方法比对代码示例更感兴趣.除SSRS /其他仪表板控件外,您如何从SSAS获取数据？
什么是MDX语言的最佳参考/链接,备忘单？以下是我收集的一些初学者.请分享你的:)
在Sql Server Management Studio中,一旦我浏览了一个多维数据集,我就可以删除列字段,行字段和过滤字段.这将显示所需的数据.
我想知道是否有办法查看幕后生成的MDX查询以显示数据？
谢谢.
我想创建一个计算成员并按维度过滤它.这是工作示例:
(
[Policy].[Policy Status].&[Void],
[Policy].[Tran Type].&[Renewal],
[Measures].[FK Policy Distinct Count]
)
但是,如果我想像这样过滤它
(
[Policy].[Policy Status].&[Void],
[Policy].[Policy Status].&[Policy],
[Measures].[FK Policy Distinct Count]
)
比它不工作.它表示在元组中多次显示相同的层次结构.
另一件事是,如何排除行？这是个主意......
(
![Policy].[Policy Status].&[Void],
![Policy].[Policy Status].&[Policy],
[Measures].[FK Policy Distinct Count]
)
有没有人试图从R中访问提供XMLA API(如Mondrian)的OLAP服务器？
我喜欢从R对Mondrian运行MDX查询并检索结果集.
我有一个MDX查询与以下计算成员:
with member [Measures].[BBOX] as
Count(
Filter(
CrossJoin([Dim Response].[Response ID].Children, [Dim Question].[Question Text].Children),
[Measures].[Question Bottom Box] > 0
)
)
我的想法是,我想要计算维度的两个成员的组合.(请原谅我,如果我的MDX词汇量有点偏差).它也基于一些标准.
查询的其余部分如下所示:
select
{({[Measures].[TBOX], [Measures].[BBOX]},
[Dim Product].[Category Name].&[Office])} on columns,
{[Dim Question].[Question Text].Members} on rows
from H1_FY10_Revised
where ({[Dim Question].[Category Name].&[Partner]},
{[Dim Subsidiary].[Subsidiary Alias Name].&[Germany]})
我的问题是:主查询中发生的数据切片(where子句)是否转换为计算成员？从计算成员返回的数据与主查询中的轴之间是否存在任何类型的隐式连接？
或另一种表达它的方式:计算成员中的交叉连接是否在主查询的上下文中执行？