《实体解析与信息质量》 - 1.1.2 背景介绍

背景介绍

实体和属性的概念源自实体-关系模型（ERM）。实体-关系模型是现代数据模型的核心，同时也是数据库设计的基础。用于描述该模型的图形化的工具实体-关系图（ERD），在数据库项目的开发中，一直被认为是最重要的制品之一。关系模型最早由E.F.Codd于1970年提出，后来在1986年由PeterChen对该模型进行了优化，形成如今的ERM体系结构。在ERM模型中，信息系统被描述为一系列的实体的集合，这些实体拥有各自的属性，并互相关联。

图1.1是一个简单的ER图的例子，它描述了一个包含教师，课程和学生这三个实体的简单实体-关系模型。教师和课程之间的连线说明他们之间存在着某种关联。同样的，课程和学生也是互相关联的。除了表示两个实体有关联以外，连线上的符号还描述了他们之间更为细节的相互关系。比如说，你可以看到在短线交界处的三角线（乌鸦脚），我们用它来表示一个多对一的关系。在这个例子中，它说明一名教师可能要教授多门课程。此外，与乌鸦脚一起的一条短竖线进一步约束他们之间的关系，即每名教师必须教授至少一门课程。教师实体和链接处的两条竖线，表明了他们之间还有一个称作唯一关系的关联约束。这约束表明：每门课程必须分配一名且只能分配一名教师。乌鸦脚符号和一个圆圈在一起表明两端出现的课程和学生实体之间是零对多的关系。这意味着任何学生可能参加几门课程或不参加任何课程。相应的，每门课程可能有数名学生或没有学生报名。

图1.1ER图实例

每个实体类型还包含了一系列的反映该实体特征的属性。比如说，教师实体有职工号，姓名和部门这三个属性。当这些属性赋予了具体的值之后，他们就具体的定义了某一位教师，这位教师被称为现实世界中的一个实体，而上述定义的这样一个实例（或记录）同样也被称为该实体的一个引用。

ERM的一个基本的规则是，每个实例都需要有唯一的标识符。这被Codd（1970）称为实体标识规则。被数据模型选择中的一个或一组具有标识性的属性，又被称为主键，因为这些属性值的组合代表了唯一的一个实体。但是，在设计阶段，特定组合的描述性属性并不一定有这样的标识功能，即使有，他们也可能指向了多个不一样的实体。因此，为了安全起见，数据模型会额外加入一个属性，这个属性并不描述实体的任何特征，但它使得主键更容易生成。举例来说，图1.1中如果使用名字和部门作为教师标识属性，很可能会出现同一部门有两个教师有着相同名字的情况。如果出现这样的情况，那么名字和部门的组合就不能满足主键的要求。然而通过添加职工号这一属性，每个教师实体便拥有了唯一主键值。这称为代理键，这些人造键的值没有内在的意义，比如职工号“T1234”或员工数量的“387”。

这些人造主键必须在该记录被录入到数据库当中时就被创建好，并且在该记录的整个生命周期里，都必须被小心的维护着。只有这样，才能保证它们的有效性。而关于该实体的信息，则可以通过对数据库中的不同表进行联合操作来提供。这样的操作仅仅需要对相同的主键进行匹配就可以完成。

理论上来说，对于任何一个良好设计的数据库系统，实体解析操作都完全不应该成为其问题。因为在这样的系统当中，只有当且仅当两条记录的主键完全相同时，它们才会被认为是同一个实体。

然而一个潜在的问题是，在记录生命周期的漫长的过程中，我们无法保证对该记录的所有操作都被正确地执行了。一旦错误的操作被执行，我们便可能会失去该记录和实体之间的关联。

在涉及到多个数据库之间，甚至哪怕是同一数据库的不同表，只要是对于同一个实体使用了不同的主键，实体解析就会变得困难，可预见的问题也会更加严重。还有一些情况下，我们所用的数据根本就是来自非数据库系统，或者即使是来自数据库系统，却未能包含主键。实体解析在这些场景中，都有着更大的发挥。我们通常把实体解析在多数据库场景下的应用定义为异构数据库联合。

执法部门以及情报机构常常会需要用到实现了异构数据库联合的ER系统。在这些机构当中，通常每个子部门都拥有与自身信息相关的独立数据库，因而也使用着不同的schema及主键来定义实体。实体解析系统在这样的场景中，通常都扮演着枢纽的职能，以连接机构内所有的独立数据库。

举例来说，在某次调查过程中，一个实体的引用被输入到了系统当中，ER系统会立刻对该系统中的所有数据库进行相应的检索，查找任何能够匹配上该实体的数据，并将其进行整合以提供给终端用户。在第五章中，我们会介绍由Infoglide软件公司开发的Identity ResolutionEngine的系统，该系统便很好的提供了我们所描述的枢纽功能。

第七章的时候，我们还会给大家介绍关于ER系统的枢纽架构的未来发展趋势，它可能会成为从不同独立维护系统中分析共通点信息的通用解决方案。