关于维度划分的问题！一个还是多个？

[zhukejun]

请问这种情况是一个维度好，还是分开好，分开的话怎么分？
先谢过了！

17910不可漫游A卡
17910可漫游A卡
17910不可漫游B卡
17910可漫游B卡
17910 C卡
17911不可漫游A卡
17911可漫游A卡
17911不可漫游B卡
17911可漫游B卡
17911 C卡
其他IP卡
GSM准预付费充值卡
GSM智能预付费充值卡
CDMA智能预付费充值卡
165上网卡
193300卡
其他193业务卡

[zhukejun]

我可以做3张维表：17910 漫游 A
17911 非漫游 B
C

可是有些室不分的！

GSM准预付费充值卡
GSM智能预付费充值卡
CDMA智能预付费充值卡
165上网卡
193300卡
其他193业务卡

这样统计的时候怎么统计，就是维表的关联就比较复杂

[zhukejun]

或者这样？

ID NAME LEVEL
1 IP卡 1
2 17910 2
3 17910漫游 3
4 17910漫游A卡 4
5 17910非漫游 3
6 17910漫游B卡 4
......
18 193业务卡 1
19 193300卡 2
20 其他193业务卡 2
......

[zhukejun]

应该是这样！请大家提题意见，不知能不能解决所有需要统计的组合

ID NAME LEVEL P1ID P2ID P3ID
1 IP卡 1 NA NA NA
2 17910 2 1 NA NA
3 17910漫游 3 1 2 NA
4 17910漫游A卡 4 1 2 3
5 17910非漫游 3 1 2 NA
6 17910非漫游A卡4 1 2 5
......
18 193业务卡 1 NA NA NA
19 193300卡 2 18 NA NA
20 其他193业务卡 2 18 19 NA
......

[clhy95412]

我看你还是在OLAP查询工具所要求的维表结构的条件下来建立你的维表。
如果你的ROLAP是metacube的话，利用level字段就可以。
如果你的OLAP是Essbase的话，利用Parent和Child模式建立就可以。

[zhukejun]

两层用parent&child没有问题，多层怎么用？

[newskysh]

问一下你的事实数据是怎样的结构？围绕事实数据来设计维度是比较的设计思想！

[yongwc]

父子维可以有很多层的，不是两层

[zhukejun]

父子维怎么做成多层的？
找自身的DADDY吗？
sid sname pid ？

[zhukejun]

大家只是提意见，都没有正面回答一个解决方案吗！

[newskysh]

你自己不说清楚，谁能帮你回答一个解决方案？

[zhukejun]

事实表是统计各类卡的销售情况

[atigerqigh]

你单问一个维，别人怎么知道，
再说了，要分析多细？还有些什么维，如果就只有这些数据的话，分开得了，如果还有其他维的话，考虑不要在一个多维分析中建立过多的维，你可以把他们和起来，一切都是需要看需求的，没有一定的规律

[clhy95412]

多层用PARNT和CHILD一样能解决。

[given]

没错，如果单单是问一个维表的结构如果构建别人是比较难回答的。

最好针对事实表来做维表，而且维表的层次结构也需要和需求挂钩

父子维多层的用法
parent_id child_id name
1 2 爷爷
2 3 爸爸
3 4 儿子

如果要在sql analysis展示的话
是这样的格式爷爷
|_爸爸
|_儿子

[given]

如果不是父子维，但是有结构的话，都秉承

门类-〉大类-〉小类-〉小类代码（和事实表关联用）（星型结构）

当然还有雪花结构，这就看需求的情况

[xhfjy]

父子维的看SQL SERVER的例子就有了

[statement]

同意clhy95412(clhy95412)的看法。
不过我觉得你真的要定义维度的话，你大可不必定义的那么细。可以把分类项放到level上处理。维度的话，你完全可以根据你的卡的性质，例如是根据销售对象分的，这样定义一个维，然后分level就差不多了。
结构的话，实际上星型结构就可以了。

[zhukejun]

那在事实表中已经做好聚合，还是统计分析时做动态做聚合？
大家平时怎么解决？统计一下

[given]

事实表中最好是明细数据，这样的好处是，如果需要从统计的数据察看明晰的数据的需求时，你所设计的事实表就能够满足需求，而不需要在重新构建事实表。同时你保留明细数据不会对多维数据库的聚合产生影响。

[given]

一般来说，星型结构是可以满足一般的需求，但是在实际应用中，这种结构远远不能满足的。