星型架构:客户机和非客户机的独立维度,还是服务人员的共享维度?

不需要将客户机拆分为两个表(维度)。只需将所有客户机、活动客户机和潜在客户机放在同一维度表中。 然后可以引入IsActive属性(列)来区分付费客户和潜在客户。迟早你会使用数据挖掘工具来了解更多关于客户的信息,以及愿意为你的服务付费的人和不愿意付费的人之间的区别。为了使算法能够工作,您必须为两组人提供数据——付费的人和不付费的人。总而言之,潜在客户和付费客户属于同一张表。

有了这个,你就可以使用你的1号模型了。确保事实表中的度量是有意义的。例如,如果一个电话\u id=123有10个人参与,那么

sum(cost_of_connection)
from factAudience
where call_id = 123;

应该返回通话的总费用,而不是毫无意义的东西——比如实际费用的10倍。

编辑

“付费客户机”和“潜在客户机”都是客户机的一种类型,因此属于同一维度表——dimClient。在DW的某个地方有一个factSale(或类似的)与FK到dimSale。即使您在dimClient中没有一个列来区分paying和prospect,您仍然可以通过加入factSale和dimClient来获得paying客户。

在组织中引入数据仓库时,“谁是客户?”是一个常见的争论。 为了能够分析客户的获取、保留、转换等,潜在客户与付费客户有着相同的待遇——至少在数据仓库中是这样。请记住,收购和创造新客户是(几乎)任何首席执行官的首要任务。

我要说第二个:它在他们自己的、专门的维度中为与会者建模,同时允许您通过该维度中的属性暴露他们的客户特性(或其他特性),这可能是您在现实生活中希望深入了解的方式(“向我显示所有与会者”,然后是“现在哪些是客户”)。

在您的客户机维度中,我将填充所有与会者的客户机id,匹配到“未知”元素,其中与会者不是客户机。

这里有一个很好的讨论:

http://crpit.com/confpapers/CRPITV75Riazati.pdf

没什么区别。第二个版本可能更正确,但是您的olap系统支持这个吗?

第二个在我看来像“雪花模式”。从维基百科的文章开始研究雪花模式。你会看到星星和雪花之间的一些比较。