比如：
业务A,需要数据a1,数据a2,,数据a3, 数据4。我们可以制定进入系统的关于业务A的条件是必须要有数据a1,a2才可以进入系统(也就是最低要求)，如果提供的业务数据同时有数据a1,数据 a2, ,数据a3,那就是更高一级的数据(第二级数据)，如果业务数据在满足第二级数据的基础上，提供了数据4，那就是第三级数据。
如果用过J2EE平台的同行理解起来就比较容易，这实际上就是JMS基于主题的消息管理思想用于软件系统一个具体例子而已，这里不过是强调的是用于管理数据的信任等级而已。
其实很多软件项目开始制定的的数据规范，一般到后来都执行不下去，主要是太理想化了，也许只有到系统真正用起来了，系统数据的信任等级才能上去。所以我觉 得应该在系统开始时候就把数据分等级，不同的等级，业务给与适当不同的处理，这样也便于后期的业务进行查询统计分析或者数据挖掘。
这种思想实际上就是将数据可以信任的程度进行分类;而一般的软件系统是把数据定义为两类，可以进入系统，不可以进入系统;我在这里设想的是，从数据可以信 任的角度出发，分成多种类别，使用了一个小数来描述信任程度，而不是一个二值逻辑变量来描述;这样从建立软件系统整体模型的时候，把数据信任管理纳入考虑 之内，在进一步作业务分析，决策支持或者数据挖掘时候是比较有好处的;当然进一步延伸可能就需要从OLTP/OLAP混合建模来考虑，不过真要到那个高 度，可能项目范围就扩大了很多，具体怎样操作，还要看项目具体情形。
当然，在软件项目实际操作的时候，可能还会遇到另外一个问题，很可能用户会乱用这个数据信任程度的概念，我个人的建议是在项目实施中如果可能的话，优先进 入信任等级高的数据，然后才是信任程度低的数据;当然也可以从人员来角度作为切入点，信任等级越低的数据，进入系统就需要的业务更熟悉的人员来操作录入， 而且经过的业务处理步骤就越多。一句话，数据信任程度越低，就应该受到的审查/检察越多。
在现实中稍微规模大一点的软件系统涉及到的组织机构都是比较大的，有很多还可能是松散的组织管理模式。在这类组织机构中，同样的业务数据可能很多部门都会是数据录入点和数据分析点，为此可以从数据采集/来源角度来描述数据本身。
从当前项目利益来说，数据来源管理方便数据查询分类，长期来说可以建立起数据信任等级。
对于数据来源的识别，一般需要有特定信息来记录数据的来源，特别是一些大型企业当然分支机构较多的公司企业政府，也应该这样来管理。
事实上，数据来源管理是数据信任管理的进一步延伸，是数据信任管理的前置条件。一个数据，可以是来自于A部门的也可能是来自于B部门的。为了方便统计查询和数据信任管理的加强，应该记录下数据的来源地。
具体操方式可以有以下几种：
1) 数据录入人员的工作人员编号，知道了数据录入人员的编号，就知道数据的来源地。
当然，实际工作种存在人员调动，替操作(1个人用另外一个人的身份进入系统数录入)，这些都有可能需要考虑到，否则可能造成数据来源管理失效。
2)另外一种方式就是直接记录数据录入的部门编号。
这种方式弊端就是不能记录下数据的具体操作人员。
其它说明：如果系统中引入了工作流产品，数据来源这部分工作可以由工作流来担任。具体例子：在现实的软件系统中可能存在一个主数据库/数据中心，若干分数 据库/数据中心，系统在每过一定时间进行数据上传/下载，为了进行数据合并和控制数据的修改，应该每个分数据中心只能处理修改自