CN1190477A

CN1190477A - 修改现有数据库以反映相应对象模型变化的方法和装置

Info

Publication number: CN1190477A
Application number: CN96195335A
Authority: CN
Inventors: 川井健二
Original assignee: Wall Data Inc
Current assignee: Wall Data Inc
Priority date: 1995-07-07
Filing date: 1996-06-03
Publication date: 1998-08-12
Also published as: US5717924A; NO980068L; NO980068D0; AU6251796A; BR9609569A; CA2222583A1; EP0838060A1; JPH10511200A; KR19990028677A; AU703408B2; MX9709100A; WO1997003406A1

Abstract

对象模型包含代表数据被存在计算机系统的关系数据库中的项目的一个或多个语义对象。每个语义对象有定义为每个项目存放的数据的一个或多个部分。对象模型被映射到当前关系数据库模式中。当用户修改该模型时,计算机系统产生一个推荐关系数据库模式,并且确定当前关系数据库模式和推荐关系数据库模式之间的区别。根据当前和推荐关系数据库模式之间的区别,修改关系数据库以反映相应对象模型的变化。

Description

修改现有数据库以反映相应对象模型变化的方法和装置

本发明一般涉及计算机系统，尤其涉及利用关系数据库存储和检索信息的计算机系统。

在某些时候，大多数计算机用户都需要存储和检索某类信息。这通常是利用许多商业化的数据库程序中的任何一个来实现的。这些程序允许用户定义将被存在数据库中的信息的类型，并且为要把数据输入数据库的用户提供格式，以及为希望检索先前所存储信息的人们打印报表。

最流行的一种数据库被称为关系数据库。在关系数据库中，数据按行存在二维表中。每个表有一个或多个列，定义所存储数据的类型。按常规，对于初学者和不熟练的用户来说，很难建立这种关系数据库表(也被称为数据库模式)来准确地反映出用户将如何安排和存储数据的思想。

允许用户建立关系数据库模式的一种新手段是使用一个被称为SALSATM的计算机程序，该程序是由华盛顿州西雅图的Wall Data公司开发的。该程序允许用户对将被存在数据库中的数据建立模型。该模型包括一个或多个语义对象，表示类似人员、定货单、公司或用户可以看作将被存在数据库中的某个唯一实体的其它任何东西的一个完整项目。每个语义对象具有一个或多个属性，存放关于该语义对象以及定义两个或多个语义对象之间关系的对象链接的识别信息。一旦用户完成了语义对象模型，SALSA计算机程序分析该模型，并建立能将数据存在计算机中的对应关系数据库模式。SALSA语义对象建模和模式发生系统的细节见1993年10月29日提出的、系列号为08/145,997的公共转让、共同未决申请的美国专利申请，该专利申请在此将作为参考文献引用。

在现实世界的数据库应用中，要求存在数据库中的数据的类型随时间变化。在建立关系模式时认为很重要的信息，结果对用户却没有什么价值，而其它更重要的信息却不在数据库中，需要以后再增加进去。目前还没有一种商业化的计算机程序允许用户很方便地修改关系数据库模式以删除信息、增加信息或改变数据库中信息之间的关系。因此，为了修改数据库模式，通常需要定义一个全新的模式，并利用转换程序将先前已经存在数据库的数据重新填入新的关系数据库模式中。通常，数据库模式必须由作为数据库建模领域专家的用户来更新。这样做不但费时费钱，而且也挫伤了那些只想在数据库中存储数据、而不关心数据库管理系统内部工作的用户的积极性。

考虑到目前数据库技术存在的问题，需要一种允许用户修改现有关系数据库模式的计算机系统。这种系统在允许用户完成复杂的模式修改时应该是直观的和便于学习的，而这种工作先前则需要在数据库建模专家的帮助下才能完成。

本发明是一种计算机系统，用于修改现有的数据库模式，以便反映在相应对象模型中发生的变化。对象模型包括一个或多个对象，其中的每一个都包括一个或多个描述该对象的分量。对象模型与被存放在计算机系统的存储器中的某个关系数据库模式相关。

当用户修改对象模型时，计算机系统产生一个推荐模式。将该推荐模式和定义现有数据库的当前模式进行比较。检测当前模式和推荐模式之间的变化，并将数据库中每个表应发生的变化组合成一个列表。选择修改表的次序，以便使那些需要被其它表引用的表能在引用其它表的表之前先被修改。

计算机系统进一步确定数据库中某个表的一列是否包括将被移到数据库的另一个表中的数据。当某一列包括将被删除的数据时，对将被加到数据库中的另一个表的同一列进行查找。一旦找到接收数据的表，计算机系统通过将数据移到适当的表中的方式来更新该数据库。

通过结合附图参考下面的详细描述，就能更容易接受并更好地理解本发明上述和其它许多相关的优点，其中：

图1是根据本发明允许用户修改现有关系数据库模式的计算机系统示意图；

图2-8图示如何修改关系数据库以反映在相应对象模型中所发生的变化；

图9A-9F为一系列的流程图，表示由本发明计算机系统所执行的比较两个关系数据库模式的步骤，目的是为了更新现有的关系数据库以反映在相应对象模型中所发生的变化；

图10A和10B为流程图，表示由本发明计算机系统所执行的修改现有关系数据库的步骤；

图11A表示本发明如何对数据库表的变化进行排序以维护数据的完整性；

图11B为流程图，表示由本发明计算机系统执行的、按照最少依赖性次序修改数据库表的步骤。

图11C表示被定义在某种循环关系中的关系数据库表；

图12表示如何将数据从一个图示的表格移到另一个表格以反映相应对象模型所发生的变化；

图12A说明多对多值类型的数据转移；

图12B说明多对1链接类型的数据转移；

图13为流程图，表示由本发明执行的将数据库中的数据从一个表移到另一个表的步骤；

图14A-14C为一组流程图，表示由本发明执行的计算移动路径的步骤；

图15A-15D为一组流程图，表示由本发明执行的修改现有关系数据库以反映在相应的对象模型中所发生变化的步骤。

为了解决在目前技术状态下的数据库管理系统无法让用户方便地修改关系数据库的问题，本发明提供一种通过程序设计更新关系数据库模式以反映在某个相应的对象模型中所发生变化的计算机系统。

现在看图1，该图给出实施本发明的计算机系统的示意图。该计算机系统通常包括中央处理器(CPU)70、内部存储器72和例如磁盘驱动器74这样的永久性存储装置。监视器或显示器76连接CPU，使用户能看到代表存放在关系数据库中的数据的对象模型，关系数据库存在内部存储器并最后放在磁盘驱动器74上。用户使用键盘78和例如鼠标80这样的指向装置建立对象模型。建立对象模型后，计算机程序让CPU分析该模型并且在存储器72中建立相应的关系数据库模式。正如下面将描述的，分析对象模型所发生的变化，并且修改存放在存储器中的数据库模式以反映所发生的变化。

正如在′997专利申请中所充分陈述的，SALSA计算机程序提供了一种简单的方法，通过这种方法，用户能够建立关系数据库表，而不必理解如表格、属性、相交表格、外部关键字、代用(surrogate)关键字等等这样的关系数据库概念。

在SALSA程序中，语义对象被用来表示数据存放在关系数据库的项目。每个语义对象由其包含的属性所定义。简单值属性表示项目的简单特性，例如人员的姓名、年龄、职业等等。组属性集体地定义了语义对象所代表的对象的一个特性，地址就是组属性的一个例子，因为它包括街道、门牌号、城市和州名，集体地定义了一个人所居住的地方。对象链接属性定义了对象模型中语义对象之间的关系。

在′997专利申请中，语义对象被定义为包括一个或多个属性，这些属性可以是简单值、组或对象链接属性。与′997专利不同，语义对象的属性现在称为部分，并且将语义对象简单称为对象。然而，为了以前提出的申请和本说明书的一致性，术语“对象”和术语“语义对象”同义，而且术语“部分”和术语“属性”也是同义的。

虽然′997专利申请中描述的语义对象建模系统允许用户建立数据库模式，却没有提供让用户修改现有模式以反映相应对象模型所发生变化的手段。在本发明中，用户对对象模型的修改可划分为四类。这些类型包括：修改模型中的对象；修改对象中的部分；修改部分的特性；或修改模型中对象之间的关系。对于发生在对象模型中的每种变化，在关系数据库的某个表中必须有相应的变化。

表1给出了用户可以对对象模型中的对象所作的修改以及为了实现该模型的修改而对数据库模式所作的相应的修改。

表1

对象模型变化	数据库模式变化
对象模型变化	数据库模式变化	建立新对象	建立新表格
删除对象	删除表格	建立新对象	建立新表格
删除对象	删除表格	改变对象名	改变表格名

正如′997专利申请中所介绍的，对象模型中的每个对象和存在计算机系统存储器中的某个相应的关系数据库表配对。通常，每个表都与其相应的对象同名。如果用户在模型中增加一个对象，必须在数据库模式中增加一个新的关系数据库表。同样，如果从模型中删除一个对象，则其相应的数据库表从模式中删除。最后，如果用户修改某个对象名，则相应的关系数据库表的表名也随之被改变。

用户可以对数据库进行的第二类修改是修改对象中的部分。表2列出了用户可以对某个部分所作的修改以及在关系数据库表中所作的相应修改。

表2

部分变化	数据库模式变化
部分变化	数据库模式变化	增加单值的简单值或组部分	增加新列
删除单值的简单值或组部分	删除列	增加单值的简单值或组部分	增加新列
删除单值的简单值或组部分	删除列	增加多值的简单值或组部分	建立新表
删除多值的简单值或组部分	删除	增加多值的简单值或组部分	建立新表
删除多值的简单值或组部分	删除	增加单值的对象链接部分	增加新列，定义为外部关键字
删除单值的对象链接部分	删除外部关键字列	增加单值的对象链接部分	增加新列，定义为外部关键字
删除单值的对象链接部分	删除外部关键字列	增加多值的对象链接部分	若为多对多关系则建立新的相交表格否则增加新列作为外部关键字
删除多值的对象链接部分	删除相关表格或外部关键字列	增加多值的对象链接部分	若为多对多关系则建立新的相交表格否则增加新列作为外部关键字
删除多值的对象链接部分	删除相关表格或外部关键字列	增加父类型部分	增加新列，定义为外部关键字
删除父类型部分	删除外部关键字	增加父类型部分	增加新列，定义为外部关键字
删除父类型部分	删除外部关键字	增加/删除子类型组部分	没有变化

