在系统设计中，我们一般会考虑时间，但我们很少会正式意义上去分析时间，我现在从数据仓库的角度来分析一下，“时间”作为一个“维度”时，应该如何设计。
我们绝大部分的系统都只考虑业务型的，也就是系统的运行，而作为一个大型的系统来说，“数据分析”才是关键，因此，要把系统设计成具有“分析”，也可能称之为“数据挖掘”（当然数据挖掘的概念并不仅仅于此），这种具有“分析”功能的系统，可以称之为“决策辅助系统”。
这种系统的不同点就是重点在系统的分析决策上，那么对数据的分析就尤其重要，其实的都先不讲，先要看一下“时间维度”，时间在我们的系统中应该是一个最常用到的维度了。
一般的系统中，我们只会加个“生成日期”或“订单日期”的字段，也就是在这样的系统中，我们对时间强调不深，只要记录具体的“时间”就可以了，只会用一个字段来记录，那么我们来提几个问题：
如何获得一周中各天的销售值？想分析一下一周中哪一天销售量比较高。
如何获得一年中每个月的销售总值？
如何获得双休日的销售情况？
如何获得每星期的销售情况？
如何获得每年端午节或其他农历节的销售情况？
总之，我们会有很多的与时间相关的分析，如果按上面的一个“时间”字段，要分析这些，恐怕将非常困难。也不是不可以分析，只是分析的工作量将非常具大，因此我们如果是要做这种类型的分析系统，那么应该充分考虑数据仓库中提到的“时间维度”。
也就是单独定义一个表来作“时间维度表”，在销售时记录此“时间维度表”的主键值作为外键关联，而这个“时间维度表”上，我们可以定义N多的时间属性，如：星期，周，月，年，是否周末，是否法定节日，农历，等等。如图：
通过这样的“时间维度表”，那么对上面的时间分析，我们将变的异常简单了，而且如果有一天遇到时间扩展信息，也可以直接在“时间维度表”中添加字段，而不是修改“订单表”。
其实上面我提到的时间概念，是指的日期，也就是年-月-日，如果有的系统要对Time时间进行分析的话，那么不应该把日期Date与时间Time放在一个“时间维度表”处理，因为这将使“时间维度表”记录以几何级倍数增大，而应该是采用另一个“Time的维度表”来处理。
当然了，这是在必要的系统中才会考虑这个“时间维度”的，因为如果系统不需要这些分析的话，使用“时间维度”会增加系统很大的复杂度。
大家应该根据实际的系统情况来分析。
我们绝大部分的系统都只考虑业务型的，也就是系统的运行，而作为一个大型的系统来说，“数据分析”才是关键，因此，要把系统设计成具有“分析”，也可能称之为“数据挖掘”（当然数据挖掘的概念并不仅仅于此），这种具有“分析”功能的系统，可以称之为“决策辅助系统”。
这种系统的不同点就是重点在系统的分析决策上，那么对数据的分析就尤其重要，其实的都先不讲，先要看一下“时间维度”，时间在我们的系统中应该是一个最常用到的维度了。
一般的系统中，我们只会加个“生成日期”或“订单日期”的字段，也就是在这样的系统中，我们对时间强调不深，只要记录具体的“时间”就可以了，只会用一个字段来记录，那么我们来提几个问题：
如何获得一周中各天的销售值？想分析一下一周中哪一天销售量比较高。
如何获得一年中每个月的销售总值？
如何获得双休日的销售情况？
如何获得每星期的销售情况？
如何获得每年端午节或其他农历节的销售情况？
总之，我们会有很多的与时间相关的分析，如果按上面的一个“时间”字段，要分析这些，恐怕将非常困难。也不是不可以分析，只是分析的工作量将非常具大，因此我们如果是要做这种类型的分析系统，那么应该充分考虑数据仓库中提到的“时间维度”。
也就是单独定义一个表来作“时间维度表”，在销售时记录此“时间维度表”的主键值作为外键关联，而这个“时间维度表”上，我们可以定义N多的时间属性，如：星期，周，月，年，是否周末，是否法定节日，农历，等等。如图：
通过这样的“时间维度表”，那么对上面的时间分析，我们将变的异常简单了，而且如果有一天遇到时间扩展信息，也可以直接在“时间维度表”中添加字段，而不是修改“订单表”。
其实上面我提到的时间概念，是指的日期，也就是年-月-日，如果有的系统要对Time时间进行分析的话，那么不应该把日期Date与时间Time放在一个“时间维度表”处理，因为这将使“时间维度表”记录以几何级倍数增大，而应该是采用另一个“Time的维度表”来处理。
当然了，这是在必要的系统中才会考虑这个“时间维度”的，因为如果系统不需要这些分析的话，使用“时间维度”会增加系统很大的复杂度。
大家应该根据实际的系统情况来分析。
