数据集成与数据库集成-分布式数据库技术

2023-10-28 理论教育版权反馈

【摘要】：企业里，ERP系统要将自己的生产数据和供应链数据集成，也要与CRM中的客户数据集成。下面先讨论数据库集成。数据库集成涉及处理参与数据库中信息的集成问题，将参与的数据库从概念上集成起来，形成一个凝聚定义的多数据库。因此，要设计一种合理的和适当的全局概念模式，将这些成分数据库集成为一个多数据库是一个重要的问题。图5.1数据库集成过程第一步，需要把成分数据库模式翻译成一个通用中间体（记作InS1，InS2，…

数据集成（data integration）是一个目前急需解决的问题，无论是对学者、用户和企业来说，都是如此。企业里，ERP系统要将自己的生产数据和供应链数据集成，也要与CRM中的客户数据集成。为了保证产品的质量，制造业的整机厂商也希望将零配件供应商的ERP系统中的相关数据集成到自己的ERP系统里。军事上，战场协同，统一的数据链是能打胜仗的关键，因此，各军种、各兵种、前方和后勤等所有的数据都要集成到一起，构建完整、统一、一致的数据链。P2P系统中，每个节点（peer）之间交换数据的语义转换、消除歧义等的需求也是数据集成问题。

显然，数据集成是普遍遇到的一个问题。下面先讨论数据库集成。

数据库集成（database integration）涉及处理参与数据库中信息的集成问题，将参与的数据库从概念上集成起来，形成一个凝聚定义的多数据库。从数据库设计的角度看，这是一个自底向上的开发过程。从简单意义上看，这是定义和设计一个全局概念模式的过程。

如前所述，数据库集成涉及的是一个自底向上的开发过程。现在的应用形势是，各种应用会陆续先后开发和投入使用，各自都需要数据库的支持。因此，数据库集成时，众多独立的数据库已经存在，新的需求是，要求这些应用能互相交流与协作，从而在它们（独立的数据库）的基础上构建一个全局数据库。这些独立的数据库就成了全局数据库的成分数据库（也称局部数据库）。因此，要设计一种合理的和适当的全局概念模式，将这些成分数据库集成为一个多数据库是一个重要的问题。要解决这个问题，可分两步走：模式翻译（schema translation，或简单称为translation）和模式集成（schema integration）。数据库集成过程如图5.1所示。

图5.1中，每个独立的数据库均是成分数据库，分别记作database1、database2、……、databasen。集成的结果记作GCS，即全局概念模式。它们先通过不同的翻译器（translator）形成相容的内模式（InS1，InS2，…，InSn），然后由集成器（integrator）集成为全局概念模式（GCS）。

具体来说，这些成分数据库之间要进行交流和通信，就需要互相理解。而彼此之间的独立设计、模式与概念理解差异很大。简单来说，数据关系里的某个属性“工资”（salary）在不同的机构（在不同的成分数据库）会有不同的语义，有的是指企业给职工每月的总支出，有的包含奖金与补贴，也有的不包含奖金与补贴，有的市场人员的工资里会包含其每月的业务交际支出，有的区分基本工资、岗位津贴、绩效工资与补贴，等等。要交流、通信，至少要将它们在语义上统一起来。此外，即使在语法上存在大量的异构问题，也需要转换。例如，同样的工资，有的数据库里定义为整数，有的定义为字符串，有的定义为浮点数等。即使都是整数，也有16位整数、32位整数、64位整数的差异；浮点数也存在精度的差异。总之，转换是不可避免的。如何转换呢？如果上述n个独立的数据库一对一转换，则显然需要（n-1）！个转换器，这是不可取的。因此，最好将n个独立的数据库转换成一种通用的中间形态。

pagenumber_ebook=95,pagenumber_book=80

图5.1　数据库集成过程

第一步，需要把成分数据库模式翻译成一个通用中间体（记作InS1，InS2，…，InSn）的正则表示。使用正则表示方便了翻译过程，减少了翻译器的数目。选择正则模型很重要。应该把所有数据库中可用的概念集成起来，这是原则，也是充分条件。值得一提的是，很多研究使用面向对象模型来实现集成。

显然，这里的翻译步骤也是必需的，如果成分数据库是异构的，则必须使用不同的数据模型来定义每个本地模式。所以在图5.1中，每个数据库对应各自的翻译器，分别记作translator1、translator2、……、translatorn。

第二步，把每个中间模式集成为一个全局概念模式，记作GCS。

【例5.1】假设某个大学有一个关系型数据库，由大学的教务处维护，它包含如下关系：

Student(sno，sname，age，dep t，c l ass)

SC(sno，cno，mar k)

Course(cno，cname，c redi t)

Teacher(tno，tname，t i t le)

TC(tno，cno，c l ass room，date)

同时，这个大学的人事部门也使用和维护着一个数据库，主要是关于老师的信息（自然也包含其授课信息），而这个数据库使用实体-联系（E-R）模型描述，如图5.2所示。图5.2中的矩形代表实体，菱形表示实体间的联系，联系的类型使用弧上的标注来描述。例如，Student_Course关系说明从Student实体到Course实体是多对多的。

