一点被忽视的模型使用方法

：[@more@]

现在每个公司，每个技术人员再谈到BI/DW的时候都谈到模型，不管是关系模型还是多维模型，甚至是二者的混合模型，我们很多人都在考虑表（table）的设计，数据的存储等等问题，这些的确使我们需要考虑的，但是我们却忽视了一点，我们前台展现的只是需要的浏览数据，而不是你有没有数据存储在database中。当然我这样说，大家都要问了，不存储数据怎么展现数据了？是的，我们需要存储，但是不是任何展现的数据都需要在数据库中记录，有的是我们使用case语句转化过来的，这些转化后的数据存储在数据库中最好。

言归正传，我接触到的很多的数据模型，大多都是直接用表去展现，而较少的使用视图（view）

变化维也好，正常的维度也好，我们都可以使用视图，只要视图的条件不要太多，索引效率较高，我们其实可以选择视图的方式，比如我们常用的person，time，product等等，都存在变化维的问题，而且对于同一张表，比如time，在不同的展现或者分析技术上，使用的方式是不一样的，通常的报表，只需要展现正常的数据，就可以使用简单的select from的方式，如果我们需要在维度上过滤一些东西，或者按照某种状态，类型去过滤数据的时候，或者进行一下计算，比如我们常常提到的holiday的问题，我们就需要增加一下表之间的关联，使用union或者inner link等方式
这样既不会改变现有的结构，也方便前台的展现和以后的一些必要的变动和维护，特别是table结构发生变化，我们就有可能需要去做很多的更改，特别是ETL和前台的应用。

这里有几点使我们需要注意的
1：建模的时候，最好有2-3个status和flag的字段，比如是否有效，是否过期，是否有特别的用法。这样方便查询和使用，同时也为将来企业的业务变化，或者存在并购，收购需要整合系统时预留了扩展的空间，特别是很多公司，有很多分公司，而很多系统是一个个的上线，比如中国，日本，韩国，新加坡，有可能这几个国家的原系统都不一样，而我们实施时，考虑的只是1-2个系统，当要增加新的系统，我们就变得很为难，一旦我们有足够的status或者flag的字段，我们就方便通过view去展现我们需要的数据了

2：考虑多种业务的需要，比如sales和HR，logistic等，需要查询的时间都可能不一样，有的需要特别标示周末，有的需要按照周统计，有的需要按照特殊的时间，比如月底等等，这些应用有足够的了解，我们的应用就比较得心应手

3：性能的考虑，使用视图，如果query不是很复杂的话，性能就和table差不多，如果特别复杂的时候，我建议还是有一张临时表或者专为view服务的表，加一些相应的ETL去处理数据，这个有点像datamart，主要看实际情况，你愿意为应用主题建立datamart还是使用view

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7600305/viewspace-1004894/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7600305/viewspace-1004894/