ETL----源业务系统数据库跟踪报告

一旦源系统被确定，就要说明这些系统的意义以及谁对他们负责。下图就是为这个目的建立的图表。这个图表，也就是源系统跟踪报告，使得我们不用总是麻烦系统管理员或者业务管理者。如果走运的话，数据建模工程师将开始制作这个列表。不管谁定的初稿，这个列表的维护应该是ETL小组和数据建模小组共同努力来完成。如果在分析过程中认为一个源系统不适合作为数据仓库的源，保留它在这个列表中，并说明不使用它的原因；可能在后续阶段会用得到。 
源系统跟踪报告也可以作为数据仓库的后续阶段的概要。如果有20个源系统被确定在这个列表中，并且阶段1 包括两个或者三个系统，则规划这个项目要很长很长的时间。 

  主题域：系统的数据集市常用的名称。 

  接口名称：源系统支持的交易应用系统的名称。 

  业务名称：业务用户通常使用的系统名称。 

  优先级：用于确定将来阶段的位置顺序，优先级通常在数据仓库总线矩阵完成后设置。 

  部门/业务用法：使用数据库的主要部门，比如：会计、人力资源等等。如果有许多部门使用这个应用，指出这个业务用法，比如：库存控制、客户跟踪等等。 

  业务所有者：与使用应用或者数据库的相关问题的联系人或者小组。一般来说该人或者该小组是这个主题域的数据负责人。 

  技术所有者：一般是负责维护数据库的DBA或者IT 项目经理。 

  DBMS: 源数据库管理系统的名称。大多数是关系型数据库，比如ORACLE, DB2, 或者SYBASE。也可能是非关系型数据存储如LOTUS  NOTES 或者VSAM。 

  生产服务器/OS：这个列包含数据库运行的服务器的物理名称。也包括操作系统。当为ETL设计操作系统级的脚本时，就需要这个列。比如，不能在NT上使用UNIX SHELL脚本。 

  日常用户：让你知道组织中有多少操作型人员使用这些数据。这个数字并不是潜在的数据仓库的最终用户数。 

  DB大小：DBA可以提供这个信息。知道源数据的记录数有助于你确定ETL 的优先级和将要付出的工作量。一般来说，越大的数据库的优先级别越高，因为当在交易系统中查寻大表或者几个表关联查询时性能常常变得很差。 

  DB复杂度：系统中的表和视图对象的数目。 

  #每日交易数：估计出该数字使你对增量加载过程所需要的容量有个认识。 

  注解：通常在研究数据库的时候用来做一般观察报告。可能包括关于未来数据库版本的注释或者为什么某些实体是或不是一个记录系统的原因。