类似地，Works_in关系说明为一个多对多关系。与常用的方式一样，实体和联系的属性用椭圆表示。

如果以上这两个数据库涉及的是彼此相关的应用域（如面对校长的需求，因为校长同时关注这两个应用域），则要把这两个数据库集成到一起。这样，就需要实施这两步：模式翻译和模式集成。

1.模式翻译

模式翻译指的是将一种模式映射成另一种模式。这要求按照全局概念模式定义对一种目标模式的规格说明，并生成中间模式。

模式翻译的核心是模式映射（schema mapping）。(www.chuimin.cn)

pagenumber_ebook=96,pagenumber_book=81

图5.2　实体-联系（E-R）模型

2.模式集成

模式集成连接在翻译过程后面，通过集成中间模式生成全局概念模式。

模式集成涉及两个任务：同质化和集成。模式集成的思想是保证成分数据库和其他数据库在结构和语义上以同质方式可比。同质化后是将多个数据库的模式进行合并，再建立一种全局概念模式。

（1）同质化（homogenization）。在这个阶段要解决语义异构和结构异构的问题。语义异构这个词我们常用，但定义并不明确。同质化是指数据库之间数据的含义、解释和预期的使用差别。解决语义异构性的一个重要方面是找出命名冲突。基本的命名冲突问题是异名同义和同名异义问题。两个相同的实体，如果它们的名字不同，则称为异名同义。两个不同的实体，如果它们的名字相同，则称为同名异义。

有许多种处理名字冲突的方法。一种是通过模式或模型名来解析同名异义词，但无法采用类似的简单方式解析同义性问题。本体技术是一种可取的方法。本体指定了特殊应用域，定义了词语及其语义，它们在该域上是可接受的。如果该域上的每种数据库模式使用一个共同的本体，则名字冲突就自然而然地解决了。当然，在不同的域上使用本体，还有很多问题需要研究和解决。

【例5.2】假设中间模式采用E-R模型表述，分别记作InS1和InS2。

InS1和InS2之间的同义词关系如表5.1所示。

有四种可能的结构化冲突方式：型冲突（type conflicts）、依赖性冲突（dependency conflicts）、键冲突（key conflicts）、行为冲突（behavioral conflicts）。型冲突发生在使用一种模式里的属性和另一种模式里的实体表示相同对象但分别定义为不同类型（例如一个中定义为整型，另一个中定义为字符串）时。依赖性冲突发生在使用不同联系模式（一对一、多对多）来表示不同模式里的同一件事时。键冲突发生在有不同的候选键可用、在不同的模式里选择不同的主键（primary key）情况下。行为冲突意味着建模机制的不同。例如，从一个数据库里删除最后一项可能会让所包含的实体被删除。

表5.1　InS1和InS2之间的同义词关系

pagenumber_ebook=97,pagenumber_book=82

结构化冲突，如结构间的依赖性冲突，解决办法是采用转换方法。例如，一个非键属性（non-key attribute）可以转换成一个实体，通过在新建实体和代表它的新属性之间建立一个中间联系来实现。

两种模式可以与四种方式相关：可以互相等价；可以一个是另一个的子集；可以是一种模式里的某些成分发生在另一种（模式）里，但要保留某些唯一的特征；也可以是完全不同的、不相干的。

实体之间的联系在E-R模型中十分重要。决定联系的类（class）和型（type）在全局模式设计中是基本的工作，例如，模式的等价性在决定两种模式表示相同的信息时是重要的。因为无法通过语法来识别这些联系，所以必须考虑它们的语义。为了确定一个属性是否与另一个属性等价，需要获取属性蕴含的信息。更复杂的是，一种模式里的一个属性可能作为实体出现在另一种模式的另一个属性里，也代表相同的信息。遗憾的是，同质性问题往往要求人工干预，因为这需要中间模式的语义知识。

如前所述，模式映射，首先需要将翻译的两种模式转换成有共识的中间形态，如面向对象的描述或本体形态等。

（2）集成。集成涉及将中间模式进行合并和重构。将全部模式合并成一种单一的数据库模式，再重构它们，然后创建出“最好的”集成模式。合并要包含参与模式里的信息。

这里，集成步骤是直接的。如果InS1是InS2的一个子集，那么可以将InS2作为集成模式。

合并和重构需满足完整性（completeness）、最小化（minimality）和可理解性（understandability）等条件。如果所有模式的全部信息集成到一种公共模式里，则这个合并是完整的。为了实现完整合并，我们可以使用转包（subletting）和一个实体来描述另一个实体。泛化（generalization）和特化（specialization）可以看成是转包的特例。

如果在模式集成里保留冗余的关系信息，则该归并不是最小的。非最小化模式也会在翻译过程中发生，原因是中间模式不是最小的。

值得注意的是，可理解性是一维因素。实际上，还有许多维度需要在这里解决。

这里讨论的仅仅是传统的数据库集成问题，在Internet时代，情况要复杂得多。在新的数据集成需求中，涉及数据库的集成、数据库和文本文件（系统）的集成、地理信息的集成和多媒体数据的集成等。我们把此时的问题称为互操作问题。

数据集成与数据库集成-分布式数据库技术

相关推荐