图2-8图示了能对某个对象中的部分所作的修改以及数据库模式所发生的相应变化。正如将要看到的那样，在计算机系统的显示器屏幕上修改对象模型，而在计算机系统的内部存储器中执行对数据库模式的修改。

图2给出当用户增加单值的简单值或组部分到某个对象时关系数据库表所作的修改。这里对象100代表一个雇员，该对象包括三个简单值部分：“姓名”、“地址”和“SOC_SEC_NO(社会保险号)”部分，唯一地识别存在数据库中的雇员对象的一个实例的部分由部分名左边的一对星号所指示。

正如′977专利申请中所提出的那样，雇员对象100在数据库中被表示为关系表105。表名匹配对象100的名，该表格有三列：姓名、地址和社会保险号。雇员表中的社会保险号列被选择作为该表的主关键字以引用某个唯一的雇员。数据库维护定义该表主关键字的列的记录。此外，大多数数据库还保持某个列是否为对数据库中另一个表格的外部关键字的记录。

当用户增加一个新的单值的简单部分到对象时，相应的关系表105必须被更新。这里，用户增加一个表示雇员生日的标号为“BIRTHDAY”的部分到雇员对象。该部分是单值的，因为假定一个雇员只能有一个生日。为了将该信息存在数据库中，列107被加到雇员表105上，列107和被加上的部分同名。列107被定义来保持由生日部分所定义的数据，即日期。

正如将看到的那样，如果用户从对象中删除某个单值的部分，则从表格中删除相应的列。如果用户删除的是唯一地识别对象的某个实例的单值部分，例如标号为“社会保险号”的部分，则该表格的主关键字也将被删除。在这种情况下，产生代用关键字列并加到该表格上。

将一个多值的部分加到对象的效果如图3所示。对象110，代表一个学生，包括三个简单值部分：“学号”、“地址”和“电话号码”。学生对象110和相应的关系数据库表112相关，该表格有三列，对应该对象中三个部分中的每一个。在图3所示的例子中，用户把一个标号为“主课_0.N”的多值简单值部分加到学生对象110上。该部分被显示在屏幕上，其中最小基数零表示学生可能还没有选择任何主课，而最大基数N则表示学生可能选择多于一门的主课。

多值部分存放在关系数据库内独立的表格中，因此，将多值部分“主课_0.N”加到学生对象110上将导致建立表格114。表格114和被加上的部分同名。该表有三列：第一列存放代用主关键字，第二列存放学生的主课，第三列存放对学生112表的外部关键字。具体来说，学生表格112的主关键字(即，存放在标号为“学号”列中的那些值)被用作表114中的外部关键字由此提供一种用于查找表114的机制以确定和某门特定的主课有关的每个学生，并且提供了查找表112以确定每个学生主课的方法。

如果用户从对象中删除一个多值的简单值部分，则从数据库中删除相应的表格114。

当用户增加单值的对象链接部分到对象模型中的某个对象时，发生在关系数据库模式中的变化如图4所示。这里，对象模型包括表示经理的对象120和代表秘书的对象122。增加对象链接部分118到经理对象120以定义经理和秘书之间的关系。对象链接部分118具有最小基数零，表示经理不需要秘书，而最大基数1则表示经理最多可以有一个秘书。将对象链接118放在经理对象120中自动导致产生相应的对象链接124并加到秘书对象122上。

表126表示关系数据库中的经理对象120。该表包括三列，存放经理的姓名、工资和地址。表128用来表示秘书对象，至少包括四列，存放具体某个秘书的姓名、地址和工资，此外，表128还包括一列，标号为“Wpm”，存放秘书每分钟能够打印的字数。

增加单值的对象链接118到经理对象120，导致列130被加到表126上。列130标号为“姓名_1”，以便将其和标号为“姓名”的列区别开来。列130存放对关系表128的外部关键字。如上所述，所选择的外部关键字被定义以便为相应的表格引用主关键字(即，姓名)。

将列130增加到表126上，使得数据库管理系统查找表格以便确定哪个经理和某个特定的秘书相关，以及反过来查找。应该注意到，对于一对一的关系来说，外部关键字可以被加到任一表上。为了一致，本发明总是将外部关键字加到相应于用户首先已经将对象链接部分放在其中的语义对象的表格上，如果对称的、或具有所需的链接，或具有单值组部分中的对象链接。

从经理对象120中删除对象链接部分118或从秘书对象122中删除对象链接部分124将导致从关系表126中删除外部关键字列130。

和图4所示的对象模型修改不同，图5给出了当用户将多值的对象链接部分加到对象时，关系数据库所发生的变化。这里，对象模型包括代表一本书的对象134和代表作者的对象136。将多值的对象链接部分138加到书对象134上表示一本书可以有多个作者并且一个作者可以写出几本书。当多值的对象链接部分138被加到对象134时，相应的多值对象链接部分140被自动建立并且被放在作者对象136中。

为了表示书对象，相应的关系表144在数据库中被建立。该表有三列，对应书对象134中三个部分中的每一个。关系表146对应作者对象136，由于作者对象136中没有一个部分唯一地识别某个特定的作者，表146包括代用关键字的列，该列为表146的主关键字。

在对象134中增加多值的对象链接部分138导致相交表格148的建立。该表包括两列，存放表144和146的主关键字。相交表148使得数据库管理系统能够确定数据库中任何一本书的作者，并且确定某个特定的作者已经写了哪些书。

从书对象134中删除多值的对象链接部分138将导致从数据库模式中删除相交表格148。

图6表示当用户在对象模型中的两个对象之间建立父/子类型关系时、数据库是如何被修改的。例如，如果用户有代表雇员的对象150和代表经理的对象152，用户可以通过将父类型的对象链接部分154放在经理对象152中来表示经理“是一个”雇员。父类型对象链接部分由部分名右下方的下标“P”指示。将父类型对象链接部分154放在经理对象152中将自动导致被放在雇员对象150中的相应的子类型对象链接部分156的建立和插入。

为了表示关系数据库中的雇员对象150，建立两列的关系表158，存放雇员对象150两个部分的值。为了表示经理对象，建立两列的关系表160，存放经理对象中每个部分的值，以及作为该表主关键字的代用关键字列。将父类型的对象链接部分154加到经理对象152在数据库中通过在表160中增加列162来表示。列162包含表158的外部关键字。如上所述，所选外部关键字最好是相应雇员表158的主关键字。

从经理对象152中删除父类型对象链接部分将导致从表160中删除列162。

除了修改对象中的部分，用户也可以修改部分的特性。如′977专利申请书中所述，特性定义允许存放在数据库的列中的值。表3给出能对对象中的部分的特性所作的修改以及发生在数据库中的相应变化。

表3

部分变化	相应数据库模式变化
部分变化	相应数据库模式变化	改变部分名	改变表或列名
将部分的最大基数从一修改到多	删除列，用外部关键字和代用关键字建立新表	改变部分名	改变表或列名
将部分的最大基数从一修改到多	删除列，用外部关键字和代用关键字建立新表	将部分的最大基数从多修改为一	删除表和外部关键字，增加新列
将对象链接部分的最大基数从一修改到多	如果一对多则在相关表中键立外部关键字，如果多对多则建立相交表	将部分的最大基数从多修改为一	删除表和外部关键字，增加新列
将对象链接部分的最大基数从一修改到多	如果一对多则在相关表中键立外部关键字，如果多对多则建立相交表	修改部分的最小基数	修改NULL(空)限制
修改部分的ID状态(即唯一性)	修改UNIQUE(唯一性)限制	修改部分的最小基数	修改NULL(空)限制
修改部分的ID状态(即唯一性)	修改UNIQUE(唯一性)限制	修改简单值部分的值类型	修改数据类型
修改部分的缺省值	修改缺省值	修改简单值部分的值类型	修改数据类型

正如从表3中所看到的，用户可以对部分特性所作的许多修改包括简单地重新定义一列或存放在关系表的列中的数据类型。然而，某些部分修改增加或删除表和/或列。

图7表示当用户重新定义某个单值的简单值部分为多值部分时数据库的变化。这里，对象模型包括代表学生的对象170。对象170有四个部分，标号为“学号”、“姓名”、“地址”和“主课_0.1”。主课部分的最小基数为零，表示学生可以不报一门主课，主课部分的最大基数为1，表示学生最多有一门主课。为了将学生的数据存在数据库中，在计算机存储器中建立关系表172。该表至少有四列，表示学生对象中的每个部分。

如果用户将主课部分的最大基数从1改为N，由此表示学生可以有一门以上的主课，表172被重新格式化。具体来说，从表172中删除标号为“主课”的列并且建立新表176以存放学生主课的多个记录。表176包括三列，一列存放学生的主课，例如“英语”、“历史”、“数学”等，第二列存放对学生表格172的外部关键字，最后一列存放代用关键字，作为表176的主关键字。

在数据库中实现对主课部分最大基数从N到1的修改，与图7所示处理过程的相反。

图8表示当用户将对象链接部分的最大基数从1修改为N时数据库发生的变化。在所示的对象模型中，对象180代表某所大学的一个教授。教授对象有三个部分，标号为“姓名”、“年龄”和“系别”，代表关于一个教授的存储数据。此外还有一个标号为“学生咨询者”的对象链接部分，链接教授和学生对象(没有表示)，由此表示某个教授是某个学生的导师这样的事实。对象链接部分的最小基数为零，表示教授可以没有被指导的学生。被指导学生对象链接属性的最大基数为1，表示教授至多有一个被指导的学生。

为了在数据库中表示教授对象，建立一个三列的关系表182，对应教授对象中的三个部分。此外，表182还包括一列，存放来自对应的学生表格186的外部关键字。

当被指导学生对象链接属性的最大基数从1改为N时，表示一个教授可以有多个被指导者，关系表182的外部关键字列184被删除，接着将存放来自关系表182的外部关键字的列188加到存放学生数据的关系表186上。

在两个对象都互相有多值链接的情况下，建立具有对这两个对象表的外部关键字的相交表格。

用户能做的最后一类对象模型修改是改变一个表的限制条件。虽然在对象模型上没有明确表示，用户可以改变被选为主关键字的表格的列。表4给出当用户修改表格的主关键字时必须进行的相应修改。

