客户姓名和地址属性处理太过简单。不同地方采用的缩写显示，会议地址列空间足够大，可以容纳任何地址，但没有建立保证与邮局规则一致的规则，或者不能支持地址匹配和纵向/横向识别。
将姓名和地址属性拆分为多个可能的部分，抽取过程则需要针对原先混乱的姓名和地址进行语法分析。属性分析完成后，可以将它们标准化。
客户纬度通常包含多种日期，例如，首次购买的日期，最近一次购买的日期，生日等。
客户维度最强有力的属性是分段类，在不同的商业环境下，这些属性的变化范围显然比较大，对某个个体客户来说，可能包括
性别
民族
年龄或其它生命分段方式
收入或其他生活类型分类。
状态（例如新客户、活跃客户、不活跃客户已离去客户）。
参考源
特定业务市场分段（例如，优先客户标识符）
维度建模的一个基本原则是确定事实表粒度，然后仔细将维度和事实表增加到设计中，保持同样的粒度。
当不同属性的数量不断增长超过了适宜范围，并且新属性增加非常频繁时，我们推荐使用桥接表。
假设将贷款申请信息收集起来，包含一个开放的姓名-值对。一段时间后，可能收集的上百个甚至上千个不同的贷款申请变量。
这样使用桥接表方式非常合适。
大多数商业客户具有多种联系方式，包括决策者、购买代理、部门主管、客户联络人等。每种联系方式都与特定角色关联，由于联系数量不可预测且比较繁多，桥接表设计是处理这种情况的方便方法。
在大量操作性应用中，可能希望检索客户在过去任意时刻的确切状态，在被拒绝贷款延期后，客户是否属于欺诈警告状态，他处于该状态多长时间了，关键的建模步骤包括一对日期，第一个日期是事务的准确时间，第二个日期是另一个事务的准确时间。
招揽客户的事实表和客户相应的实施表，客户喝着俩之间存在一对多的关系，客户和响应之间也存在一对多关系，招揽和响应事实表具有不同的力度。并不是每个招揽结果都存在响应，且某些响应未与招揽对应。将招揽事实与客户纬度连接，然后将其与响应事实表连接，由于粒度不同，在关系数据库环境下，无法返回正确的答案。
如果商业用户频繁地合并多个业务过程的数据，最后的方法是定义额外的事实表，将数据一次性合并到事实表中，而不是依靠用户自己在不断地、准确地的去合并数据。
网友评论