一些维度建模的问题

[小水牛]

现在在做保险行业的维度建模，对一些问题想请教各位：

1.系统中有很多的“类型”表，“状态”表，比如理赔类型表，批改类型表，交易类型表等等，这些类型表都需要分别建立一个维度表吗？

2.一个客户的多个联系地址如何处理？

3.对于OLTP系统中的众多代码，是继续用代码表示还是直接用代码对应的内容来表示？例如：1代表A，2代表B，3代表C，是直接在维度表中用
A,B,C表示呢，还是用原来的代码？

4.如何设计异构的产品以及标的维度表？是每个单独做一个吗？那和事实表如何关联呢？

5.在EDW中基本用3NF建模，用start_date和end_date保留数据版本，在数据集市中（维度建模）如何处理呢，是保留原来的方式，还
是用缓慢变化维？

[Li, Frank]

第三个问题的探讨：
要用代码标转化，主要考虑以后其他数据源的装数。考虑到数据标准化，建议统一编码。

在08-3-26，小水牛 <Lucia...@gmail.com> 写道：

[innovate511]

1。是否需要建维表，按照经验，有如下几点依据（1）是否有必要专门的表去维护管理，（2）维定义变化是不是会比较大，（3）描述的信息范围会不会比较
多。如果类型是比较固定的，不需要经常维护的，定义简单的，可以直接放在事实表作为退化维，否则还是拿个维表去维护吧。
2。这个要看业务系统怎么定义的，比如是家庭地址，还是公司地址，或者联系地址，这需要问业务系统的人。
3。是自己的还是原来的代码都不重要，关键是统一建，只要你的模型能管理好每一个定义。
4。这恐怕需要调研清楚吧。维度模型就是需要先理解数据源的业务意义，才能建合适的模型，以解释他们所代表的意义，对于结构不一样的源头，首先是转换成
数据仓库系统中定义一样的，然后设计统一的代码管理，才能融合在主体模型当中。
5。不知道楼主是否只有一个数据集市，如果是多个数据集市，建议还是先统一维度建模，然后再进数据集市吧。进入维度模型后，那两个时间标识就没用了，需
要转换为对应的时间范围进行针对时间周期的汇总，比如日事实表、周事实表等。

[小水牛]

非常感谢你的帮助

1.这些表基本都需要建立维表，我想说的是如果对这些表分别建立维表的话，可能会有几十个，太多了，而且每个表的结构都差不多，有没有什么好的办法来解
决，还是只能分别建维度表？

2.客户信息中可能会有多个地址，这些地址有不同的用处，在建立客户维度表的时候，如何多个地址呢，而且这些地址的数目可能不是固定的，如果是固定的2
个或3个，就可以直接扩展开来了。

4.异构的产品、标的结构是指这些产品不能用统一的一个表结构进行表示，在OLTP中是有一个父表，下面有一些具体表示这些产品或标的的字表，在维度建
模的时候，还采取这种方式吗？有没有其他的处理方法？

5.在EDW中那两个日期加上原来的主键作为联合主键表明数据的不同版本。在数据集市中，是还采用这种方式，还是采用代理键的方式？如果采用代理键，如
何做相应的转换呢？

> > 是用缓慢变化维？- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[beyo...@foxmail.com]

按我现在的做法来探讨一下：

在EDW中：

1、那些“类型”表和代码表还是存在的。因为，之所以采用3NF的EDW建模，主要是为了减少冗余。当然，可能这些表会根据多个OLTP系统的实际情况，进行一些整合。

2、那些存放业务数据的表或其它如客户信息的表等，用start_date和end_date保留数据版本。

3、“一个客户的多个联系地址如何处理？”，建立一张客户联系地址表。

 

在数据集市中（维度建模）中：

1、把那些“类型”表和代码表的数据都整理到相应的维度表中。

2、业务数据分事务型、周期快照型和累积快照型来保留时间信息；维度数据采用缓慢变化维来反映历史信息。

 

问题4好像KIMBALL的书中有描述，已经记不得了。

 

2008-03-27

---

---

发件人： 小水牛

发送时间： 2008-03-26  15:06:37

收件人： ttnn BI 观点

抄送：

主题： 一些维度建模的问题

--~--~---------~--~----~------------~-------~--~----~

http://groups.google.com/group/ttnn