表4

表的限制条件	相应表格修改
表的限制条件	相应表格修改	修改主关键字	修改主关键字并更新相应的外部关键字
修改主关键字类型(数据/代用)	修改主关键字并更新相应的外部关键字并/或删除代用关键字	修改主关键字	修改主关键字并更新相应的外部关键字

通过重新定义关系数据库表中的一列以及任何相关表对应的外部关键字列来改变表格中的主关键字。

为了确定计算机存储器中或存放在永久性存储介质上的数据库模式应该如何被更新，当用户修改时，需要将对应该对象模型的关系数据库推荐模式与当前数据库模式预先存放的定义进行比较。确定这两个模式之间的区别并据此修改现存的关系数据库。

为了存放推荐和当前模式的表示形式，本发明建立了一种存放在计算机的内部存储器以及计算机的永久性存储装置上的数据结构。该数据结构包括数据库中每个表的定义以及表中每一列的定义。当对象模型被分析以建立关系数据库模式时，推荐模式的数据结构被完成。

在本发明最佳实施例中，存放当前模式表示形式的数据结构由下面的C++类的实例(instance)组成。然而，那些熟悉计算机程序设计技术的人将认识到，也可以用其它的数据结构来存放这些模式定义。另外，也可以使用其它的程序设计语言。应该注意到，下面提供的类定义只包括某个类的相关成员变量。虽然没有明确给出类的成员函数，但是从本发明下面的介绍和附加流程图中的描述来看是很明显的。

class Schema

{

tableList； //列出对应对象模型中每个对象的所有表格

}；

模式类包括表格定义的一个列表，分别对应对象模型中的每个对象。被建立用来存放多值部分实例的表格和相交表格不包括在该列表中。表格的列表中的每个元素包括对相应关系数据库表的完整定义。

下面TableDef类的实例用来存放数据库模式中每个表格的定义。

　　class TableDef

　　{

　　table_Id；        //赋予该数据库表的唯一性标识符

　　columnList；      //该表中列项目的列表(类型为

　　                    DataColumn，KeyColumn，GroupCloumn，或

　　                    ForeignKey)

　　*parentTable；    //如果能用，对父表格的指针

　　tableList；       //列出属于该表的子表

　　relationList；    //列出对其它表格的关系

　　indexList；       //列出为该表所定义的索引

　　primaryKeyType；  //TableKeyType的用户说明

　　primaryKey；      //定义为主关键字的索引

　　tableName；       //初始名，可以和对象名相同

　　newTableName；    //用在数据库中的实际表名

　　tableType；       //显式表类型(即对象、多值部分或相交)

　　hDBObject；       //到对象模型中相应对象的句柄

　　}；

正如可以看到的，TableDef类包括成员变量，存放表中各列的信息、对父表的指针(如果有的话)、属于该表的任何子表，以及表格之间的关系。此外，该表的主关键字和关键字类型也被说明。

关系表中每列的信息被存储作为类DataColumn、KeyColumn、GroupColumn或ForeignKey的实例。所有这些类都和下面定义的一个公共基类ColumnDef相关。

class ColumnDef //存放数据库中每列信息的基类

{

Col_Id； //赋予数据库中每列的唯一标识符

nullAllowed； //TRUE-可选，FALSE-必须

idStatus； //唯一性：非唯一、唯一或主关键字

columnName； //数据库中赋予的列名

hDBProp； //到模型中相应对象部分的句柄

colType； //数据列、关键字列、组列或外部关键字列

}；

实际上没有建立该类的实例，而该类仅用来存放下面派生类的公共成员变量。

class DataColumn：public ColumnDef

{

valueType； //在相应对象模型中说明的数据类型

dataType； //在数据库中说明的数据类型

logicalLength； //当可用时在模型中说明的数据长度

dataLength； //当可用时在数据库中说明的数据长度

scale； //当可用时在数据库中说明的精确长度

}；

DataColumn类的实例保存关于关系数据库表中存有数据的任何列的信息。

如果一列被定义为表格外部关键字的成员，则与该列相关的信息作为下面类的实例被存储。

class KeyColumn：public DataColumn

{

*pRefColumn； //到被父外部关键字引用表中相应列的指针

}；

由于大部分数据库程序无法识别关系表中的列组，与逻辑上被组织为一组的各列有关的信息作为下面类的实例被存储：

class GroupColumn：public ColumnDef

{

columnList； //列出一组中的列成员(可能的类型有：

DataColumn，GroupColumn，ForeignKey)

}；

最后，涉及表格中任何外部关键字关系的信息作为下面类的实例被存储。外部关键字是从GroupColumn类中派生的，因为表的外部关键字可以包括多个列。然而外部关键字的columnList成员被限制在KeyColumn类的实例。

class ForeignKey：public GroupColumn

{

*pReferenceTable； //指向出现该外部关键字的最初表格的指针

}；

当分析对象模型以定义推荐数据库模式时，上述各类的实例被建立和初始化。

存放在上述数据结构中的数据库模式对应用户修改过的对象模型。推荐模式和描述存在计算机存储器中的数据库的模式进行比较。为了便于本发明的说明，将原有数据库定义叫做当前模式。描述当前模式的数据结构被存在计算机内存或计算机的永久性存储装置上。在用户完成了一系列对对象模型的修改之后，从永久性存储装置中将当前模式的数据结构重新调入内存，并且和定义推荐模式的数据结构进行比较。

现在看图9A-9F，图中给出由本发明的计算机系统执行的比较两个数据库模式的步骤。如上所述，每个模式被存储为定义数据库中的表格、每个表中的列以及表中的任何关键字(主关键字或外部关键字)的数据结构。

从步200开始，计算机系统重新调入推荐模式数据结构和当前模式数据结构，并将这些数据结构放在计算机的内部存储器中。在步204，计算机开始一个循环，在该循环中，将当前模式的tableList中列出的每个表和对应的推荐模式tableList中的每个记录进行比较。在步208，确定当前模式中的表是否具有空的子表列表，如果不空，对子表列表中的每个表调用将要介绍的表格比较子程序。该递归操作继续直到发现具有空的tableList的表格。

在步214中，模式比较子程序确定是否在推荐模式中发现当前模式的表格。如果没有，用户必定已从对象模型中删除该对象或多值部分，并且在步218从关系数据库中删除该表格。

如果在推荐模式中找到该表，比较子程序开始循环，在步216中对为某个特定的表定义的columnList中的每列进行分析。在步220中，确定该列是否类型为GroupColumn的列。如果是，在步216为columnList中的每列调用比较子程序，以便跟踪组中的各个列。在步224中执行该递归操作，直到一组中的所有列都被处理。

现在看图9B，一旦找到不在组中的列，计算机系统就确定该列的类型是否为DataColumn或KeyColumn(步228)。如果一列被定义为这两种类型之一，处理过程进入步232，确定当前模式中的该列是否在推荐模式中被找到。这可通过在定义在推荐表格中的columnList中查找具有相同Col_Id号的列来实现。如果在推荐表中没有找到该列，准是用户已经执行了对象模型修改，导致从正考虑的表中删除该列。在从表中删除该列之前，计算机系统必须确定该列是否包括将被移入其它表中的数据。该处理过程如图13所示，并将在下面介绍。在执行图13所示的步骤之后，考虑在步236从当前表格中删除该列。

正如下面所要进一步详细介绍的，将要对相应的数据库所作的任何修改都不是立即进行的。而是将所有对数据库表的修改都存起来，直到当前和推荐模式已经完全被比较。到那时才对数据库中的表格进行修改。

如果在当前模式的某个表中和推荐模式的某个表中都发现同一列，计算机系统在步240中确定该列的dataType、logicalLength、nullAllowed、columnName、dataLength和scale特性在当前模式中是否和在推荐模式中相同，如果不同，在步244中更新该列的特性。

在步248(图9C)中，计算机系统确定正被分析的列是否为ForeignKey类型，如果是，计算机系统则确定该关键字是否在推荐模式的表格中(步252)。如果该关键字不在推荐模式中，则计算机系统必须确定该列是否包括将利用图13中由框254表示的步骤被移入数据库另一表格中的数据。接着在步256将该关键字标记为将从当前数据库的表格中删除。

如果该关键字同时存在当前模式和推荐模式的表格中，计算机系统在步260比较并更新定义外部关键字的成员关键字列，其方法和上述步240和244的方法相同。

在步264中，计算机系统确定当前表格的columnList中的所有列是否均已经被分析。如果还没有，计算机系统循环回到216(图9A)，并且分析当前表格的columnList中的下一个项目。

一旦当前模式某个表中的所有列全被分析过，计算机系统在步268(图9D)确定是否存在推荐表中有的、而在当前表中却找不到的列，如果有的话，步272在正被分析的数据库表中加入这些列。

在当前表中的所有列都已经被分析过后，计算机系统在步276开始一个循环，分析为某个特定表维护的indexList中的每个索引。在步280中，确定是否找到当前模式的indexList中某个项目并且和推荐模式的对应项目相同。如果当前模式中的索引在推荐模式中没有找到，则将其删除。如果不相同，则在步284中更新indexList中的该项目。步288确定是否indexList中的所有项目都已经被分析，如果不是，处理过程返回到步276并分析索引表中的下一个项目。在步288之后，在当前表格中没有找到的推荐表中的任何遗留索引都被建立。

在步292(图9E)中，计算机系统确定当前模式中表的主关键字是否和定义在推荐模式中的表的主关键字相同，如果不同，在步296中更新当前数据库中表的主关键字。如果新的主关键字的数据不合格，即，或者非唯一或者包含空值，将出现错误状态。

接着计算机系统确定当前模式中表的tableName特性是否和定义在推荐模式中的tableName相同(步300)，如果不同，步304更新当前数据库中该表的表名。

在步308中，计算机系统确定tableList中的所有项目是否已经被分析过，如果没有，系统循环回到步204(图9A)，并且用上述的方法分析下一个表。一旦所有的表都被分析过，计算机系统在步312(图9F)确定是否有在推荐模式中而不在当前模式中的任何表格，如果这样，步316将这些表加到当前数据库中。

如上所述，对当前数据库关系表的修改被存在将被执行的一个动作列表中，每个将被执行的动作作为对对象模型中的某个对象的部分修改的结果被加到列操作、索引操作或外部关键字操作的一个列表上，该表由下面类的实例维护：

