8. 设计市场营销的数据仓库时,需要考虑哪些因素?

成功的管理系统=50% 的业务+(25%的数据库+25%的程序)
建立数据仓库的第一个步骤就是通过与业务部门的充分交流，了解建立数据仓库所要解决的问题的真正含义，确定各个主题下的查询分析要求。
业务人员往往会罗列出很多想解决的问题，信息部门的人员应该对这些问题进行分类汇总，确定数据仓库所实现的业务功能。一旦确定问题以后，信息部门的人员还需要确定一下几个因素：
·操作出现的频率，即业务部门每隔多长时间做一次查询分析。
·在系统中需要保存多久的数据，是一年、两年还是五年、十年。
·用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。
·用户所能接受的响应时间是多长、是几秒钟，还是几小时。
由于双方在理解上的差异，确定问题和了解问题可能是一个需要多次往复的过程，信息部门的人员可能需要做一些原型演示给业务部门的人员看，以最终确定系统将要实现的功能确实是业务部门所需要的。
1、考察现有系统环境
大多数数据库项目都不是从头开始建立的，通常机构内总会存在用来满足特定需求的现有系统。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。
2、充分预计需求的升级趋势
询问用户如何看待未来需求变化非常有用，这样做可以达到两个目的：首先，可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。
3、充分理解客户的需求
看起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求，真正的需求在客户的脑袋里。你要让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。
一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解。
了解业务可以在以后的开发阶段节约大量的时间，而其你会发现，一旦你明确了业务需求，你就可以自己做出许多决策了。
4、确定数据对象的命名规范
一定要定义数据库对象的命名规范，可以考虑用约定好的前缀或后缀：
对于视图来说，可以采用vw_前缀；
对表来说，表名可以加上前缀tbl_；
对表内的列[字段]来说，数字类型可以用_N作为后缀，字符类型可以采用_C后缀等，Money类型可以采用_M后缀，日期类型可以采用_D作为后缀等等；
对于存储过程来说，可以采用sp_前缀；
对于自定义函数，可以考虑采用udf_前缀；
此外，采用全大写字母，且以下划线分割单词，如：TBL_CUSTOMER_INFO
5、创建数据字典
一定要花点时间创建数据字典，其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库的人都明确如何从数据库中获得数据。
6、从输入输出下手
在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。举个简单的例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
7、报表技巧
要了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年？如果需要的话还可以考虑创建总结表。系统生成的主键在报表中很难管理。用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱。
8、考虑国际化问题
在设计用到网络或者具有其他国际特性的数据库时，一定要记住大多数国家都有不同的字段格式，比如邮政编码等，有些国家，比如新西兰就没有邮政编码一说。