Babituo
20060413
刚刚从TTNN的OLAP主题http://ttnn.c3crm.com/index.php?title=OLAP学习回来,看到了几个概念,联系起来理解了一番,不知是否准确,还请各位前辈指点.
1.OLAP的核心就是"事实"
2.对于一个"事实"我们可以从"多个不同的正交的角度"来观测,每个角度就是一个"维度";
3.在每个角度上,我们可以采用不同"焦距"的"放大镜"或"望远镜"来观测这些事实,这就是为度的"分级";
4.如果在每个维度上只采用1种"焦距",就只能看到一层的事实,这就是"星型模式";
5.如果还是"星型模式"中看到的那些事实,但每个维度都采用了多套的"焦距",则形成"雪花模式";
6.在小焦距上看到的(放大到最大)事实,组织起来就是"事实表";
7.在"雪花模式"中稍远一些焦距上看到的事实,组织起来就是"聚集表";
8.在雪花模式上调整焦距看事实,就会看到很多层次的"聚集表"
9.把焦距从远到近调整,从最顶层的"聚集表"往最低层的"聚集表"查看的操作就是"钻取";
我的理解对吗?
还有什么重要的概念漏掉了吗?
刘庆
20060413
很有意思的比喻，看来邱兄十分善于用类比来理解问题。
对于第四点"星型模式"的描述，似乎不是那样回事。一个星型模式中的事实表，当然只是体现每个参与维度的一个级别（也就是一种焦距），这多个特定级别的维度也就确定了事实表的"粒度"，一般来说，这些维度字段也就构成了该事实表的主键。
例如一个事实表有以下字段（月份、县、销售量、计划销售量），那么日期维的月级别、地区维的县级别确定了该事实表的粒度。
但这只能说"星型模式是在每个维度上采取一种焦距，只看一层事实"，反过来却不是，应为雪花模式也是如此。
雪花模式和星型模式的区别主要就在维度表的构造上面，星型模式的维表有冗余，而雪花模式去掉这种冗余。但事实表跟是否雪花模式或星型模式不相干的，聚集表也跟是星星、雪花不相干，聚集表本身也是一种事实表。所以对于第7、8点，值得商榷。
其实，星型模式、雪花模式、聚集表这些名词主要出现在ROLAP环境中，星型、雪花模式能够让ROLAP能够维护维度、度量等元数据，而聚集表是为了能够让ROLAP引擎作聚集导航，提高查询性能用的。
而维度、度量、分级等都可以算是OLAP本身的概念，跟ROLAP或是MOLAP无关的。除了这些还有一些概念，诸如钻取体系、维度不平衡等。
最后还有个一点是要请教邱兄的。
对于第2点，"多个不同的正交的角度"，其中"正交"的确切含义。在软件架构中，经常可以看到这个词，也是困惑我多年的词。这个词的真正定义是什么？
从这个词语的本义看，有"垂直"的意思。但结合一般语境来理解，这个词反而应当是"不相交"的意思，是"平行"。比如说"正交的角度"，我想邱兄的意思就是说这些维度之间各自独立，相互不会有依赖（当然通常并非如此，很多维度是有依赖关系的）。再比如事物的分类，说这五种分类"正交"，可能是指一种事物归属了其中一种分类之后，不会再归属于其他分类了。软件架构中的正交设计，也是这种"不相交"的语义，要保持模块的独立性，相互之间不会互相调用。
因此，我非常奇怪，为什么要用"正交"这个词呢？谁第一个用它？它的本义或者延伸涵义是什么呢？
Babituo
20060414
多谢庆哥解答，可能是类比手法太模糊了，我觉得庆哥的解答和我理解的基本一致，但庆哥说有不同，索性再展开一层举例说明，庆哥有空帮我看看。真还有不同的话，我就要找这个概念深挖下去了。
1.OLAP的核心就是"事实" ————比如“销售额”
2.对于一个"事实"我们可以从"多个不同的正交的角度"来观测,每个角度就是一个"维度";——比如时间维，地
点维，就是从时间和地点两个不同的正交角度来看。
顺便给出我对正交的理解：
“正交”直接字面理解是“垂直相交”的含义，“垂直相交”用在几何上很好理解的（删除了一大段罗嗦的解释）。
用在语义关系方面怎么理解呢？
可以对应立体几何上用正交坐标系来描述空间点的做法来类比理解，描述一个事实，比方说“销售额”，我们暂时用了2条轴：时间和地点，也就建立了一个用来摆放销售额事实的平面，为什么说这两个轴是正交的呢？因为时间和地点是两个完全不同的概念，也就是说，说出一个时间，我们不会想到这个时间会对应哪个确定的地点，要想，也会想到所有的地点都会有这个时间，说出一个地点，我们也不会想到这个地点会对应哪个确定的时间，要想，也会想到自始致终，在所有的时间上都是这个地点。所以说，时间和地点作为用来描述事实的坐标轴，它们是正交的。用正交的好处，就是可以用最少的坐标信息了确定一个点的位置。
我理解刘庆为什么会把“正交”和“平行”，“无关”的概念联想起来，原因其实很简单，假设我们把时间、地点看作是同一种东西，这个东西就会叫做“元”，如果我们把所有的“元”这种东西又放到一个空间中去进行定位，比如现在的“时间”和“地点”两个元就可以放到一个“描述销售额用到的元”这条“数轴”上，就是两个不同的“点”，也就是说，这些元之间是无关的，也就是平行的，比如“时间”和“地点”在“描述元的空间”中是平行的。但是，他们在“事实空间”中是垂直相交的两条轴。
假设我们在元空间中选择的是相关的、也就是不平行的概念线来描述事实，又会怎么样呢？比如说，我们取所有的“时间”和所有的“交易”各为一条轴，那么，我们得到的事实空间就不会是一个正交描述的空间，因为“交易”这个轴本身就包含了“时间”的约束，这会导致事实空间上会出现很多不可能存在的点，比如：求"和某个时间、某次交易对应"的销售额事实有可能是荒唐的，因为，那次交易有可能根本就不是在那个时间进行的。由此可见，用正交坐标系描述空间的效率是最高的。如果你找到了一个事实的正交描述，你就找到了这种事实的本质描述，否则，就不是最简约的描述，就没有达到本质。
也许你会说，照我这样说，“时间”和“地点”也是不正交的，因为也不是所有的取某个时间和某个地点的交叉点上都会有“销售额”事实发生。那么，我就要提醒一下：区别在于“可能”还是“不可能”，如果存在永远“不可能”发生销售的地点，那么，这个“刻度”就不会出现在地点的“数轴”上。对于没有发生销售额的点，我们可以认为那个空间点是存在的，在那个点上是可能发生销售额的，只是实际没有发生，或发生的为0。
这和哪个点是不存在的，但坐标轴又能标出那个点来是不同的。
3.在每个角度上,我们可以采用不同"焦距"的"放大镜"或"望远镜"来观测这些事实,这就是维度的"分级";——比如：时间焦距：季度，月，周，日。地点焦距：全国，全省，全市，全县，全区。
4.如果在每个维度上只采用1种"焦距",就只能看到一层的事实,这就是"星型模式";——比如：在时间轴上，我们只有“日”这一个“焦距”，在地点轴上，我们只有“全区”这个一个“焦距”，（假设我们不知道有其他焦距存在，或根本就不让我们用），那么，我们看到的事实，就是各区在每天的销售额是多少这些事实。这些事实和我们的两个维，形成一个“两角星”的模样。
5.如果还是"星型模式"中看到的那些事实,但每个维度都采用了多套的"焦距",则形成"雪花模式";——比如：还是以上“各区在每天的销售额是多少”这些事实，现在，让我们能够自由地选择时间轴和地点轴上的“焦距”了，也就是在时间轴上，我们可以看到每一个年都包含它的四个季度，每一个季度都包含它的三个月，每个月...,于是，时间轴变成了一棵树，或一把可以分多级展开和收拢的伞的形状，也就是雪花的一片叶子的形状。同样，地点也类似，于是，以“各区在每天的销售额是多少这些事实”为中心，以时间和地点两片展开的雪片叶，就形成了一个两片雪叶的雪花模样。
6.在小焦距上看到的(放大到最大)事实,组织起来就是"事实表";——比如，上面4中的比如，就是放大到最大看到的事实。假设我们以为“周”是最小的时间焦距，“县”是最小的地点焦距，我们更本就不知道还有更小的时间和地点单位，那么，我们看到的最细是事实就只能是“各县在各周发生的销售额是多少”这些事实，这些事实，也构成一个事实表。
7.在"雪花模式"中稍远一些焦距上看到的事实,组织起来就是"聚集表";——比如，上面6中的比如中，因为现在我们有“雪花”的叶子作为维了，而不是简单的一个“角”了，所以，我们可以把焦距自由地调来调去。我们知道，当调到远一些的时候，看到的“事实表”实际上是由更地层的“事实表”分类汇总上来的，为了不至于在我们调到某个焦距时，临时汇总给我们看，那样我们可能要等很长时间，可能就不想看了，所以，就实际做出这个“事实表”来，事先就把聚集的汇总计算好等着，这个事先做好的计算得到的“事实表”就是“聚集表”。也就是说“聚集表”在形式上和“事实表”没什么两样。如果仅仅把这种形式称为“事实表”的话，则可以说：事实表有不同的“粒度”，我们并不大在乎中间粒度和最小粒度的区别，两种说法的含义完全相同，只是用意稍有不同的侧重。
8.在雪花模式上调整焦距看事实,就会看到很多层次的"聚集表"——比如7中的比如。
9.把焦距从远到近调整,从最顶层的"聚集表"往最低层的"聚集表"查看的操作就是"钻取";——既然这种操作叫做"钻取"，那么，"钻取体系"不就是让这种操作成为可能的“雪花叶片似的维”，以及按这些维准备好的一系列“聚集表”和“事实表”吗？如果只是一个“星”，还能往下“钻”吗？如果要往下“钻”,不是一点要有“雪花叶片似的维”吗？
10.维度不平衡：没查到，估计是个比较高深的概念了，是指“维本身”发展的不平衡（比如动物分类，有的分类分几下就分不下去了，有的可以总往下分，有的只需要一条线分下去，有的分很多枝，每枝又有不同的分法）还是事实的分布按维产生的不平衡性呢？
刘庆
20060414
不知道在星型模式和雪花模式上是否理解一致，就这个类比来说，好像是让这个概念更加复杂了。可能用数据库语言来表示会更直接一些。
星型模式和雪花模式的主要区别在于维表的构造，比如一个日期维度，有日、周、月、年四个级别。当星型模式时，有一个日期维表，其结构为：
（日ID、日描述、周ID、周描述、月ID、月描述、年ID、年描述）
每个级别由一个ID来标识，其描述字段还可以更多一些，称为"属性"，例如针对月ID，还可以有"年中月描述"，对于日级别，还可以有"是否节假日"等属性。显然，这是一种不符合第三范式的设计，主键是日ID，可周描述、月描述这些字段并不是依赖这个主键的。而雪花模式则按照第三范式来设计，会分成四个维表。
日期维表：（日ID、周ID、月ID、日描述、是否节假日）
周维表：（周ID、年ID、周描述）
月维表：（月ID、年ID、月描述）
年维表：（年ID、年描述）
常见的都是星型模式，很少见到雪花模式，虽然在设计上，他后者更加符合范式。
从上面的举例，可以看出所谓星型或是雪花，都是在于ER模型的区别，都是在ROLAP下谈论的。无论从星型或是雪花，都可以汇总出聚集表，聚集表这个概念在MOLAP下是没有的。
而钻取体系，说是用户钻取的路径，可以是上下钻取，粗粒度到细粒度查看数据，是下钻（DrillDown）；从细粒度再看粗粒度的，叫上钻（DrillUp）。还有一种钻透（DrillThrough）的说法，这是某些产品支持的，大意是从统计数据，钻取到明细数据，例如从某日某区域新客户为13个，钻透可以直接查看这13条客户记录。另外还有什么交叉钻的，CrossDrill，却不理解其含义。
在一个维上钻下钻，就是查看不同粒度的数据，但路径可以有所不同。例如上面提到的日期维，就可以分成从(日->月->年)和(日->周->年)两条路径，而周和月之间没有路径。这就叫作钻取体系，Hierarchy。当然，可能还会有别的叫法，毕竟在OLAP领域，目前没有权威的中文概念，除了维度、度量是普遍接受的中文名称。
至于维度不平衡，确实如邱兄所言。如果我们将维度看作一颗分类树，从根节点到叶子节点的深度不同。例如部门维吧，有的分公司可能有四级部门，有的可能只有三级。这就是一个不平衡的维，一般来说，解决此类方法，最简单的就是按照最大深度的那个分支设定维的级别数目，再如部门维的例子，如果最多级别就是四级部门，市、县、区域、组，那么对于那些只有市、区域、组三级结构的，硬在"市"和"区域"之间塞一个"县"级别，让他的取值和区域一样就得了。
当然，有些产品对于这个问题有独特的解决方法，一般都会考虑。不过现在使用上面这种简便方法，也已经足矣，只是在用户钻取的时候，有些奇怪，怎么钻下去还是一样的结果呢？
Babituo 20060417
刚刚看到一篇文章谈星雪问题.
http://www-128.ibm.com/developerworks/cn/rational/r-warehouses/
感觉根据文章所说,以及ttnn上说的,仍然从表面上看不出所得到我上面的类比理解有什么问题.
庆哥上面谈到了一些细节的信息,可以说明我上面的类比理解是不准确的,准确理解是否如下:
作为星星的维,其实也是可以有多层次分级的,只不过它是将每级的ID放在同一个维表中,并且每级的ID都和事实表中的事实建立外键的关联?,也就是说,和事实关联的多个外键,可能是针对同一维的,这样一来外键的索引层次虽然变成只有一层,但有多个,所以逻辑上仍然是多级的.
作为雪花的维,就比星星的维规范多了,先把该属于同一个维的多级ID用一个基本维表和多个分级的维表关联,再用这个基本维表的一个ID为代表和事实表建立外键关联,这样,从事实表来看,一个维就只有一个外键,维的事,交给维自己去解决，于是就出现一个维上多层索引的外键。
所以,不管是雪花还是星星,逻辑上是一样的,都是同时可以实现多级的多个维来管理事实的.只是他们的技术处理不一样而已。我之前理解星星只能处理固定的一级的维，是错误的。
回过头来看我的类比，
“星星”的一个维，只不过是用分别固定为不同焦距的多个镜片"同时一起"观测事实,(之前的理解缺"同时一起"这个关键)
“雪花”的一个维，则是用一部可以灵活调整多个焦距的一个镜片来观测罢了。
类比并不会把事情搞复杂，而是象我这样的初学者容易把事情想成可以想成的不一样的结果而已。
再有，不知道我的“正交”理解是否准确？
刘庆 20060417
再来谈谈正交。
如果用坐标系来说明正交的含义，是比较清晰的。但如果要说在OLAP分析中，"对于一个"事实"我们可以从"多个不同的正交的角度"来观测,每个角度就是一个"维度""，这句话就有些不妥了。用正交的角度去观测事实，那是理想不过的，但那些维度必定是不正交的，至少目前无法那样。
考虑的极端一些，所有维度不正交，于是形成一个维度——"发生的事"。横坐标就是这个维度，纵坐标是度量值。其实这就可以想象成一个关系型的事实表，表中有多少记录数，这个横坐标上就有多少坐标点。对每个坐标值的描述，可能就是"2005年6月某地某产品的销售量"，其中"2005年6月某地某产品"就是这唯一维度的维成员。这当然不是正交。因此可以将这个维度拆成三个正交的维度，月份、区域和产品维。他们互相之间没有依赖关系。
看，那么事实表的结构也能够体现这点。一般事实表可以用（维ID1、维ID2、维ID3、度量1、度量2）的结构来表示，其中三个维为该表的主键。如果维度是正交的，这三个维ID相互之间没有依赖关系，这张表是遵循第三范式的。如果有一个维其实是依赖另一个维的，例如一个地区维和一个营销案维，营销案只能在某个地区发生，对地区有依赖。显然这就不遵循第三范式。那么可不可以将地区维去掉，直接从营销案维中上钻到地区不就行了？这可能涉及到统计口径的问题，而且，有些营销案可能确实还是所有地区共用的。
姑且先不谈统计口径的问题，为这个事实表再加上一个维度，营业厅维。显然一个营业厅肯定是在某个地区的，它也是依赖地区。如此，即使在这个维表中去掉地区维。营销案维和营业厅维也是不正交的，必定存在某个营业厅不承担某种营销案的情况。对此，如何将这些维度正交化？
故此，我认为正交的的维度是一种理想化的。维度应该是从业务上面考虑观察事实的角度。它更应该贴近业务上的分类，例如对于产品，可以是按照地区划分类别，也可以按照产品类型或者目标客户群来划分。不过现在通常的做法是从数据得到维度，将某一个代码表转换成维表了事。
不过将正交的维度找出来到也是好事，至少想到一个用处，可以估计这个事实表，或者cube的数据量吧。理论上，事实表的记录条数和cube的单元格格数略等于这些正交维度维元素数目的乘积。
Babituo 20060417
明白了，正交是太理想化了。
是的，
科学是讲究正交的，现实是不科学的。
我们是为现实服务的，不是为科学服务的，
用科学为现实服务，还有很长的路要走啊。
下面试着用“正交”的办法来解决一下“营¬销案维和营业厅维也不正交”的问题。
事实是“销售量”
客户需求是：“求某营销案中某营业厅的销售量”
我们当然不能说客户不能有这样的“非正交”的需求，但，面对这样“非正交”的需求，我们就一定必须用“非正交”的数据解决方案吗？我怀疑不一定，下面试着分析下，和庆哥探讨。
先分析“营销案”是什么？
根据本例子简单推测，营销案应该是：某时间段，在某某地区的某某某营业厅，应该取得多少销售量。
可见，营销案中包含的时间是和营业厅“正交”的，“地区和营业厅”和“营业厅”是“包含”的。
假设“营业厅”是地点的最小单位，那么，“营业厅”就是地点维中的最小单位级别，仍代表地点。
假设营销案中包含的时间是一天为时间单位的，那么，每一个“营销案”实际上就是一些时间单位和地点单位的聚集关联。n个营销案就是n个这种聚集的关联。
我们可不可以只建立关于时间（天）和地点（营业厅）和销售额表呢？
然后我们再建立关于时间（天）和地点（营业厅）的营销案表呢？
如果要我设计数据库，我会设计成这样，数据仓库的设计可能和数据库不同。
刘庆 20060417
哦，我这里可能没有将营销案说明，抱歉。
我提到的营销案其实跟时间和营业厅没有多大关系，而是营销政策，譬如一种优惠套餐"打300送300"，或者是一种鼓励客户入网的策略，如"预存1000送手机"，其实他们跟资费有关系。
当然，如果从严格意义上来说，按照邱兄上面的分析思路，它们跟地区也没有多大关系的，每个地市都同样可以有"预存1000送手机"营销案，从概念上和地区是正交的。但在电信业务中，营销案或者简单地称为套餐，已经是一种比较特定的业务对象，在生产系统中，不会严格地、正交地设计业务模型。我认为这是合理的，虽然正交的模型，能够让模型更加灵活、紧凑，可给应用、统计、维护以及扩展带来很多麻烦。所以，即使每个地市都有"轻松听"套餐，也需要每个地市都有其自己的"轻松听"营销案。
而到了数据仓库，同样也不可能再将这种依赖关系掰开。故此，营销案维度和营业厅维度总是依赖地区。哈，人们对现实事物认识总是混乱的。
Babituo 20060417
哈哈,对电信业务不了解,让我闹笑话了.
多谢庆哥解释.
其实,结合具体案例学习BI可能会更有收获.
我现在确实有这么个具体案例,说具体,也还是比较抽象.
我在设想做一个事件管理的软件系统,
事件,就是我们日常工作生活中常发生的一种事实:某个时刻,某个地点,某些个事物,发生了某个变化.
在这里,变化是"事实",时间,地点,事物是"维",可以这样理解吗?,
准确地说,事物还可以分成"事"和"物".
这样就成了"时间\地点\物件\事情"这四维描述的"变化"事实了.
我认为"地点"维对一个简化的事件管理系统来说,不怎么重要,
物件就是通常所说的"资源"或"对象"
事情就是通常所说的"活动"
所以,就简化为"活动\资源\时间"这三维描述的"变化"事实
这就是一个最简单的"事件模型"系统.
显然,"活动"维和"时间"及"资源"维是不正交的,因为活动本身就是一些资源在一段时间上被重整.
如果用数据仓库来管理事件?这样的设计是可行的罗?
刘庆 20060417
关于这个例子，我也曾经考虑过，参见《主体、客体、事件、地点》。
当然，那里并非从数据仓库建模的角度去考虑这个问题，仅仅从概念建模出发。没有将时间单独拿出来考虑，文中也提到原因，因为实在难以将他想象成一个业务对象。
多了一个"地点"的概念，邱兄认为对于简化的系统来说没有必要单独出来一个概念，这点我也统一。其实，我也觉得将他作为一个独立的概念有些牵强，可能只是对于庞大复杂的系统有用吧。
如果是进行数据仓库建模，我想就需要对这个业务模型进行变换一下，将概念模型中没有什么冗余的结构变换成面向主题的结构。这说得有些抽象。
其实所谓主题就是这些"概念"，譬如说"事件"、"资源"或者某种"主体"。针对这些主题，分别从不同角度去观测其事实。事件有发生的事实，必定有发起的主体和影响的客体，因此也就可以从主体、客体的属性来观测事件的事实，这些事实一般包括发生的次数、持续的时间等。而主体，有存在和参与事件的事实，那么可以从其本身的属性去观测，例如主体的类型、年龄等，也可以从其参与事实的角度考虑，例如参与的次数（分段）、发起事件的类型等观测。
因此，对于邱兄提到的事件管理系统，如果作为数据仓库设计，那么就会有"活动"主题，"资源"主题，当然，这些主题肯定得细分，例如事件，可以细分为"乘车"主题、"打球"主题，毕竟他们涉及到的主体、客体相差挺大。但乘车和坐船又可以合成一个主题，唤做"交通"主题。
不过有个特点确实挺有意思，无论这些主题如何划分，时间和地点这两个维度终归都是其中两个重要维度。
Unlock 20060417
对于有相互依赖关系的维度的设计，想请教一下刘庆在具体的设计中是如何做的。
就这个营销案来说，是把将营销维度与营业厅维度分开，地区作为一个层次存在营业厅维度中。还是有其它的设计方法。如果把营销维度与营业厅维度分开的话，如果用MOLAP来做数据集市的话，感觉会浪费很多空间。
最近做的一个数据仓库项目中就遇到这种情况，是第一次做数据仓库项目，设计的时候就把有依赖关系的维度分开了，考虑到有很多空间浪费了，感觉很便扭，所以想请教一下刘庆有没有什么好的方法解决这个问题。
刘庆 20060418
谈到具体的MOLAP如何处理这种相互有依赖关系的维度，我也只能谈谈想法，毕竟没有做过MOLAP的维度设计。
但一般MOLAP工具会考虑这个问题，例如考虑维度是稠密还是稀疏的，这是尽量避免存在那种空单元格的存在，但我不能确定稠密维和稀疏维的界定标准。例如此处，营销案维和营业厅维，如果从发生的事实考虑，几乎每个营业厅都会有数据，但营销案却并非如此，可能有的营销案已经作废，另外还有某个地区的营销案不会和另一个地区的营业厅联系在一起。因此，如果将营销案作为稀疏维可能是一种选择。
在存储方面，稠密维是按照类似多维数组的方式存储的，因为这些维度的交叉点大多存在度量值，因此浪费的空间少。而稀疏维是索引式的，类似关系表的存储。因为他和其他维存在"不可能存在"的度量，因此用这种方式可以避免为这些度量值提供存储。
多维数据库确实存在"数据爆炸"的现象，也是众多MOLAP厂商需要面对的问题，但我想作OLAP设计时候的考虑，是访问性能、存储空间和用户分析需求的平衡。如果营销案和营业厅确实有需要结合在一起分析的，却因为空间过于浪费的原因而分开他们，恐怕也不好。
如果有对MOLAP解决这个问题有好方法的，欢迎来探讨。
Babituo 20060418
太有意思了
想不到庆哥也想过这个问题,而且我们的概念模型是多么的相似.
不由得联想到了历史上的"地心说"和"日心说"之争.
有时觉得概念的世界和现实世界一样,是一个相对运动的世界.
但我们总有一种"寻找心"的情节.
从最简化的概念模型出发,假设我们的世界就是这么一个抽象得干干净净的世界,只有"时\地\体\变"这四种东西,剩下的就是他们的关联了,不再有别的东西了,那么,在这个关联网络中,谁应该是"心"呢?
注解:
时:时间;地:地点(空间);体:物体(主体,客体);变:变化(运动);
为什么我们总要找心?因为擒贼要先擒王.
我想,OLAP中的主题,就是心,为维就是其周边的背景事物.
所以,在完成最抽象的概念模型处理前,我觉得还是先不做"主题涣散"为好.
我想,作为"心",必须满足的基本特征条件是:它与所有其他事物的关联最多.无疑,把"变化"作为"心"符合这条原则.
其实,"活动"本身就是变化,连续的变化,不停地发生事件,只是我们把一系列看来可以重复发生的变化序列命名为一种活动类型罢了.所以,这种命名规范也可以成为一个维,和其他维不一样,这个维来自主观意识.
我想进一步请教庆哥,如果我就只想这样来管理这么一个纯粹的概念模型,用什么开发环境好?最少需要用到哪些BI的资源?
刘庆 20060418
呵呵，我看到后面关于"心"的描述，差点理解成为"人心"了，思想走入另外一条路，想着邱兄说得是"如何从人的观念中得到这个世界的模型"。这是在谈"认识"，可结合上面的地心说和日心说，我理解邱兄所言之"心"为"核心"、"本质"，原来是在谈"本体"。
将"变化"作为"心"，想起了一句话——"唯一不变的就是变化"。
确实，从我们关注的企业业务环境中来说，所提到的用户、营销政策等概念，之所以将他们提出来，是因为有事件的产生。客户和企业建立产品服务关系形成用户，企业制定营销政策，用户使用产品服务等等，真是因为这些活动，才将参与活动的主体、客体抽象出来。而对于活动中不直接关联的，可以不抽象。例如"人"这个对象，虽然有具体的人参与企业活动，但他是作为"客户"出现在活动中，而非"人"，因此，没有必要为"人"建模。但如果你要是为社会建模，你就需要抽象出"人"这个对象，因为有诸如"男人和女人组件家庭"这种活动。
不过如果问，"什么是本质？"，是这些实际存在的物体，例如设备、人？还是人们观念中的概念，例如用户、产品？亦或就是邱兄所言的"活动"？我不敢确定，毕竟这个问题其实是一个传统而悠久的命题。
邱兄提到的满足"心"的基本特征条件是，"它与所有其他事物的关联最多"，这个条件并不明确，因为"多"这个词是相对的，虽然活动关联了很多的主体、客体，可一个主体会参与很多活动，影响很多客体啊。如此，哪个更多，恐怕这并不好判断。
我赞同先不作"主题涣散"，不过即使如此，还需要一个前提——面对的问题域是什么。概念是人们观念的反映，总得放在一个环境中，我想在企业环境中的概念模型和社会环境、自然环境中的概念模型都是不一样的。如果是撇开具体环境而谈无处不在的概念，这个话题恐怕有点大了，呵呵。
至于管理这种纯粹的概念模型用什么开发环境好，用到哪些BI资源，有些不解。因为我的理解是不需要什么开发环境，也不是它需要BI什么资源，倒是BI需要它的支持。（咱们说得是同一个事吗？）
Babituo 20060418
《主体、客体、事件、地点》里面最后有句话:"对于世界上发生的事情，可以用四个概念来描述一下，在某个"地点"，某个"主体"作用于某个"客体"，发生了某个"事件"（有发生的时间）。"其实,庆哥已经在探索这么一个又大又小的题目了,而且,已经把题目缩小到只讨论"主体、客体、事件、地点"外加"时间"这5种东西了.庆哥试图把一个大大的世界浓缩为只有这几年种东西进行演绎的概念小世界,思想的跨度之大，另我佩服.
我只是提出另外一个相似的概念小世界,只有"时间\地点\资源\活动\变化"这5种东西.这是一个概念游戏,玩它不仅仅为了练习思考,庆哥既然能写出上面这篇文章,当然也不仅限于活动活动脑筋吧.
所以我会提出实现它的想法——实现这个只有5种东西的概念小世界，看它能演绎出什么花样来。我们可以当作是“构造分子”的游戏来玩：只有这5种原子，原子和原子之间通过共用电子对建立键连，我们最后可以看看最终构造出来的分子结构有什么规律。我觉得这是一个BI的项目呢！
庆哥如果觉得这个游戏好玩，我们就继续玩下去。
Babituo 20060418
时间：2006年4月18日中午12点
地点：公司食堂
资源：我，肚子，饭，饭碗，筷子...
活动类型：吃饭
变化：碗里的饭空了，我肚子里的饭满了
时间和地点正交
时间和资源正交
时间和活动正交（假设吃饭这种活动可以在任何时候进行）
时间和变化相关（一个变化一定发生在确定的时间）
地点和资源正交
地点和活动正交（假设吃饭这种活动可以在任何地点进行）
地点和变化相关（一个变化一定发生在确定的地点）
资源和活动相交（一个活动一定有有限个资源参与）
资源和变化相交（一个变化一定是关于有限个资源的）
活动和变化相交（在一个活动中一定会发生多次的变化）
可见，变化有4个外部关联，是外部关联最多的，应该把它放在分子的中心位置。
刘庆 20060419
其实思考这些问题更多确实就是活动活动脑筋，至于动手去作个什么东西，暂时还没有没有那样的想法。而老庞可能真正在动手，他不也是在寻找这种原子性的东西用以构建信息系统吗，只不过他考虑的出发点放在供需的适配上面了。
这样活动脑筋也挺有意思，曾经结合过几件事情思考，发现其实这并非是非常虚的空想。
第一件事，历史文献的记录方式。参见《战国风云模型》，各种各样的历史人物、国家粉墨登场，发生种种事件，诸如建国、战争、迁都、刺杀、死亡等等。如果要用一个模型来表示历史，应当如何去表示呢？曾经想过用事件作为主线，任何其他主体、客体都是在事件中关联到。例如一次战争，某年某月，秦国去攻打燕国。如此，切换到秦国为中心的视图，能够看到他曾攻打过燕，而切换到燕国为中心，可以看到他曾被秦所攻打。
然而，在历史里，一般都是记录大事件，而事件这个概念也有些不明确的，因为一次事件其实可以有很多小的事件组成。秦攻打燕，包括秦兵出征，攻占城池或者谈判等事件，这些小事件中，又会涉及其他的主体客体。
历史文献大多有国别体，纪传体等，这就是说从不同角度去看待事件，而不是从事件本身去一一记录，因为那样太过于庞大，要知道一天得有多少人出生，有多少人死亡呢？而从国家、人物来谈历史事件，这是更容易描述，也更容易阅读的，一个国家的建立和消亡，和哪些国家大过仗，出了哪些人物。一个人物何时出生何时死亡，有过什么贡献。当然这样的表述就是免不了会重复介绍一些事件，例如对于秦国，要介绍他于那年灭了燕，而对于燕，也要记录哪一年被秦所灭，是对同一事件的两次记录。按照数据库的说法，这是冗余数据，可能会导致不一致。
从对此事的思考中，发现用事件作为中心线是难以表达出来的。
第二件事，是读《奇特的一生》引发的想法，俄国的一位柳先生，其毕生都保持一个习惯，对自己的时间进行记帐。每天耗费多少时间，花在什么事情上，每个月还会花些时间将他们汇总起来，分析分析。用现在流行的名词，这就是"时间管理"了。
虽然我没有兴趣向他学习如此的时间管理方法，却十分好奇他会如何记录自己的时间。其实这就跟财务上的记帐一样，既然记录时间，那也得有一些"科目"表示时间耗费在哪些方面吧。于是，设想了一下，比如用（活动、开始时间、结束时间）的结构来记录。
那么难处就在于这个活动的分类，譬如说吃饭、睡觉，这还好，一般吃饭睡觉也不会干别的。但如果考虑学习、思考、读书，这种分类似乎就是有交叉的，读书可能是学习，也可能是消遣。如此，我想那个柳先生应该对自己的活动只是进行一些粗略的划分，并且划分出不会交叉的分类（这是不是也是正交的意思？），例如吃饭、睡觉、思考、娱乐、写作、聊天。
可这是对活动的分类只能停留在粗略层面上才不交叉，如果细化下去，不可避免地交叉。例如聊天，和朋友聊天是娱乐，和客户聊天是工作。
如果我们要为自己建立一个时间管理系统，该如何设计这个模型呢？
第三件事是正在维护的ttnn矩阵，这和第一件事其实非常相像，只是矩阵记录的是BI的历史。
开始我规划了一些主题，包括产品、组织、人物、案例、方法、架构等，后来加入了事件。同样，对于事件的描述是非常困难的的，因此，在"大事件"条目中，之记录了很少的东西。大部分内容都放在组织、产品等主题相关的条目中。一般在"大事件"中记录的事件，都会在相应参与者题目中加入此事件的描述，例如"200307，BO收购Crystal"，是需要在"BO"和"Crystal"条目中都记录此信息的。
这遇到和历史文献同样的问题，但现在是网络时代，技术发达，是否可以改变这种状况呢？
设想这样一个平台，可以让你输入某种事件。例如输入"200307，BO收购Crystal"，能够自动在"BO"这个条目中添加此信息，输入"1990年，BO公司成立"，就可以在"BO"条目下查到该公司的成立日期。
如此，在编写"BO"这个条目时，只需要描述它是一家干什么的公司，而不需要描述它跟时间相关发生的事件。
三件事情说完了，我们讨论的概念模型能不能对它们有帮助呢？
Babituo 20060419
呵呵,模型本没有对错,只有哪样更好些罢了,
庆哥茶余饭后,闲得无聊的时候再来考虑这个模型的问题吧.
我暂时提醒两句话:
1.以事件为中心不代表事件是一切;
2.讲究正交不是让所有的事物正交;
多谢庆哥引导,现在,我彻底打消了对BI的"心理障碍"了.
Yushan 20060419
大家好，朋友们讨论的很热乎，我也来凑个趣，试图回答刘庆的疑问：
从这个词语的本义看，有"垂直"的意思。但结合一般语境来理解，这个词反而应当是"不相交"的意思，是"平行"。比如说"正交的角度"，我想邱兄的意思就是说这¬些维度之间各自独立，相互不会有依赖（当然通常并非如此，很多维度是有依赖关系的）。再比如事物的分类，说这五种分类"正交"，可能是指一种事物归属了其中一种¬分类之后，不会再归属于其他分类了。软件架构中的正交设计，也是这种"不相交"的语义，要保持模块的独立性，相互之间不会互相调用。
因此，我非常奇怪，为什么要用"正交"这个词呢？谁第一个用它？它的本义或者延伸涵义是什么呢？
为什么用正交来表达不相关呢？这是因为在向量空间，表达两个向量是否相关就是看它们的投影，如果一个向量在另一个向量的投影越大，这两个向量的相关度也越大。当它们平行时，也就是夹角为０，三角余弦函数取最大值。当正交时，两个向量相互投影为０，所以就是不相关。
也就是各自独立。
表达两个向量相关的算法就是点积，也叫内积，它就是用代数方法来表达投影的意义。
如果给你两个数a和b，它们是否相关就是是否一样，最简单自然的方法是用a=b来表达，或者用a-b=0.用差值来评价是否一致最自然不过的了。
但是，还有一个非常重要，而我们不太注意评价两个数一致（相关）的方法，那就是这两个数的乘积最大。当然这两数必须满足一定的约束条件，比如当两个数之和是一个常数时，它们如何是相关的呢？是这两个数乘积最大的时候。比如
５＊５＝２５ 大于 １＊９＝９
向量的内积算法就是基于这后一个相关的评价方法，即乘积最大的数（向量）相关度最大。
Jerome 20060422
--作为星星的维,其实也是可以有多层次分级的,只不过它是将每级的ID放在同一个维表中,
--并且每级的ID都和事实表中的事实建立外键的关联?,也就是说,和事实关联的多个外键,
--可能是针对同一维的,这样一来外键的索引层次虽然变成只有一层,但有多个,所以逻辑上仍然是多级的.
关于这段分析，有些不同的意见。
星型结构的维度表中是可以有多层次分级的，但是不见得必须建立每级的ID，建立每级的ID只是一种实现方式。
即使建立了每级的ID，也不能将每级的ID都和事实表建立外键关联，只要有一个外键关联即可。
维度表和事实表之间是极力反对多主键关联的。
以下表为例：
（日ID、日描述、周ID、周描述、月ID、月描述、年ID、年描述）
在事实表中只要建立（日ID）即可与日期维度表建立年、月、日的查询。
（周ID）、（月ID）等是不需要建立入事实表的。
否则的话无论从事实表的容量考虑还是从查询的效率考虑都是不可以接受的。
Babituo 20060424
多谢Jerome的细心指点,
我一直对自己的这个"发挥理解"表示担忧,因为,在我目前看到过的资料看来,还没有看到过明确到这个细节的介绍.
从我所看到表面的陈述来说,我可以不求甚解地认为我已经理解了星型和雪花的区别了,但是,遇到这个外键设计的细节问题,就说明我理解的还不到位.
所以我要感谢Jerome的细心.
不过,我的疑问又随之而来了:
1.如果星型模式是这样设计多级的维用一个主键和事实表来关联的话,我们所说的,和雪花模式的区别在于键有冗余又在哪里呢?
2.如果是这样,星型模式和雪花模式的区别,仅在于用一个大维表来维护多级的维,还是维的每一级都用单独的一个表来维护.如果是这样的话,雪花模式用来维护一个维所用的总记录数不会比星模式更多吗?
责编：姜玲
微信扫一扫实时了解行业动态
微信扫一扫分享本文给好友
微信扫一扫实时了解行业动态
战略咨询工具大全(PPT116).ppt
战略咨询分析工具及使用方法.pd..