-~----------~----~----~----~------~----~------~--~-

[小水牛]

在EDW中，主要还是采用的3NF建模的方式，一来减少冗余，而来存储更完整的企业信息数据。

1.类似类型表之类的代码表在3NF还是存在的，但目前采用的是统一管理的方式（即结构相同的都放在一个实体里面），我的疑问是在数据集市中，这些表是
需要单独形成一个一个的维度表吗？有没有其他的办法进行管理；

2.正是用start_date和end_date保留数据版本，我想问的是在数据集市中，记录维度变化还是采用这种方式，还是用代理键以及缓慢变化维
来实现呢？

3.一个客户多个地址，在EDW中，是专门建立客户的地址联系表。但在数据集市中还是采用这种方式，还是把这些地址集成到客户维度中，而且这些地址的数
目不是固定的。

On 3月27日, 上午11时02分, "beyon...@foxmail.com" <beyon...@foxmail.com>
wrote:
> 按我现在的做法来探讨一下：
> 在EDW中：
> 1、那些"类型"表和代码表还是存在的。因为，之所以采用3NF的EDW建模，主要是为了减少冗余。当然，可能这些表会根据多个OLTP系统的实际情况，进行一-些整合。

> 2、那些存放业务数据的表或其它如客户信息的表等，用start_date和end_date保留数据版本。
> 3、"一个客户的多个联系地址如何处理？"，建立一张客户联系地址表。
>
> 在数据集市中（维度建模）中：
> 1、把那些"类型"表和代码表的数据都整理到相应的维度表中。
> 2、业务数据分事务型、周期快照型和累积快照型来保留时间信息；维度数据采用缓慢变化维来反映历史信息。
>
> 问题4好像KIMBALL的书中有描述，已经记不得了。
>
> 2008-03-27
>

[Qing]

对于第三个问题，我想提个问。

 

在EDW中针对地址专门保存，可以说，我不知道这个地址信息可以干什么，先按照规范形式保存起来。

 

到了数据集市，你说要把地址集成到客户维度。为什么要集成到客户维度呢？

 

在业务上这些地址是怎么理解的呢？是不是有以下几种可能

1、真的是一个人可以同时住在不同的地方，所以为了让你找到他，留了n个地址

2、还是说地址分别不同目的，有的是工作地址，有的是家庭地址，有的是联系人地址，但每个目的只可能是一个地址

3、或者，在这n个地址里面，只有最新的一个是有效地址，其他的都已经作废了

4、其他某种可能？

 

集成到客户维度是为了进行多维分析吧，我想还是得弄清楚业务含义，才去考虑如何集成，甚至是否有集成的必要。

2008/3/27 小水牛 <Lucia...@gmail.com>:

...3.一个客户多个地址，在EDW中，是专门建立客户的地址联系表。但在数据集市中还是采用这种方式，还是把这些地址集成到客户维度中，而且这些地址的数目不是固定的。
...

[小水牛]

对于第3个地址问题，在保险行业，投保人在购买不同的保单时会留不同的地址，比如给情人买的保单的地址肯定不能留自个家的地址，还可能有其他的不同联系
方式，比如电话等。

因为这些地址信息是和保单密切相关的。这些不同的地址在做客户服务的时候需要，比如一个投保人名下有10个保单，其中这10个保单分别的地址信息是什
么？

如果这样的话，每个保单可能就产生一个客户信息，那这样的话，客户维表中的数据量岂不是和事实表中一样多了吗？这种情况如何处理呢？

On 3月27日, 下午1时37分, Qing <happys...@gmail.com> wrote:
> 对于第三个问题，我想提个问。
>
> 在EDW中针对地址专门保存，可以说，我不知道这个地址信息可以干什么，先按照规范形式保存起来。
>
> 到了数据集市，你说要把地址集成到客户维度。为什么要集成到客户维度呢？
>
> 在业务上这些地址是怎么理解的呢？是不是有以下几种可能
> 1、真的是一个人可以同时住在不同的地方，所以为了让你找到他，留了n个地址
> 2、还是说地址分别不同目的，有的是工作地址，有的是家庭地址，有的是联系人地址，但每个目的只可能是一个地址
> 3、或者，在这n个地址里面，只有最新的一个是有效地址，其他的都已经作废了
> 4、其他某种可能？
>
> 集成到客户维度是为了进行多维分析吧，我想还是得弄清楚业务含义，才去考虑如何集成，甚至是否有集成的必要。
>