　　class SPTable

　　{

　　//定义表操作

　　  Create()；

　　  Drop()；

　　  ChangeName(oldName)；

　　//定义将项目加到columnOperationList的列操作

　　  AddColumn(pColumn)；

　　  DropColumn(currentColumnName)；

　　  ChangeColumnName(pNewCol，oldColumnName)；

　　  ChangeColumnConstraint(pColumn)；

　　  ChangeColumnDataType(pColumn)；

　　//定义将项目加到indexOperationList的索引操作

　　  AddIndex(pIndex)；

　　  DropIndex(currentIndexName)；

　　  ChangeIndexConstraint(pIndex)；

　　//定义将项目加到foreignKeyOperationList的关键字操作
				
				<dp n="d17"/>
　　  ChangePrimaryKey()；

　　  AddForeignKey(pForeignKey)；

　　  DropForeignKey(currentForeignKeyName)；

　　//建立/替换表函数            //执行类型

　　  CreateIt()；               //建立

　　  DropIt()；                 //删除

　　  Alter0()；                 //替换

　　  Alter1()；                 //REPLACE_NEWNAME

　　  Alter2()；                 //REPLACE_SAVEDATA

　　  AddIndex()；

　　  DropIndex()；

　　  AddForeignKey()；

　　  DropForeignKey()；

　　//基SPTable数据成员

　　  oldName；                  //定义在数据库中的最新表名

　　  columnOperationList        //列替换操作列表

　　  indexOPerationList         //索引替换操作列表

　　  foreignKeyOperationList    //外部关键字替换操作列表

　　  ExecutionType；            //表替换操作的当前方式

　　  *pTableDef；               //指向新表定义对象的指针

　　  *pDMTable；                //指向临时表定义的指针

　　  }；

从类定义中可以看出，类SPTable包括一系列列、索引和关键字的定义方法。各个方法分别用于将适当的数据加入columnOperationList，indexOperationList和foreignkeyOperationList。此外，该类还包括几个生成/改变表的方法，以使计算机系统能完成数据库的修改，例如生成一个表或删除一个表，以及完成重新定义一个表中的列的修改。完成这些方法的具体操作需要一系列SQL语句，视计算机系统用于操作和控制基本关系数据库的数据库管理系统的不同，这些SQL语句可能不同。例如，计算机可能运用Microsoft Access^或Borland Paradox^或其他公用关系数据库程序来操作所述关系数据库。在本发明中，用户需确认所用的数据库编程的类型，计算机由此选出用于完成所需任务的适当的例程。

并不是所有的数据库系统都以同样方式支持操纵表的SQL命令。例如，有的数据库命令不允许在一个表生成之后改变该表的名字。因此，本发明必须根据控制基本关系数据库的数据库管理系统的能力来调整选取的具体SQL命令，以完成一个操作。对任一特定的数据库所进行的一个操作必须使用的方式列于一个映射数据结构中，该数据结构在计算机系列被告知用户所用的是哪一个数据库之时被装入存储器。下表中给出了将对一个关系数据库表所作的改变与完成一个操作的几种方法之一联系起来的一个映射的例子。

表5

操作类型	执行类型
操作类型	执行类型	生成新表	CREATE
删除当前表	DROP	生成新表	CREATE
删除当前表	DROP	改变表名	REPLACE_NEWNAME
增加新列	ALTER	改变表名	REPLACE_NEWNAME
增加新列	ALTER	增加新需列	REPLACE_SAVEDATA
删除当前列	ALTER	增加新需列	REPLACE_SAVEDATA
删除当前列	ALTER	改变列名	ALTER
改变列约束	REPLACE_SAVEDATA	改变列名	ALTER
改变列约束	REPLACE_SAVEDATA	改变数据类型	ALTER
增加新索引	ALTER	改变数据类型	ALTER
增加新索引	ALTER	删除当前索引	ALTER
改变索引约束	ALTER	删除当前索引	ALTER
改变索引约束	ALTER	增加新外部关键字	REPLACE_SAVEDATA
删除当前关键字	REPLACE_SAVEDATA	增加新外部关键字	REPLACE_SAVEDATA
删除当前关键字	REPLACE_SAVEDATA	改变索引外部关键字	REPLACE_SAVEDATA
转移数据	REPLACE_SAVEDATA	改变索引外部关键字	REPLACE_SAVEDATA

表5将对关系数据库所需进行的改变映射到在SPTable类中定义的5种不同生成/改变表方法中的一个。这些方法被标记为：CREATE，DROP，ALTER，REPLACE_NEWNAME和REPLACE_SAVEDATA。对不同的数据库，每种方法有不同的定义。例如，用于由Microsoft Access^生成的数据库的REPLACE_NEWNAME例程的定义可以同用于由Borland Paradox^生成的数据库的相应例程的定义不同。

为改变数据库中的一个表，计算机系统选出一个表改变方法，并将一个所需的操作加到对一个表所需完成的操作系列中。例如，为将一列加入一现存数据库表中，计算机系统调用方法SPTable∷AddColunm(pColumn)。该方法在columnOperationList中加入一项，告诉计算机系统增加一个由指针参量标明的列。此外，方法SPTable∷AddColumn(pColumn)利用表5将ExecutionType(执行类型)成员变量设置为ALTER。ExecutionType将保持在ALTER，直到另一个操作将ExecutionType变量换为另一个较高级别的类型。例如，方法SPTable∷ChangeColumnConstraint(pColumn)将ExecutionType设置为REPLACE_SAVEDATA。在本发明实施例中，最高级别的执行类型是REPLACE_SAVEDATA，其次依次为REPLACE_NEWNAME，ALTER，DROP和CREATE。

大部分商业关系数据库管理系统都提供有用于生成和删除关系数据库表的标准化SQL结构。因此，CreateIt()和DropIt()方法对于不同数据库类型来说变化并不大。但是，相应于ALTER，REPLACE_NEWNAME和REPLACE_SAVEDATA例程的方法对不同的数据库管理系统来说则可能不同。

ALTER方法用于支持适度复杂的数据库改变的数据库。所述数据库可支持在现有表中加入列、对数据库中的列/表进行重新命名及重新定义一个表中的(主和外部)关键字的SQL语句，而不需重新定义整个表。

REPLACE_NEWNAME方法用于可在不对整个表重新定义的情况下重新命名一个表的数据库管理系统。

图10A给出了使用REPLACE_NEWNAME执行方法时，为完全地定义关系数据库内的一个表，计算机系统完成的步骤。由步320开始，生成一个具有新名字的新数据库。在步324，旧表中的数据复制至该新表中。在步328，从数据库中删除该旧表。

如果数据库管理系统不支持使用一简单的语句来完成某一操作，则必须用较复杂的方法。图10B给出了使用REPLACE_SAVEDATA执行方法所完成的步骤。从步332开始，在没有任何关键字约束情况下在数据库中生成一个与推荐的表具有相同定义的临时表。在步336，数据从现存表移入所述临时表。在步340，从数据库中删除原表。在步344，在数据库中生成一新表，然后将数据从临时表复制到新表(步348)。最后，临时表被从数据库中删除(步352)。

可以看出，图5所示及如上所述的映射，根据控制基本关系数据库的具体数据库管理程序所支持的SQL特征，决定用哪一个执行例程来改变一个表。

为保持数据库内的数据完整性，对表的修改次序是很重要的。在本发明的该优选实施例中，具有主关键字(这些主关键字在其他表中是被引用的外来关键字)的表必须在包含所述外来关键字的表之前被修改。如上所述，修改数据库中的每个表所需的操作作为SPTable类的实例被存储。这些实例以正确的顺序存放在一个列表中，以保持数据完整性。

图11A表示包括多个相应于SPTable类的实例的登录项的ChangeTableList380。每个登录项分别对应于表382、384、386和388。表382包含一主关键字，但不引用任何其他表。表384包括一个对表388的外部关键字，而表388包含一个对表386的外部关键字。为了不违背数据完整性约束，具有被另一表中的外部关键字引用的主关键字的表必须在包含该外部关键字的表之前被修改。这种排序模式被称为最小依赖顺序(least dependent order)。

在本发明中，SPTable类的实例的最小依赖顺序插入一个列表中。与其他表没有关系的表可插入该列表的任何位置，而含有外部关键字的表则必须在其引用的表之后被修改。在图11A所示的例子中，表386必须在表388之前被修改，而表388则必须在表384之前被修改。表382可在任何时刻被修改。

图11B给出了本发明中为把SPTable类的实例以最小依赖顺序插入列表ChangeTableList中所采取的步骤。计算机由步骤400开始，分析将被插入ChangeTableList的SPTable类的每个实例。在步骤402，计算机系统开始一个循环，分析ChangeTableList中已有的每个登录项。在步骤404，计算机系统判断所述列表中已有登录项是否含有对将被加入该表的登录项的活动外部关键字。若不含有，计算机系统判断所述列表中的已有登录项是否全部被分析过(步骤406)。若步骤406中的结果是“否”，则计算机系统循环回至步骤402，并分析ChangeTableList中的下一个登录项。若步骤406中的结果是“是”，则新登录项加至所述列表之尾(步骤408)。

若步骤404中的结果是“是”，即意谓着所述列表中已有的一个登录项含有对将被加入该列表中的登录项的活动外部关键字，则所述新登录项被加在含有所述外部关键字的登录项之前(步骤410)。

在步骤412，计算机开始一个循环，分析位于新加入的登录项之后的每个登录项。在步骤414，计算机判断新加入的登录项是否含有对该列表中位于其后的登录项的外部关键字。若有，计算机系统将被新加入的登录项引用的登录项移至含有所述外部关键字的新加入的登录项之前的位置(步骤416)。若步骤414的结果为“否”，计算机系统判断ChangeTableList中的所有余下的登录项是否均已被分析(步骤418)。若结果是“否”，计算机系统循环回至步骤412。若已到达列表的结束处，计算机系统判断是否所有的SPTable类的实例都已被加入列表(步骤420)。若不是，计算机系统循环回至步骤400，将下一个新登录项加入列表。

一旦SPTable类的所有实例已经被加到ChangeTableList上，步422将该表标识为完整的。在执行完图11B所示的步骤之后，数据库表被设置为按保持数据完整性的次序修改。

