首页 理论教育数据质量管理对数据模型的关系

数据质量管理对数据模型的关系

【摘要】:业务规则过少管理的重要原因是,将数据质量管理当作一次性工作,疏于发掘与扩张测定数据质量的业务规则。数据库的表和行列以物理数据模型呈现。图4-2数据模型2②业务规则2:商品交付单位表的商品交付合作单位代码是Not Null,且必须为在合作单位表中登录的公司。原因是作为业务规则1和业务规则2导出基础的数据模型2是物理数据模型,而物理数据模型要充分表现其数据业务特性是有局限性的。

信息系统构建和运营管理产业中导入数据质量管理系统现在已被认为是理所应当。最近一般规模的下一代信息系统构建提案邀请书中,数据质量管理体系建立和解决方案导入都包含在内。好像只要导入了数据质量管理系统,数据质量就会自动完善或得到保障,这样的错误认识目前还存在着。数据要像数据一样存在才能称为质量,按照数据的业务特性进行,才能称质量得到了保障。毕竟数据质量比起数据质量管理系统的导入来说,了解业务特点是什么再加以管理更重要。本节介绍了信息系统构建和运营过程中,在数据模型中对数据的业务特性进行系统性管理,连接数据质量管理系统,揭示能够保证质量的方法。

数以千计的表中数以万计的列构成了数据库(DB),为其进行数据质量管理的业务规则(business rule, BR)数如果连几百个都不到,那么数据质量指标能信得过吗?几乎大部分表和列都有固定的业务特性,去哪里找这数百个之多的业务规则呢?

不少企业和公共机关的数据质量管理现状就是这样的。甚至,即使这种状态管理下,要取得数据质量管理认证的部门也不以为然。

数百个业务规则其本身并不是问题。经常会有即使几百个业务规则也满足要求的情况。但跟数以千计的表中数以万计的列比起来,几百个业务规则就少得可怜了。

业务规则过少管理的重要原因是,将数据质量管理当作一次性工作,疏于发掘与扩张测定数据质量的业务规则。数据质量管理体系构成工作,应该建立数据质量管理流程与步骤或以关联解决方案导入为中心进行固定化。

与其说数据模型是介绍数据库表与列的文件,不如说是利用决定数据业务特性的标记法【如IE(information engineering)】并将其格式化。当然,用物理数据模型作为说明数据库的工具就更好了。所以,所谓的精心设计的数据模型,就是因为能够较好表现业务特性,所以通过数据模型能够轻松读取业务特性。

在现场进行的大量信息系统构建项目及接触运营环境的数据模型,仅数据库表和列排放的整齐好看,这样的情况非常之多,令人很心痛。甚至数据模型仅仅达到信息系统构建项目完成的程度,信息系统开放后的运营中再无任何管理的也是不计其数。

数据质量管理的核心是开发和运营定义完善且丰富的业务规则,这样的业务规则相当大的一部分不需要什么努力就可以从数据模型中导出。当然,对于将数据库表和列仅进行排列式管理的企业或机关来说,这样的数据库模型是不切实际的。

下面来比较三个数据模型,三者用不同的方法对同一业务进行设计。

(1)数据模型1。数据库表和行列只进行平面排列展示。这样的数据模型中,要进行数据质量管理的业务规则却不易找到,因此要用其他方法导出业务规则,就必须要进行调查作业,如图4-1所示。

图4-1 数据模型1

(2)数据模型2。数据库的表和行列以物理数据模型呈现。用实体(entity)代替数据库表,用属性代替行列,通过外键(foreign key, FK)中的相应列来表现,如图4-2所示。

在这个数据模型中,可以表现出数据的业务特性,进行如下的数据质量诊断,可导出业务规则。

①业务规则1:发送表的发送合作单位代码是Not Null,且必须为在合作单位表中登录的公司。

(www.chuimin.cn)

图4-2 数据模型2

②业务规则2:商品交付单位表的商品交付合作单位代码是Not Null,且必须为在合作单位表中登录的公司。

但是,通过数据模型2及上述业务规则1、业务规则2,可以推测出合作单位表中发送单位和商品交付单位都已经登录。数据模型中虽无明确表示,但通过合作公司表的合作公司类型码列,可以区分出具有发送功能的公司或具有商品交付功能的公司。如果发送表的发送合作公司代码中,填写了商品交付公司而非发送公司的企业代码,或者在商品交付企业表的商品交付合作公司代码中,填写了订货公司的企业代码,这就成了违背业务规定的数据。如此错误放任不管,那么业务规则1和业务规则2就无法发现此类错误。原因是作为业务规则1和业务规则2导出基础的数据模型2是物理数据模型,而物理数据模型要充分表现其数据业务特性是有局限性的。

(3)数据模型3。该模型是理论数据模型,虽然应称为概念数据模型,但在实际信息系统构建项目中已与理论数据模型通用,故可称为理论数据模型。这就意味着,不管是概念还是理论将从主题中脱离出来,对此不再讨论,如图4-3所示。

通过数据模型3可导出进行如下数据质量管理的业务规则。

①业务规则1:发送表的发送合作公司代码是Not Null,且必须为在合作公司表中部分集合发送公司中登录的公司。识别部分集合的合作公司一栏是合作公司类型代码。

②业务规则2:商品交付公司表的商品交付合作单位代码是Not Null,且必须为在合作公司表中部分集合的商品交付公司中登录的公司。识别部分集合的合作公司一栏是合作公司类型代码。

③业务规则3:合作公司表的是否代理国外发送一栏,合作公司的部分集合中如果仅填写了发送公司,则必须在Y、N中选一个值来表示。

数据模型3作为理论数据模型,通过物理型的数据模型1和数据模型2这样的构造得以实现,以此为前提导出业务规则1、业务规则2、业务规则3。业务规则3包括了Not Null栏的信息及域名信息,以技术方面为先导。

图4-3 数据模型3

对于多达数千个的表及数万个的列,像数据模型3这样业务特性被完美展现、正确设计的话,就能非常丰富而又简单地导出数据质量管理所需的业务规则了。

如上所述,考虑到数据模型尤其是理论数据模型的业务特性,进行详细设计是数据质量管理尤其是丰富正确的业务规则导出的必由之路。著名的计算机工程专业书籍Conceptual Database Design-An Entity Relationship Approach( Batini、 Ceri、 Navathe合著)中提出数据模型必须具备的质量特点,数据模型利用确定业务特性的表示法,且必须最大限度详细呈现,通过这些才能够确保数据模型的可读性(readability)和显而易见性(self-explanation)

许多信息系统构建和运营工作中数据模型的设计以数据库构建为目标。但是,不要仅仅将数据模型当作说明数据库表和列的产物,要将详细表达数据带有的业务特性的企业或机关数据地图合理利用起来。