> 2008/3/27 小水牛 <Lucian.n...@gmail.com>:
>
>
>
>
>
> > ...3.一个客户多个地址，在EDW中，是专门建立客户的地址联系表。但在数据集市中还是采用这种方式，还是把这些地址集成到客户维度中，而且这些地址的数目-不是固定的。
> > ...- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Qing]

地址是依赖"保单"而不是"客户"，为什么要将地址集成到客户维度里面呢？

 

我想到两个，以业务提问的形式提出：

1、不同地区的保险客户分布如何？

2、不同地区的保单分布如何？

 

第一个，客户地址应该不能用保单地址，而是用客户居住地址。

第二个，应该是保单地址（就是保单受益人地址么？），但统计的不是客户，是保单。

 

这就像是电信行业里面的客户和用户关系一样，客户是一个主动的实体，而用户是客户与产品的订购关系，比如使用语音产品。一个客户可以有多个手机号，也就是一个客户可以对应多个用户。

 

做多维分析的时候，如果要用依附于用户的维度，比如用户消费档次，去分析客户的度量，没有太多意义。虽然数据仓库中经常有冗余，但也是在概念不混淆的情况下冗余。

 

我认为没有必要将你说的地址放在客户维度。

 

2008/3/27 小水牛 <Lucia...@gmail.com>:

对于第3个地址问题，在保险行业，投保人在购买不同的保单时会留不同的地址，比如给情人买的保单的地址肯定不能留自个家的地址，还可能有其他的不同联系方式，比如电话等。

因为这些地址信息是和保单密切相关的。这些不同的地址在做客户服务的时候需要，比如一个投保人名下有10个保单，其中这10个保单分别的地址信息是什么？

[小水牛]

目前在维度建模的时候，对客户联系地址还没有要明确分析的内容。只是在建模的时候考虑如何处理比较合适。

Qing的两个问题可能也不是以地址来分析，可能都是以承保的机构所在的地域来分析的（因为对保险业务不是很了解，所以说只是可能）。

以Qing的意思，如何处理地址呢，把其作为一个独立的维度？

On 3月27日, 下午2时49分, Qing <happys...@gmail.com> wrote:
> 地址是依赖"保单"而不是"客户"，为什么要将地址集成到客户维度里面呢？
>
> 我想到两个，以业务提问的形式提出：
> 1、不同地区的保险客户分布如何？
> 2、不同地区的保单分布如何？
>
> 第一个，客户地址应该不能用保单地址，而是用客户居住地址。
> 第二个，应该是保单地址（就是保单受益人地址么？），但统计的不是客户，是保单。
>

> 这就像是电信行业里面的客户和用户关系一样，客户是一个主动的实体，而用户是客户与产品的订购关系，比如使用语音产品。一个客户可以有多个手机号，也就是一个客-户可以对应多个用户。
>
> 做多维分析的时候，如果要用依附于用户的维度，比如用户消费档次，去分析客户的度量，没有太多意义。虽然数据仓库中经常有冗余，但也是在概念不混淆的情况下冗余-。
>
> 我认为没有必要将你说的地址放在客户维度。
>
> 2008/3/27 小水牛 <Lucian.n...@gmail.com>:
>
>
>
>
>
> > 对于第3个地址问题，在保险行业，投保人在购买不同的保单时会留不同的地址，比如给情人买的保单的地址肯定不能留自个家的地址，还可能有其他的不同联系方式，比-如电话等。
>
> > 因为这些地址信息是和保单密切相关的。这些不同的地址在做客户服务的时候需要，比如一个投保人名下有10个保单，其中这10个保单分别的地址信息是什么？
>
> > 如果这样的话，每个保单可能就产生一个客户信息，那这样的话，客户维表中的数据量岂不是和事实表中一样多了吗？这种情况如何处理呢？- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[beyo...@foxmail.com]

我觉得那样的话可以采用杂项维度来处理。

 

 

2008-03-27

---

---

发件人： 小水牛

发送时间： 2008-03-27  15:00:34

收件人： ttnn BI 观点

抄送：

主题： Re: 一些维度建模的问题

--~--~---------~--~----~------------~-------~--~----~

http://groups.google.com/group/ttnn

-~----------~-