上述排序模式的唯一例外是当表格的设置互相具有循环依赖性时。图11C说明三个表T1、T2和T3之间的这类关系。当特定的数据库系统通过简单SQL语法支持增加和删除关系表的外部关键字定义来删除或增加外部关键字，而不必要重新定义该表格。通过首先在修改其他的表格定义之前删除被影响的外部关键字定义、然后保存全部所需的关系，就能够处理任何循环关系。在删除外部关键字关系后，代表表格中将被执行操作的SPTable类的实例可以被插入在ChangeTableList中的任何点上。当不具备这种可选性时，该表格可按任何次序修改，并且不能说明定义某个循环关系的任何关系。定义被影响的表格使之具有存储被输入数据的相应关键字列，但这些列不能说明为外部关键字。

数据库中正在被修改的许多表格将包含以前存放的数据。因此，存在这样的模式修改：数据必须从一个表格被移到另一个表格，以便准确地反映用户对相应对象模型所做的修改。这被称为数据移动。

通常，当数据列将要从表格中被删除时，指定数据移动的实例。因此在图9B所示的步236之前，计算机系统确定将从表中删除的列是否包含数据。当从数据库中删除ForeignKey(外部关键字)列时，在步256删除该列之前，计算机确定该列是否包含数据。

为了更好理解计算机系统将数据从一个关系表移到另一个关系表的方法，图12给出要求数据移动的对象模型和相应关系表的表示形式。对象模型包括三个对象500、510和520，分别代表办公室、雇员和经理。对象500和关系表530相关，对象510和关系表540相关，而对象520则和关系表550相关。

在所示的例子中，用户已经将一个标号为“电话”的简单值部分从对象500中移出并将其放入对象510。同样，标号为“姓名”的简单值对象也已经被从对象520移到对象510。每个部分和存放在相应表格530和550中的数据相关。

为了表示对象模型的变化，数据必须从两个源表格530和550移到目标表格540。这是通过建立一个临时表格(图中未给出)来实现的，该表格分别接收可以被存在目标表中的任何现有数据(即存放在表540中标号为“社会保险号”的列中的数据)以及存放在源表格530和550中标号为“电话”和“姓名”的列中的数据。在数据已经被移到临时表格后，表530和550的标号为“电话”和“姓名”的列可以从数据库中删除。原始表格540被删除，新表540′被建立，而临时表格中的数据被复制到新表540’。最后，删除临时表格。

图13表示由本发明的计算机系统执行的将数据从一个表移到现有数据库中的另一个表上的一些步骤。从步450开始计算机系统判别将从表格中删除的列是否包含数据。正如那些熟悉这门技术的人所理解的那样，这是用一个返回一列中的行数的SQL语句来实现的。如果该列包含数据，在步452中，计算机系统将在包含将被删除列的表的任何父表格中查找具有相同列标识符号的列。

在步456，计算机系统判定具有和将被删除列相同的列标识符号的列是否被找到。如果步456的结果为否并且所述列标识符没有被找到，计算机系统开始查找一些对象表格，这些对象表格通过外部关键字和包含将被删除列的表相关(步458)。步460判定在相关表格中是否发现具有和被删除列相同的列标识符的列。

一旦在数据库中的另一个表格中找到将被删除的列，计算机系统在步462中产生下列类DMData或DMForeignData中一个的实例。

class DmData

