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

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

源系统跟踪报告也可以作为数据仓库的后续阶段的概要。如果有20个源系统被确定在这个列表中，并且阶段1 包括两个或者三个系统，则规划这个项目要很长很长的时间。 
  主题域：系统的数据集市常用的名称。 
  接口名称：源系统支持的交易应用系统的名称。 
  业务名称：业务用户通常使用的系统名称。 
  优先级：用于确定将来阶段的位置顺序，优先级通常在数据仓库总线矩阵完成后设置。 
  部门/业务用法：使用数据库的主要部门，比如：会计、人力资源等等。如果有许多部门使用这个应用，指出这个业务用法，比如：库存控制、客户跟踪等等。 
  业务所有者：与使用应用或者数据库的相关问题的联系人或者小组。一般来说该人或者该小组是这个主题域的数据负责人。 
  技术所有者：一般是负责维护数据库的DBA或者IT 项目经理。 
  DBMS: 源数据库管理系统的名称。大多数是关系型数据库，比如ORACLE, DB2, 或者SYBASE。也可能是非关系型数据存储如LOTUS  NOTES 或者VSAM。 

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

  日常用户：让你知道组织中有多少操作型人员使用这些数据。这个数字并不是潜在的数据仓库的最终用户数。 
  DB大小：DBA可以提供这个信息。