- 系统设计之时间维度[数据仓库]

系统设计之时间维度[数据仓库]
Posted on 2005-08-29 22:19听棠.NET 阅读(945)评论(8)  编辑 收藏收藏至365Key 所属分类:技术积累
在系统设计中，我们一般会考虑时间，但我们很少会正式意义上去分析时间，我现在从数据仓库的角度来分析一下，“时间”作为一个“维度”时，应该如何设计。
我们绝大部分的系统都只考虑业务型的，也就是系统的运行，而作为一个大型的系统来说，“数据分析”才是关键，因此，要把系统设计成具有“分析”，也可能称之为“数据挖掘”（当然数据挖掘的概念并不仅仅于此），这种具有“分析”功能的系统，可以称之为“决策辅助系统”。
这种系统的不同点就是重点在系统的分析决策上，那么对数据的分析就尤其重要，其实的都先不讲，先要看一下“时间维度”，时间在我们的系统中应该是一个最常用到的维度了。
一般的系统中，我们只会加个“生成日期”或“订单日期”的字段，也就是在这样的系统中，我们对时间强调不深，只要记录具体的“时间”就可以了，只会用一个字段来记录，那么我们来提几个问题：
如何获得一周中各天的销售值？想分析一下一周中哪一天销售量比较高。
如何获得一年中每个月的销售总值？
如何获得双休日的销售情况？
如何获得每星期的销售情况？
如何获得每年端午节或其他农历节的销售情况？
总之，我们会有很多的与时间相关的分析，如果按上面的一个“时间”字段，要分析这些，恐怕将非常困难。也不是不可以分析，只是分析的工作量将非常具大，因此我们如果是要做这种类型的分析系统，那么应该充分考虑数据仓库中提到的“时间维度”。
也就是单独定义一个表来作“时间维度表”，在销售时记录此“时间维度表”的主键值作为外键关联，而这个“时间维度表”上，我们可以定义N多的时间属性，如：星期，周，月，年，是否周末，是否法定节日，农历，等等。如图：

通过这样的“时间维度表”，那么对上面的时间分析，我们将变的异常简单了，而且如果有一天遇到时间扩展信息，也可以直接在“时间维度表”中添加字段，而不是修改“订单表”。
其实上面我提到的时间概念，是指的日期，也就是年-月-日，如果有的系统要对Time时间进行分析的话，那么不应该把日期Date与时间Time放在一个“时间维度表”处理，因为这将使“时间维度表”记录以几何级倍数增大，而应该是采用另一个“Time的维度表”来处理。
当然了，这是在必要的系统中才会考虑这个“时间维度”的，因为如果系统不需要这些分析的话，使用“时间维度”会增加系统很大的复杂度。
大家应该根据实际的系统情况来分析。
Feedback
# re: 系统设计之时间维度[数据仓库]
2005-08-29 22:38 by突破自己
对自己有点启发，多谢大哥。
# re: 系统设计之时间维度[数据仓库]
2005-08-29 23:34 by灵感之源
可否简化为时间匹配？
你的需求应该是要获取指定时间周期内的数据．
# re: 系统设计之时间维度[数据仓库]
2005-08-30 00:17 bydudu
图片有点宽了。
# re: 系统设计之时间维度[数据仓库]
2005-08-30 09:11 by沉默天蝎的.net学习汇集
你的想法我非常赞同！
尤其在我这样的大公司，
严格来说需要的深度的数据挖掘，需要从中把握到市场规律。
我们公司的市场部就要求这样那样的数据，这样那样的报表。
呵呵
不过说真的，
这样造成的复杂度的确很大。
询问个问题，
你觉得使用oracle来分析还是sql server2000的数据库分析比较好呢？
# re: 系统设计之时间维度[数据仓库]
2005-08-30 09:17 by蛙蛙池塘
你在弄数据仓库呀.
# re: 系统设计之时间维度[数据仓库]
2005-08-30 09:28 bydudu
请调整一下图片宽度, 为使用1024*768分辨率的朋友考虑一下。
# re: 系统设计之时间维度[数据仓库]
2005-08-30 11:23 by听棠.NET
@沉默天蝎的.net学习汇集 :
其实至于采用什么数据库，这并不是很重要，主要是看系统的大小，数据库只是影响性能而已。
如果是很大型的，当然是推荐采用ORACLE了，如果不是特庞大的话，采用SQL SERVER足已。
这“时间维度”确实会增加很大的复杂度，所以这要视系统而定的，我也是至今没遇到如此庞大的需要使用“时间维度”处理的，不过，我们应该要有这样的意识才对。
# re: 系统设计之时间维度[数据仓库]
2005-08-30 14:02 by高
增加时间维倒是一个不错的主意。不过，我们上次做得成本分析，因为数据的维数过于细化，以至于提供给决策层的信息量过多，工作时间不允许。
_xyz