Data warehouse 设计问题
正在学习数据仓库，概念有些模糊,数据仓库是面向主题的,报表算是一个“主题”吗？或则在以下情况中1为一个主题，2为一个主题?
有一个报表:
查询条件:城市/年龄/性别
假设有一家公司生产了一个产品，需要统计
1. 哪些销售商从公司批发了该产品 （根据搜索条件: 城市）
2. 每个销售点又有多少人买了该产品 （根据搜索条件: 城市/年龄/性别）
- a. 买产品的人的学历（例如，大专 多少人， 本科 多少人， 本科以上多少人）
- b. 性别和年龄（例如：男： 10-20岁多少人， 21-40岁多少人， 女：10-20岁多少人， 21-40岁多少人）
求教: 如何设计这个数据仓库?我有以下想法，但感觉设计的很有问题, 请各位给出方案学习一下.
维度表:
Dim日期
-ID
-年
-月
-日
Dim城市
-ID
-描述
Dim销售商
-城市Key
-描述
Dim学历
-ID
-描述
dim性别
-ID
-描述
dim年龄区间
-ID
-描述
事实表:
fact销售记录
-日期ID
-销售商Key
-销售记录Count
(是否应该把下列fact表整合到一个总的fact表? 但用一个fact表数据量是否会太大?)
fact客户学历
-年龄区间key
-性别key
-销售商Key
-日期Key
-学历Key
-客户学历Count
fact客户性别
-年龄区间key
-学历Key
-销售商Key
-日期Key
-性别key
-客户性别Count
fact客户年龄
-学历Key
-销售商Key
-日期Key
-性别key
-年龄区间key
-客户年龄Count
[解决办法]
报表算不上一个主题, 只能是主题的一个呈现方式, 一个组成部分.
[解决办法]
按你所说需求，应该是建立一个以“销售”为主题的数据仓库。
我认为最后面的三个事实表，应该合成为一个“客户”维度表，不需要存储客户学历Count ，客户性别Count，客户年龄Count。
当要分析客户学历等指标的时候，把这个“客户”维度表当作事实表使用即可，而Count数可以通过很多方式获得(比如在多维数据集中的count选项,或者直接通过SQL获得)
[解决办法]
1.报表是所有数据仓库应该共有需要,而不是主题,主题是指该数据仓库的目的,是为了展示什么数据.比如:销售,保险等.
2.关于表的设计,看来你对度量,维度以及维度的属性概念的理解还有些问题.像性别,学历,年龄等都可以作为一个维度:客户的不同属性,而不是单列出来分别做维度.
[解决办法]
性别,学历,年龄不要再分KEY出去了,直接做为客户维度的属性.
数据仓库的设计可以考虑一些冗余,不需要太局限于什么1,2,3NF
[解决办法]
1.不应该把客户作为一个维度，数据仓库的维度表记录绝不能过多。
2.应该整合为一张宽表，数据量大点没有关系的，数据仓库本来就是随时间变化增量的，但建立表的时候可以预测下一行记录所占的字节数，把各个字段类型的字节数严格控制。我现在仓库中一天1亿数据进来，加上各种不同分析统计存入不同表的数据，一天要消耗我盘15G,所以原始数据只能保存个把月就得删了。
3.如果要到达快速访问的话还可以建立相应的数据集市，也即从大表中抽取相应字段进行不同的中、高级汇总
4.数据库设计模型的话除了关系模型(一般第三范式即可)，也可利用星型模式和雪花模式
[解决办法]
这可以是一个主题，只是不同的角度而已，一是从公司的角度，业务属于“配发”，二是销售点的角度，业务属于“零售”。Kimball在建设DW时提到过，要先分析数据集市，再设计维表，最后是设计事实表，如果前一个问题没搞清楚，后面的问题无法深入，如果凑合的话，只能是残废短命的DW。当然很多公司也将客户作为独立的主题分析，就看客户分析的重要性和复杂性了。
你这里的零售好像又分为销售的角度和客户两个角度，有点乱，最好理一下。如果都有需要，可以设计3个事实表，一是公司配发的事实表，一个销售点零售的事实表，再一个是客户购买的事实表。
接下来说维，既然数据集市主题已确认，那么公司、销售商、销售点、客户四大维必须设计，时间也是必须的，产品多的话，还需要产品维，这里就不需要了。（谁说维大了就不能设计成维了？除非你不想从这个角度分析）。接着城市、年龄、学历只是维的属性，必要的时候可以设计为独立的维，但也可以放在四大维里。
比如城市，四大维里都可以涉及到，那么需要考虑下维的层级，这方便BI展现的钻取。
至于年龄区间，是一个衍生维，需要特别处理，不可死设计，因为区间可能随时变化。
接下来事实是最简单的了，销售额，销售数量，毛利等等。