{SourceTable； //数据来自此DestTable； //接收数据的表格SourceCol； //提供数据的列DestCol； //接收数据的列MigrationType； //1对1、1对多，等等DataType； //值或链接Migrationpath； //源表和目标表之间外部关键字关系的列表}；

DMData类用来存放有关包含将从一个表移到另一个表的数据的列的信息。移动路径指定一系列与目标表和源表相关的表格。移动路径是对每个表和到该列表中的下一个表格的外部关键字关系的一张数据结构列表。下面更详细地介绍计算机系统计算移动路径所执行的步骤。

当被移动的列为ForeignKey类型时，建立DMForeignData类的一个实例。

class DMForeignData：public DMData

{

*pDestForeignKey； //指向推荐表中外部关键字的指针

*pSourceForeignKey； //指向当前表中外部关键字的指针

}；

如图12所示，一个表可以接收来自多个源表中的数据。所以，下面的类存放DMData和DMForeignData的实例，描述将提供移动至目标表格的数据的每个源表。

class DMTable

{

DMDataList； //列出DMData或DMForeignData的所有实例

*TableDef； //指向接收数据的目标表定义的指针

TempTableName； //在传送期间保存数据的临时表格

}；

对任何目标表格只建立一个DMTable实例。因此，在步464(图13)中，计算机系统确定是否已经对该目标表建立该类的一个实例，如果没有，对该表建立一个实例。

在步466中，计算机为将被移入目标表的每列数据将DMData或DMForeignData实例加到DMDataList中。如果目标表格将包含在原始表中发现的数据，则对将被拷入新表的每个原始数据列建立DMData实例。

在步468中，计算机找到或建立上面为目标表定义的SPTable类的实例。正如以前所指出的，SPTable类定义了将要在某个表上执行的操作。SPTable实例包含指向为目标表建立的DMTable类实例的指针。对任何接收数据的表格的执行类型一般都设置为REPLACE_SAVEDATA，以便利用图10B和上述的表格修改步骤。

下面说明建立临时表格并用图12所示的三个不同表格中的数据插入的SQL语句的基本格式。

CREATE TABLE TempTbl(Soc_Sec_No，Int，Name Text(50)，PhoneText(25))；

INSERT INTO TempTbl(Soc_Sec_No，Name，Phone)

SELECT Employee.Soc_Sec_No，Manager.Name，Office.Phone

FROM Employee，Manager，Office

WHERE Manager.Soc_Sec_No是至

Employee.Soc_Sec_No的外部关键字

AND Office.Title是至Manager.Title的外部关键字

使用目前的标准SQL，不可能顺序插入来自不同表格的多组数据。正如上面语句所说明的，必须同时指定所有的三个源列及其对应的表格。WHERE子句说明根据每个数据组的具体移动路径，不同表格的数据行是如何相关的。

下面给出的表6对为了数据插入而适当地确定表格关系的不同类型的移动路径进行了分类。该表是用于作为值的移动数据(即非外部关键字)。值类型数据移动有5个不同类型的移动路径。

表6

值类型数据移动

1对1	基数没有变化的数据移动，作为下列移动的结果：-通过单个1对1对象链接关系将某一部分移入某个相关的对象
1对1	基数没有变化的数据移动，作为下列移动的结果：-通过单个1对1对象链接关系将某一部分移入某个相关的对象	1对多	基数增加的数据移动，作为下列操作的结果：-部分的基数从一变为N-将单值部分移入多值组部分
多对1	基数减少的数据移动，作为下列操作的结果：-部分的基数从N变为一-将某个部分移出多值组，到包含组或对象	1对多	基数增加的数据移动，作为下列操作的结果：-部分的基数从一变为N-将单值部分移入多值组部分
多对1	基数减少的数据移动，作为下列操作的结果：-部分的基数从N变为一-将某个部分移出多值组，到包含组或对象	多对多	同另一组数据的数据归并，作为下列操作的结果：-将多值部分改为单值并移入某个多值组
复制	从原始表格到临时/新表格的简单数据复制	多对多	同另一组数据的数据归并，作为下列操作的结果：-将多值部分改为单值并移入某个多值组

1对1值类型数据移动的一个例子如图12所示，姓名部分从经理对象520移到雇员对象510。这两个对象是由单值对象链接部分关联的。

1对多值类型数据移动的例子如图7所示，这里，“主课”部分的基数从一变为N。多对1值类型数据移动的例子应该是图7所示基数变化的反向操作。

多对多值类型数据移动的例子如图12A所示，这里的对象550代表一个学生。该对象包含两个标号为“学号”和“姓名”的单值简单值部分。此外，对象550还包含名为“主课”的多值简单值部分和名为“年龄数据”的多值组部分。

表格552代表数据库中的对象550。该表有两个子表554和556。表554包含存放代用关键字、到父表格552的外部关键字的列以及存放年龄和gpa数据的列。表556包括存放代用关键字、到父表552的外部关键字的列以及存放学生主课(major)的列。

如果用户将名为“主课”的部分的基数从N改为一并且将其移入多值组“年龄数据”中，则出现多对多的值类型数据移动。为了表示数据库中的这种变化，存放学生主课的列从表556移入其兄弟表格554。

当数据从目标表的原始版本移到其修改版本时就是复制型数据移动。例如，如图12所示的将表540的“社会保险号”列中的数据移到表540′就是复制型数据移动的例子。

另一组移动类型用来对代表从一个表移到另一个表的外部关键字的移动数据进行分类。当两个对象之间的关系变化时，可能需要对相应的外部关键字进行某些修改。表7对各种链接类型的数据移动进行分类。

表7

链接型数据移动

1对1	外部关键字被移到被引用的对象表
1对1	外部关键字被移到被引用的对象表	多对1	外部关键字从部分表(即多值组中的链接)移到被引用的对象表
更新	由于对应主关键字列的变化而修改外部关键字列的定义，即在关系数据中没有变化	多对1	外部关键字从部分表(即多值组中的链接)移到被引用的对象表
更新	由于对应主关键字列的变化而修改外部关键字列的定义，即在关系数据中没有变化	替换	由于父表格的变化而定义新的外部关键字

1对1链接型数据移动的例子如图8所示，其中，外部关键字列从“教授”表182移到“学生”表186。

多对1链接型数据移动的例子如图12B所示，其中，对象570代表学生，该对象包括3个部分，即两个名为“学号”和“姓名”的简单值部分以及名为“年龄数据”的组部分。该组部分包含一个名为“年龄”的简单值部分和名为“教师”的对象链接部分。该对象链接部分将学生对象550链接到代表该学生的教师的对象552。当用户将教师对象链接部分移出多值组“年龄数据”时，就发生多对1链接型数据移动。

在修改之前，如图12B所示的对象模型在数据库中可由4个表格表示。表574有两列，存放学生的标识符和学生的姓名。表576为表574的一个子表，该表有3列，存放代用关键字、对表574的外部关键字和年龄。表578为表576的子表。该表有3列，保存代用关键字、对表576的外部关键字和对表580的外部关键字，表580存放描述教师的数据。通过将教师对象链接部分移出多值组“年龄数据”，计算机系统删除表578并加入一列到表580，该列将存放链接表580和表574的一个外部关键字。

当修改某个表的主关键字而导致在将该主关键字用作外部关键字的那些表中也发生相应的变化时，就是更新和替换链接型数据移动。

当将被从某个表中删除的一列在推荐模式的另一个表中发现时，被识别为移动数据类型(值或链接)。根据这个信息，对为目标表建立的DMTable类实例中的每个DMData和DMForeignData类实例，计算组成将移动数据的SQL语句所需的移动路径。

图14A和14B给出由计算机系统执行的计算值类型数据移动和链接型数据移动的移动路径的步骤。参看图14A，计算机在步700开始一个循环，通过首先检查移动路径类型(即1对1，1对多，多对1，多对多或复制)，分析数据类型(DataType)为“值”的DMData和DMForeignData的每个实例。接着步702将源表作为第一记录加入正在被计算的移动路径。

在步704，计算机确定移动类型是否为1对1，如果是，计算机在步706中找出当前模式中的相关对象表，即表标识符和推荐模式中的目标表的表标识符匹配的那些表。对于图12所示的1对1例子，计算机定位雇员表540，接着，计算机系统在步706中登记所定位的表及其对源表的外部关键字关系(步708)。在图12所示的例子中，计算机将登记经理表格550中的Soc_Sec_No列作为对雇员表540的外部关键字，完成该移动路径。

如果步704的结果为否，计算机系统在步710中确定该移动类型是否为1对多。如果是，计算机在步712确定是否是否该目标表为新表(即在当前模式中没有找到)。如果是，没有进一步的移动路径被定义。如果该目标表不是新的，计算机系统在步714中查找当前模式的一个子表，该表的标识符和目标表的标识符匹配。计算机在步716中将该子表及其对源表的外部关键字加到移动路径上。在图7所示的1对多例子中，移动路径列出作为源表的学生表172、作为目标表的主课表176，以及主课表的学号列是对学生表172的外部关键字等事实。

如果移动类型不是1对1或1对多，计算机在步720确定其类型是否为多对1，如果是，步722将源表的父表以及它们之间的外部关键字关系加到移动路径上。接着，计算机确定父表的标识符是否匹配目标表的标识符(步724)，如果是，移动路径是完整的，否则，计算机在步726中确定该父表是否代表对象模型中的一个对象。如果不是，计算机返回步722并将父表的父表以及外部关键字信息加到移动路径上。正如将为熟悉这门技术的那些人所承认的，步722将源表和代表对象模型中的对象的表之间的每个表格都加到移动路径上。如果步726的结果为是，计算机将按照上述步706和708(由框728表示)所述的1对1移动类型那样处理。

如果步720的结果为否，计算机确定移动类型是否为多对多，如果是，计算机在步742中将源表的父表以及外部关键字关系加到移动路径上。在步744中计算机确定目标表是否为新表(即在当前模式中没有定义)。如果是，移动路径是完整的。否则计算机在当前模式中查找其标识符和目标表标识符匹配的子表(步746)。最后，计算机在步748中增加目标表及其对父表的外部关键字关系。

如果步740的结果为否，计算机知道该移动为复制类型，不存在移动路径。

为了让用户能同时修改现有的对象关系，图12中可以看到这样的例子，在移动名为“电话”和“姓名”这样的部分后，删除办公室对象500和经理对象520。由于移动数据所需的所有信息在当前模式中仍然可用，用户可以同时进行这些修改。

为了支持这种扩展功能，移动路径查找需要按图14C所说明的修改。其主要区别在于得不到移动路径类型，直到该路径被定义。必须在没有任何辅助信息的情况下执行在推荐模式中的初始查找，即在所有的推荐表中查找这样的一个列，其标识符和源列的标识符匹配。一旦找到一个表，需要在当前模式中查找具有匹配的表标识符的一个对应表。在成功识别当前模式中的源表和目标表后，需要定义一个一旦路径来连接这两个表。如果目标表是新的，应该找出其父表。在导致没有数据移动的当前模式中，这两个表完全不相关是可能。从源表开始，通过其子表(1对多)、兄弟表(多对多)、父表(多对1)或相关的对象表(1对1或多对1)进行查找。根据上述的源基数和路径方向就可以找到移动路径的类型。

图14C给出本发明扩大对已经被移入语义对象模型的某个列的查找所执行的步骤。从步814开始在推荐模式中进行查找，找出其标识符和将被移动列的标识符匹配的列。在步816中，计算机确定该表是否被找到，如果没有找到，没有数据被移动。如果步816的结果为是，计算机系统判别该表在推荐模式中是否为新建立的，如果是，处理过程进入步818，计算机系统确定在步816中找到的表的父表是否为新表，如果是，没有数据移动路径被实现。

如果在推荐模式中的父表不是新表，计算机系统在步822中定义该父表为被定位的表格。接着，在步824中，计算机系统在在当前模式中查找具有匹配的标识符的表。在步826中，计算机系统确定该表是否被到，如果没有找到，不执行数据移动。如果步826的结果为是，意味着在当前模式中找到该表，则计算机系统在步840中将源表加到移动路径上。在步842中，计算机系统在源表的子表(如果有的话)查找目标表。在步844中计算机系统确定是否在源表的任何子表中找到目标表。如果没有计算机系统判别源表是否有一个父表，如果是，则查找任何兄弟表。如果源表没有父表，处理过程进入步838。

在步828中父表及其对源表的外部关键字关系被加到移动路径上。在步830中计算机通过父表的表格列表查找兄弟表。在步832中计算机系统确定是否找到目标表，如果没有计算机系统开始一个循环，通过源表的父表查找目标表。索引、当前表被初始化为源表，并且被重新设置为每个父表的父表。在步834中计算机系统确定当前表的父表是否具有匹配目标表的标识符。如果没有，计算机系统在步836中确定父表是否和对象模型中的某个对象相关，如果否，父表和到当前表的外部关键字关系在步837中被加到移动路径上。接着处理过程返回步834。

如果步836的结果为是，计算机系统查找任何相关对象表。步848中计算机系统确定在任何相关对象表中是否找到目标表，如果没有，移动路径是完整的。如果步848的答案为是，则计算机系统将目标表及其对当前表的外部关键字关系加到移动路径。如果在当前表的子表、兄弟表或任何父表中找到目标表，则计算机系统在步846中将目标表及其对当前表的外部关键字关系加到移动路径上。

现在参看图14B，由计算机系统对链接类型移动执行的计算移动路径的步骤如图所示。从步770开始，计算机开始循环，分析其DataType成员变量等于“链接”的每个DMForeignData实例。计算机首先判别该移动是否为1对1类型(步772)。如果是，计算机在步774中将源表加到移动路径上。接着，在步776中，计算机在当前模式中查找其表标识符和目标表标识符相同的表。然后在步778中，将目标表以及源表和目标表之间的外部关键字关系一起加到移动路径上。

如果移动类型不是1对1的，计算机在步782中判别该移动是否为多对1类型，如果是，计算机在当前模式中查找具有和目标表的标识符相同的表，并且在步784中将目标表加到移动路径上。在步786中，计算机将源表以及源表和目标表之间的外部关键字关系加到移动路径上。在步788中，源表的父表及其外部关键字信息被加到移动路径上。接着，计算机在步790中判别父表是否代表对象模型中的某个对象。如果是，移动路径被完成。否则计算机返回步788，并且将父表的父表和外部关键字信息一起加到移动路径上。

如果移动类型不是1对1或多对1，计算机在步792中判别移动是否为替换类型。如果是，计算机在步794中将源表加到移动路径上。接着计算机在步798中将源表的父表以及外部关键字信息加到移动路径上，并且在当前模式中查找具有和目标表标识符相同的子表。在步804中，计算机确定该子表是否被找到，如果是，移动路径被完成。否则计算机系统判别步798中找到的父表是否具有自已的父表(步806)。如果是，计算机按照步774、776和778(由框808表示)介绍的1对1链接类型移动处理。如果该表不代表一个对象，计算机返回步798。

最后，如果移动类型不是1对1、多对1或替换，计算机知道移动必定是更新类型。如果是，通过在步810中加入源表以及在步812中加入目标表及其对源表的外部关键字关系来完成该移动路径。

一旦计算好移动路径，计算机就组合了若干SQL语句，当这些语句由基本的数据库管理系统执行时，将修改该关系数据库以反映对象模型中的变化。

在建立和初始化SPTable、DMData和DMForeignData类的实例之后，计算机系统修改现有关系数据库模式的表格，以反映用户对相应对象模型的修改。图15A-15D表示由计算机系统执行的修改现有数据库模式的步骤。参看图15A，计算机系统在步900开始一个循环，分析DMTable类中的每个实例。在步902中，计算机系统为每个实例建立一个临时表格。在步904中，计算机系统将数据从源表中移到临时表格。步906结束该循环，计算机系统确定是否所有的DMTable实例已经被处理，如果不是，处理过程返回步900并建立下一个临时表格。

一旦建立了临时表格，计算机系统则开始一系列的循环，分析SPTable类的实例。如上所述，SPTable类通知计算机系统关于对数据库中现有的表格必须执行的所有变化并且建立新表。从步908开始，计算机系统分析SPTable类的每个实例，按照这些实例被放在如上所述以及图11A所示的ChangeTableList中的次序。接着，计算机系统确定执行类型是否被设置为“删除”(步910)。如果是，计算机系统在步912中对该类调用删除表格功能，该表将从数据库中被删除。在步914，计算机系统确定SPTable类的所有实例是否都已经被分析。如果不是，处理过程返回步908。

从步916(图15B)开始，计算机开始一个新的循环，分析SPTable类的每个实例。在步918，计算机系统读出该类的indexOperationList。接着计算机在步920中确定该列表中的记录是否要求索引被删除。如果是，计算机系统在步922中调用删除索引函数。一旦整个indexOperationList列表已经被分析(见步924)，计算机系统在步928中读出foreignOperationList。在步930中，计算机系统确定该列表中的记录是否要求删除某个表的外部关键字。如果是，计算机系统在步932中调用删除外部关键字成员函数。在步934中计算机判别是否已经处理了foreignOperationList中的所有记录。如果不是，处理过程返回到步928。在处理了indexOperationList和foreignOperationList中的所有记录之后，计算机系统在步926中判定是否所有的SPTable类实例已经被处理。处理过程返回到步916，直到所有的SPTable类实例已经被分析。

现在转向图15C，计算机系统开始处理SPTable类每个实例的另一个循环。在步934中，计算机系统判定该实例的执行类型是否为“建立”。如果是，计算机系统在步936中调用该类的建立表格函数。在步938中判别是否SPTable类的所有实例已经被分析，如果不是，处理过程返回到步932。

在步938之后，计算机系统开始分析SPTable类的每个实例的另一个循环(见框940)。在步942中，计算机判别该实例的执行类型是否为“替换”。如果是，计算机系统在步944中调用替换表功能。步946确定什么时候SPTable类的每个实例都已经被分析。

现在转向图15D，计算机系统在步950中开始一个循环，再次分析每个SPTable实例。在步952中，计算机系统读出foreignOperationList。计算机系统在步954中开始一个循环，判定foreignOperationList中的记录是否要求将被加到该表上的一个外部关键字(步956)。如果是，计算机系统在步958中调用加入外部关键字成员函数。在步960中，计算机系统判定是否已经分析了foreignOperationListk中的所有记录。在步962中，计算机系统判定是否已经处理了SPTable类中的所有实例，如果不是，处理过程返回到步950。

在如上所述分析了SPTable类之后，计算机系统在步964中开始一个循环，再次处理DMTable类的每个实例。在步966中，计算机系统将数据从早些时候建立的临时表中插入到目标表上。步968判定是否已经处理了DMTable类中的每个记录并且在步970停止处理过程。最后在步970中删除所有的临时表格。

如上所述，在图15A的步904中，计算机将数据从源表移入由DMDTable类实例定义的临时表格。下面更详细地介绍本发明是如果实现这一功能的。

在执行图15A-15D的步骤之前，对每个DMTable实例的dataList中的每个DMData或DMForeignData实例被分析，以便建立包含下面4个子句的SQL插入命令：

INSERT INTO temporary table name(destination column names)

SELECT source column names

FROM destination table，source table names

WHERE join conditions

一旦建立了一个临时表格，执行一个SQL INSERT命令，将新的目标表格的数据填入该临时表格。

SQL语句的INSERT和SELECT子句是直接从每个DMData或DMForeignData实例中得到。FROM和WHERE子句被区别定义，取决于对每个DMData或DMForeignData实例定义的移动类型和具体的移动路径。数据移动类型的不同值类型的变化总结如下。

值类型移动1对1

在源表和目标表之间所有的源表都直接用连接条件连接。下面的例子表示标号为“PK”、“C1”和“C2”的三个列是如何从标号为“dstTable”、“srcTable1”“srcTable2”中移入名为“tempTable”的临时表格。在这个例子中表srcTable1的标号为“FK1”的列和表srcTable2的标号为“FK2”的列是表dstTable中PK列的外部关键字。

INSERT INTO tempTable(PK，C1，C2)

SELECT dstTable.PK，srcTable1.C1，srcTable2.C2

FROM srcTable1，srcTalbe2，dstTable

WHERE srcTable1.FK1＝dstTable.PK

AND srcTable2.FK2＝dstTable.PK；1对多

在1对多值类型数据移动情况下，要求将一列数据从源表移到目标表的SQL语句更加复杂。如果计算机已经确定目标表不在当前模式中，需要建立一个具有代用关键字的新表。为了达到这一目的，需要建立两个临时表格。第一个临时表(在下例中为keyTable)只一列，保存代用关键字的顺序值。为了建立第一临时表格，计算机执行类似下面语句的一个SQL语句：

CREATE TABLE keyTable(PK int)；

然后利用下面的SQL语句将顺序的代用关键字值重复地加到第一临时表中：

INSERT INTO keyTable(PK)

VALUES (？)； “？”是一个整数

计算机在每次迭代中产生唯一的整数值(这里用？号表示)并将该整数作为一个代用关键插入第一临时表。计算机系统执行上面的INSERT语句直到记录数等于将被移动的源表中的记录数。

由于当前标准的SQL语法并不支持通过行号来选择一行，需要用到第二临时表格(pkTable)和一个视图。利用下面的SQL语句，建立第二临时表，并且将和从源表scrTable移动的列(在本例中为C1)中非空记录相关的主关键字值的复制拷入第二临时表。

CREATE TABLE pkTable(PK type)；这里的“类型”为主关键字的数据类型

INSERT INTO pkTable(PK)

SELECT srcTable1.PK

FROM srcTable1

WHERE srcTable.C1 IS NOT NULL；

接着在第二临时表上建立一个视图，以便通过利用SQL标准函数Min()找出主关键字的最小值，选择单个主关键字值。然而，熟悉数据库程序设计技术的人将认识到，标准函数Max()也可以被使用。

CREATE VIEW minPKView(PK)

ON SELECT Min(PK)

FROM pkTable；

一旦该视图被完成，计算机系统建立第三临时表(tempTable)，该表将被用作所修改目标表的模板。

在说明了第三临时表之后，计算机系统开始一个循环，插入包含被移动数据的源表的列C1中的记录、被用作外部关键字的源表的主关键字，以及形成第三临时表的主关键字的surrogate关键字。下面是完成这些步骤的SQL语句的例子。当执行该语句时，WHERE子句中的“？”用整数代替。接着增值以便进行下一次插入。

INSERT INTO tempTable(C1，FK，PK，)

SELECT srcTable1.C1，srcTable1.PK，keyTable.PK

FROM srcTable1，keyTable，minPKView

WHERE keyTable.key＝？

AND srcTable1.PK＝minPKView.PK；

在插入每一行之后，删除“pkTable”中的一个对应行。重复这一过程直到pkTable为空。然后从数据库中删除所有临时表和视图。

如果目标表已经存在当前数据库模式中，要求将源表“srcTable1”中的列C1移到临时表“tempTable”的SQL语句简化为：

INSERT INTO tempTable(FK，PK，C1)

SELECT dstTable.FK，dstTable.PK，srcTable1.C1

FROM dstTable，srcTable1

WHERE srcTable1.PK＝dstTable.FK

在表“tempTable”被设置之后，接着将整个表拷入目标表并可删除临时表。多对1

当部分从多值到单值基数变化时就出现多对1值移动。为了反映数据库中的这一变化，通常需要删除数据。问题在于那些数据值将从源表拷到目标表以及那些数据值将被丢掉。作为一种缺省，本发明的当前实施力总是选择具有最小主关键字的记录作为被保存的记录。

为了完成数据移动，建立源表主关键字的数据库视图。由于移动路径可以包括多个表，需要指定源表和目标表之间的所有外部关键字关系。因此，利用具有下面形式的SQL语句构造视图以便封闭整个移动路径：

CREATE VIEW pkView(FK，minPK)

ON SELECT T1.FK，Min(srcTable.PK)

FROM T1，T2，...，Tn，srcTable

WHERE T1.PK＝T2.FK

AND Tn.PK＝srcTable.FK

GROUP BY T1.FK；

这里的T1...Tn为移动路径中除去目标表之外的所有表格。

在定义了视图之后，计算机系统执行INSERT SQL命令将所选择的记录加到目标表上。利用该视图，INSERT命令将如下所示：

INSERT INTO tempTable(PK，C1，C2)

SELECT dstTable.PK，srcTable1.C1，dstTable.c2

FROM srcTable1，dstTable，pkView

WHERE srcTable1，PK＝pkView.minPK

AND dstTable.PK＝pkView.FK；

在执行了上面的SQL命令之后，“pkView”需要被删除以完成该插入操作。多对多

多对多类型数据移动实际上是两种数据组合。因此需要采用某种方式连接源表和目标表的记录。作为一个缺省操作，本发明利用每个父实例的简单笛卡尔积如下：

INSERT INTO tempTable(FK，PK，C1，C2，PK2)

SELECT srcTable.FK，srcTable.PK，srcTable.C1，

dstTable.C2，dstTable.PK

FROM srcTable，dstTable

WHERE srcTable.FK＝dstTable.FK

被连接的表具有新建立的记录，因为笛卡尔积导致重复的主关键字值。这些重复的值需要被重新赋予新的唯一值。

为了完成这一任务每个源表中的主关键字也被拷入临时表。两个(或多个)主关键字列的组合仍然是唯一的，以便选择性地更新目标表的代用关键字值。计算机首先利用下面的语句建立临时表格。

CREATE TABLE pkTable(FK int，PK int，PK2 type)；

这里的“type”是第二主关键字的数据类型。接着利用下面的语句将主关键字插入临时表中：

INSERT INTO pkTable(FK，PK，PK2)

SELECT FK，PK，PK2

FROM tempTable；

接着，顺序建立两个(或多个，取决于被关联的表格数)视图。第一视图选择对每个外部关键字值即每个父记录选择最小值的第一主关键字。

CREATE VIEW minPKView(FK，minPK)

ON SELECT FK，Min(PK)

FROM pkTable

GROUP BY FK；

接着，第二视图对每个最小值的第一主关键字选择最小值的第二主关键字。

CREATE VIEW minPKView2(minPK，minPK2)

ON SELECT minPK，Min(PKTable.PK2)

FROM minPKView，PKTable

GROUP BY minPK；

接着，通过重复执行下面的两个SQL命令来实现更新，在每次执行之后对整数“？”增1直到主关键字表为空。该关键字值被初始化为现有的最大主关键字值加1。

　　UPDATE         tempTable

　　SET            PK＝？

　　WHERE          1＜(SELECT        COUNT(+)

　　                    FROM minPKView2

　　                    WHERE minPKView2.minPK＝tempTable.PK

　　                    AND minPKView2.minPK2＝

　　                    tempTable.PK2)；

　　DELETE FROM    pkTable

　　WHERE          1＜(SELECT    COUNT(*)

　　                    FROM minPKView2

　　                    WHERE minPKView2.minPK＝pkTable.PK

　　                    AND minPKView2.minPK2＝pkTable.PK2)；

　　                    链接类型移动

当外部关键字被移到另一个对象表时，需要不同定义SQL插入命令，以便利用源外部关键字数据作为约束条件从源表中拷备主关键字值。这又取决于每个DMForeignData实例的移动路径。下面解释本发明是如何处理每种链接类型移动的。1对1

在1对1移动的情况下，源表主关键字值作为新的外部关键字值被插入。下面的SQL命令表示在表“srcTable”的标号为“FK”中找到外部关键字值是如何被移入目标表“dstTable”中的列“PK”。

INSERT INTO tempTable(PK，FK)

SELECT dstTable.PK，srcTable.PK

FROM dstTable，srcTable

WHERE dstTable.PK＝srcTable.FK多对1

如上所述，多对1移动通常需要删除数据库中的数据。因此，利用具有下面形式的SQL语句建立一个视图，以便减少多个记录进入每个其他对象实例中的一个。

CREATE VIEW minPKView(dstFK，minPK)

ON SELECT dstFK，Min(srcObjTable.PK)

FROM srcObjTable，...，Tn，srcTable

WHERE srcObjTable.PK＝T1.FK

AND ...

AND TN.PK＝srcTable.FK

GROUP BY dstFK；

利用上面的视图，主INSERT命令如下所示。

INSERT INTO tempTable(PK，FK)

SELECT dstTable.PK，srcTable.PK

FROM dstTable，srcTable，minPKView

WHERE srcTable.PK＝minPKView.minPK

AND dstTable.PK＝minPKView.dstFK；更新

当由于在被引用表中发现主关键字的某些变化而某个现有的外部关键字需要新值时，就用到这个移动类型。利用具有下面形式的SQL语句，用现有的关键字约束条件直接复制新的关键字值，这里的FK是外部关键字列名，而PK则为保存被引用表的主关键字值的列。

INSERT INTO tempTable(FK)

SELECT refTable.PK

FROM srcTable，refTable

WHERE srcTable.FK＝refTable.PK；替换

当由于父表的变化即某个部分表被移到另一个父表而用某个新定义替换外部关键字时，就用到这种移动类型。通过执行具有下面形式的SQL语句，利用现有的关键字约束条件直接复制新的关键字值，这里的T1...Tn为在上述所计算的移动路径中找到的表格。

INSERT INTO tempTable(FK)

SELECT refTable.PK

FROM srcTable，T1，...，Tn，refTable

WHERE srcTable.FK＝T1.PK

AND ...

AND Tn.FK＝refTable.PK

在修改了当前的数据库以反映对相应的对象模型所做的修改之后，推荐模式被存储作为当前模式，被作进一步对象模型变化的比较。

正如从上面的介绍中可以看到的，本发明根据相应对象模型中的变化来修改现有的数据库模式。本发明允许用户方便地更新数据库，而不必理解例如表、关键字、外部关键字和代用等这样的传统的关系数据库概念。相信本发明将使得那些具有很少或完全没有关系数据库经验的人更容易使用关系数据库。

虽然，已经说明和描述了本发明的最佳实施例，但应该承认，在不脱离本发明精神和范围的情况下，可以进行各种修改。

Claims

1.一种修改现有的关系数据库以反映相应对象模型变化的方法，包括步骤：

将一个对象模型存放在计算机系统的存储器中，该对象模型至少包括一个对象，该对象代表与其相关的数据被存入所述关系数据库中的一类项目，所述对象至少包括一个部分，该部分定义了为所述项目存放在所述关系数据库中的数据；

显示对象模型的一种可视化表示形式；

将当前关系数据库模式存放在计算机系统的存储器中，所述当前关系数据库模式定义了被包含在现有关系数据库中的一个或多个关系表、以及被包含在一个或多个关系表中的一个或多个列；

检测用户对对象模型所作的修改并自动产生对应于被修改的对象模型的推荐关系数据库模式；自动比较当前关系数据库模式和推荐关系数据库模式；并且

根据当前关系数据库模式与推荐关系数据库模式的比较结果，自动修改关系数据库，而不需要用户除对对象模型修改之外的其它输入。

2.权利要求1的方法，其中推荐关系数据库模式和当前关系数据库模式包括关系数据库表的列表，其中，比较当前关系数据库模式和推荐关系数据库模式的步骤进一步包括步骤：

自动判定是否在推荐模式的关系数据库表的列表中找到当前关系数据库模式的关系数据库表的列表中的每个登录项；并且

从关系数据库中自动删除存在于当前关系数据库模式的关系数据库表的列表中、但不存在于推荐关系数据库模式的关系数据库表的列表中的每个表格。

3.权利要求2的方法，进一步包括步骤：

自动判定推荐关系数据库模式的关系数据库表的列表中是否存在在当前关系数据库模式的关系数据库表的列表中没有找到的任何登录项；并且

对存在于推荐关系数据库模式的关系数据库表的列表中、但不存在于当前关系数据库模式的关系数据库表的列表中的每个登录项，自动加一个关系数据库表到关系数据库中。

4.权利要求3的方法，其中当前关系数据库模式和推荐关系数据库模式包括被包含在每个表中的每个列的列表，其中，比较当前关系数据库模式和推荐关系数据库模式的步骤进一步包括步骤：

自动判定被包含在推荐模式的一个表中的列的列表中是否找到被包含在当前模式的所述表格的列的列表中的每个登录项；并且

从关系数据库中自动删除那些被包含在当前关系数据库模式的关系数据库的所述表中、但不存在于推荐关系数据库模式的所述表中的列。

5.权利要求4的方法，其中，如果计算机系统确定从关系数据库中删除一列，该方法进一步包括步骤：

自动判定将从关系数据库中删除的列是否包含数据，如果是，查找推荐关系数据库模式中表的列表，以确定将被删除的列是否已经被移到推荐关系数据库模式的另一个表中；并且

如果在推荐关系数据库模式的另一个表中发现将被删除的列，自动将数据从关系数据库的源表移到关系数据库的目标表中。

6.权利要求5的方法，其中，将数据从源表移到目标表的步骤包括以下的步骤：

在关系数据库中自动建立一个临时表；

自动地将数据移入临时表中；

自动判别目标表是否包含将被存储的任何数据，如果是，将要保存的数据移入临时表；

从关系数据库中自动删除目标表；

自动建立一个新的目标表，该表包含存放被存储的数据以及来自源表的数据的列；

自动将数据从临时表移入新的目标表；并且

自动从关系数据库中删除临时表。

7.权利要求1的方法，其中，关系数据库包含具有对关系数据库中其它表的外部关键字的一个或多个表，该方法进一步包含步骤：

自动在计算机的存储器中建立一个列表，该列表包含将要修改的每个表，其中，该列表中的登录项被如此安排，使得包含对数据库中其它表格的外部关键字的表在外部关键字所引用的表之后被修改。

8.权利要求5的方法，其中，将数据从源表移到目标表的步骤进一步包括以下的步骤：

自动确定表示源表和目标表之间的外部关键字关系的源表和目标表之间的一条移动路径。

9.一种修改当前的关系数据库以反映相应对象模型变化的计算机系统，该模型至少包含一个对象，代表存放在关系数据库中的信息，每个对象至少包含一个部分，代表存放在关系数据库中的数据，该计算机系统包括：

一个处理器；

连接处理器的一个存储器；

存放当前关系数据库模式的一个外部存储装置；

由中央处理器驱动、以便产生对应当前关系数据库模式的对象模型的一种表示形式的一个显示器；

允许用户修改对象模型的数据输入装置；

存放在存储器中的一组程序化指令，使处理器分析被修改的对象模型并自动建立推荐关系数据库模式，这组指令进一步使中央处理器自动比较推荐关系数据库模式和当前关系数据库模式，并且在除了对对象模型的修改之外、没有其它用户输入的情况下，自动修改对应被修改对象模型的当前关系数据库模式。

10.权利要求9的计算机系统，其中，当前关系数据库模式包含多个表，每个表至少有一个存放数据的列，其中，这组指令使得计算机系统在存储器中产生一个列表，该列表指出了构成当前关系数据库模式的表为对应被修改的对象模型而将被修改的次序，其中，该列表被如此安排，使得具有对当前关系数据库中其它表格的外部关键字的表在该外部关键字所引用的表之后被修改。

11.权利要求9的计算机系统，其中推荐关系数据库模式和当前关系数据库模式包括关系数据库表的列表，其中，指令组使得计算机系统通过下面的方法，比较当前关系数据库模式和推荐关系数据库模式：

查找推荐和当前数据库模式中的关系数据库表的列表，确定在当前关系数据库模式中是否存在任何不存在于推荐关系数据库模式中的关系数据库表；并且

产生一个SQL语句，该语句将从当前关系数据库模式中删除存在于当前关系数据库模式中、但不存在于推荐关系数据库模式中的任何关系数据库表。

12.权利要求11的计算机系统，其中，所述指令组进一步使得计算机系统通过下面的方法，比较当前关系数据库模式和推荐关系数据库模式：

查找推荐和当前数据库模式中的关系数据库表的列表，确定在推荐关系数据库模式中是否存在不存在于当前关系数据库模式的关系数据库表的列表中的任何关系数据库表；并且

产生一个SQL语句，该语句对存在于推荐关系数据库模式中、但不存在于当前关系数据库模式中的每个关系数据库表，将一个关系数据库表加到当前关系数据库模式中。

13.权利要求11的计算机系统，其中当前关系数据库模式和推荐关系数据库模式包括被包含在每个关系数据库表中的每个列的列表，其中，所述指令组进一步使得计算机系统通过下面的方法，比较当前关系数据库模式和推荐关系数据库模式：

查找当前数据库模式和推荐关系数据库模式中的每个表的列的列表，确定在当前关系数据库模式的关系数据库表中是否存在任何不存在于推荐关系数据库模式的关系数据库表中的列；并且

产生一个SQL语句，该语句将从当前关系数据库模式中删除存在于当前关系数据库模式的表中、但不存在于推荐关系数据库模式的表中的那些列。

14.权利要求4的方法，其中，指令组使得计算机系统执行下面的操作：

确定将从数据库中删除的列是否包含数据，如果是，查找推荐关系数据库模式中的某些关系数据库表，确定该列是否已经被移到推荐关系数据库模式中的另一个表中；并且

产生一个SQL语句，如果在被定义在推荐关系数据库模式中的另一个表中发现将被删除的列，计算机执行该语句，将关系数据库某个源表中的数据移到某个目标表中。

15.权利要求14的计算机系统，其中，指令组使得计算机系统产生一系列的SQL语句，这些语句将：

在关系数据库中建立临时表；

将数据移入该临时表；

判定目标表格是否包含任何将被保存的数据，如果是，将要保存的数据移入临时表；

从关系数据库中删除目标表；

建立一个新的目标表，该表包含存放已保存的数据和来自源表的数据的列；

将数据从临时表移入新的目标表；并且

从关系数据库中删除临时表。