CN1799048A

CN1799048A - 通用数据库模式

Info

Publication number: CN1799048A
Application number: CNA2004800107728A
Authority: CN
Inventors: 沃尔夫冈·弗洛顿
Original assignee: SEDUNIZE CO Ltd
Current assignee: SEDUNIZE CO Ltd
Priority date: 2003-04-23
Filing date: 2004-04-22
Publication date: 2006-07-05
Also published as: JP2006524376A; US20060225029A1; AU2003901968A0; EP1620812A1; EP1620812A4; WO2004095312A1

Abstract

本发明提供一种计算机软件产品(18)，其包含由电子处理器执行的机器可读指令，以根据一种模式(24)来提供数据库管理系统，所述模式包括：第一个表(34)，其存储各种实体类型的名称；与所述第一个表相关的第二个表(36)，其存储各种实体类型的实体名；与所述第一个表相关的第三个表(38)，其存储关于所述各种实体类型的字段名；以及与所述第二个表和第三个表相关的一个或多个值存储表(40)，其使存储的字段值与实体相关联；所述模式包括例如“EntityType”、“Entity”、“Field”、“FieldType”的标识符，以指示在所述表的每一个中存储的数据的性质。

Description

通用数据库模式

技术领域

本发明涉及数据库和数据库模式。

背景技术

当今，在商业环境中应用数据库管理系统(DBMS)是常见现象。大多数DBMS被设计为对关系数据库中存储的数据进行操纵。关系数据库包括不同实体类型之间的关系规范，这些实体类型是在数据库中被建模的。一般以模式图的形式将这些关系和实体类型用图表呈现出来。模式图将实体类型描述为字段的矩形列表，矩形列表包括表列名。并由表示实体之间关系的线示出表示实体类型的矩形列表的相互联系。

在设计用于特殊应用程序的关系数据库时，一般都将大量的工作花费在分析实体和确定与该应用程序有关的关系上，以便可以创建适当的模式。在已模块化的应用程序改变的情况下，这是常有的事，那么必须更新模式，并且也要时常地更新相关的DBMS。一般也必须修改与访问该数据库有关的软件应用程序。例如，可能需要更新该模式以插入新的实体类型，从而改变或添加新字段到实体类型，或改变实体类型之间的关系。随着模式复杂性增加，在更新模式时的系统开销一般按指数规律地增加。

应当认识到，至少有两个问题与通常的建模过程有关。首先，必须为每一个应用程序创建新的模式图。其次，更新已有的模式以及必要时对有关DBMS和软件应用程序进行重新配置都需要相当大的系统开销。

本发明的目的在于提供一种解决上述讨论问题的便利方法。

发明内容

根据本发明的第一个方面，提供一种计算机软件产品，其包含由电子处理器执行的机器可读指令，以根据一种模式来提供数据库管理系统，所述模式包括：

第一个表，其存储各种实体类型的名称；

与所述第一个表相关的第二个表，其存储各种实体类型的实体名；

与所述第一个表相关的第三个表，其存储关于所述各种实体类型的字段名；

与所述第二个表和第三个表相关的一个或多个值存储表，其使存储的字段值与实体相关联；以及

标识符，其指示在所述表中的每一个表中存储的数据性质。

优选的是所述模式包括应用于所述第一个表的第一层次关系和应用于所述第二个表的第二层次关系，以便于层次实体的定义。

在优选实施例中，所述模式包括存储所述实体之间的关系的表。

优选的是所述第一个表包括存储与实体类型对应的指针的列，所述指针指示位置，在所述实体类型的新实例创建期间，可以从所述位置获得缺省值。

所述第三个表可包括存储以下数据的列，所述数据指示根据在所述一个或多个值存储表的列中存储的数据来产生新创建的实体名。

优选的是所述一个或多个值存储表中包括多个值表，所述每一个值表均包括特定类型的值列。

在一个实施例中，每一个所述值表均与所述模式的一个或多个表相关。

优选的是所述每一值表均与所述第二个表相关。

可以将所述值表设置为存储指向存储在数据结构外部的数据的指针，所述数据结构由所述计算软件产品创建。

在优选实施例中，所述模式包括数据类型表，所述数据类型表将所述值存储表的名称与特定类型的值列的对应名称联系起来。

优选的是所述数据类型表与所述第三个表相关。

所述数据类型表可以与中间值类型表相关，并且其中所述值类型表指向所述第三个表。

优选的是所述第三个表包括定义多字段功能性的列。

所述第三个表可以包括指示是否存储关于对应字段类型的历史数据值的列，并且其中所述值存储表每一个均包括存储所述字段类型的当前值、以及存储指示何时写入所述当前值的数据的列。

优选的是所述第三个表包括这样的列：存储指示新创建的实体实例的值是否是从另一个实体实例继承的。

可以提供具有存储数据存储格式的列的格式表。

在优选实施例中，所述模式包括一个或多个存储指示字段集分组的值的表。

根据本发明的另一个方面，提供一种借助于电子处理器实现的存储数据的方法，所述数据关于多个不同实体类型的实体，以及关于所述不同实体类型之间的关系，所述方法包括：

将所述实体类型的每一个的标识符存储在第一个表中；

将所述多个实体的每一个的标识符存储在与所述第一个表相关的第二个表中；

将所述不同实体类型的多个字段类型的每一个的标识符存储在与所述第一个表相关的第三个表中；以及

将与所述实体有关的字段值存储在一个或多个值存储表中，所述值存储表与所述第二个表和第三个表相关。

优选的是所述方法进一步包括：通过将第一层次关系应用于所述第一个表且将第二层次关系应用于所述第二个表来存储层次实体。

所述方法可以进一步包括将数据存储在一个或多个定义所述实体之间的关系的表中。

优选的是所述存储定义关系的数据步骤包括：

将识别不同关系类型的数据存储在第五个表中；以及

将识别关系的数据存储在第六个表中。

根据本发明的再一个方面，提供一种根据上述方法进行操作的计算装置。

根据下列参照多个图的优选实施例的描述，将会清楚地理解本发明的各个方面的更多优选特征。

附图说明

图1A为实现本发明实施例的计算机系统的框图。

图1示出了说明数据抽象的简单例子的模式。

图2-10示出根据本发明实施例的模式。

图11示出在图2至10中示出的模式的扩充。

图12示出根据本发明实施例操作的计算机系统产生的查看表单的例子。

图13示出根据本发明实施例操作的计算机系统产生的编辑表单的例子。

图14示出根据本发明实施例操作的计算机系统产生的历史表单的例子。

图15示出根据本发明实施例操作的计算机系统产生的列表表单的例子。

图16示出根据本发明实施例操作的计算机系统产生的报告表单的例子。

图17示出根据本发明实施例的模式的一部分。

图18示出根据本发明实施例的模式的另一部分。

具体实施方式

图1A为计算机系统的框图，可以在该计算机系统上执行根据本发明实施例的软件产品。该系统包括监视器6、键盘4以及鼠标20，它们全部都连接到包含主板10的逻辑框2上，该主板10使电子处理单元(CPU)8连接到RAM 12、ROM 14、通信端口22以及辅助存储装置阅读器16上。该辅助存储装置阅读器读取软件产品18的指令，例如，一般以光盘或磁盘或固态存储器的形式提供软件产品18。在使用中，CPU 8根据包含在软件产品18内的指令对计算机系统进行操作。这些指令定义了现在要描述的数据库程序26和数据库模式24。

在此使用术语“数据抽象”来描述将标准数据库模式转换为“抽象”数据库模式的过程，在标准数据库模式中，利用表、这些表中的列和字段之间的关系来定义和存储信息，每一个表均表示相异数据类(例如，客户)以及每一列均表示要存储的数据项(例如，名)，在“抽象”数据库模式中，能配置一组稳定不变的表、字段以及关系以存储所期望的任何一类数据，而不需要改变模式(表、字段和关系设计)。

在图1中示出了一个非常简单的数据抽象的例子，图1中示出了标识为为Entity*28和Field*30的两个表，这两个表通过单一关系32相互联系。

为了将包含如下字段：

·名

·姓

·电话

·地址

的Client表映射为图1中所示的模式，采取如下步骤：

1.在Entity表中输入ID＝1和Name＝Client的记录

2.在Field表中输入四条记录，其中，各自的记录Lable＝“上面的字段名之一”并且EntityID＝1

3.然后可以将数据输入到Field表中的相应Value列中

上面的过程示范了将任意种类的数据存储到恰好为两个表中的方法，但该方法有如下几个缺点：

1.没有一致的方式来对这些表进行查询

2.需要重复每一个字段的标签

3.没有实体和字段的定义结构

因此，不能将上面的过程用来构造完全抽象模式。

核心抽象系统(CAS)

现参照图2，图2示出了用于根据本发明第一实施例的数据抽象的基本结构。图2中的模式包括分别标识为EntityType 34、Entity36、FieldType 38和Field 40的四个表，用于表示存储到每一个表中的数据性质，正如将要说明的一样。

图2的模式有利于构造和配置任意数量的实体类型，每一种实体类型均具有专用的一组字段类型集。一旦对这些实体类型进行配置，通过查询EntityType表和FieldType表就能自动创建对于存储实体的新实例所需的全部实体和字段记录。应当注意，由于将字段类型的名称用于字段标签，因此在Field表中不再有Lable列。

为了定义包含如下字段：

·名

·姓

·电话

·地址

的标准“Client”表的抽象，在图2的模式中采取如下步骤：

1.在EntityType表中输入ID＝1和Name＝Client的记录

2.在FieldType表中输入四条记录，其中，各自的记录Name＝“上面的字段名之一”以及EntityTypeID＝1

为了创建新的Client实体，采取如下步骤：

1.在Entity表中输入EntityTypeID＝1的记录

2.输入一组字段记录，每一个FieldType的一个字段记录均为Client EntityType定义，将EntityID分配给新实体的EntityID，并且将FieldTypeID分配给对应的FieldTypeID。

然后，可以将值输入到新实体名称列和其新字段值列中的每一个字段值中。不需要改变模式，就可以在该模式中定义和存储任意数量的EntityType，并且对于其数据存储的所有方面，能有选择地准确地查询该模式。

为了比较标准表查询与抽象表查询的SQL语句，查找姓为“Smith”，标准SQL为：

SELECT ID FROM Client WHERE Lastname＝“Smith”

而就图2的CAS模式来说，等效的语句是：

SELECT ID FROM Entity

INNER JOIN Field ON Field.EntityID＝Entity.ID

WHERE Entity.EntityTypeID＝1

AND Field.FieldTypeID＝2

AND Field.Value＝“Smith”

虽然CAS SQL语句更加复杂，但其是通用的。当在标准模式中定义一组新的表时，每一个新表均需要专用的SQL来访问每一个新表和列。当在抽象模式中定义新的数据类时，通过替代EntityType和FieldType各自的ID，能将上面的SQL用于任意的EntityType和FieldType。

SQL中的其他不同在于：标准查询用SELECT*返回所有的表字段，而CAS版本需要“子选择”或功能以返回字段值。此外，这些也能根据提供一致的和通用的字段访问的FieldType定义来自动地产生。

为了可靠地访问全部存储信息，可使用枚举器系统或基于对象的ID服务。这些可以根据数据库的内容来自动地产生。

在下面描述的所有附加服务均保持这种数据存取的SQL结构的一致性和通用性来进行数据存取。

实体服务

这些服务表示CAS的附加功能。

下列的“服务”描述了支持服务的范围，这些服务可以与CAS结合以实现多种功能。它们每一个均将描述实现新功能的CAS的扩充。

重要的是，随着这些服务合并，CAS变得能代替越来越多的标准模式架构和方法。

支持实体层次

给实体表提供层次结构是有用的。这提供了层次“构架”，也使实体的文件夹或目录成为可能。

图3示出具有ParentEntityTypeID列的EntityType表，该ParentEntityTypeID与其自身ID有关系。其后，在具有与其自身ID关系的ParentEntityID的Entity表中反映了这种结构。

这允许EntityType定义范围之内的层次定义，然后，可以在新实体输入到Entity表中时反映这种层次定义。

在ParentEntityTypeID为空(未定义)的EntityType表中的任何定义均被认为是层次中的根节点。根节点类型的实体同样也有空的ParentEntityID，这使它们成为Entity表中的根节点。

支持文件夹和目录

能通过将简单的IsFolder布尔列引入到图4中的EntityType表中，来定义表示层次中的文件夹或目录占位符的EntityType。

IsFixed布尔列的引入提供了一种这样的方法：即，将文件夹或其他实体设置为是否必须存在于层次的定义位置之中，或是否可以存在于层次的任意位置之中。

可以引入称为HierachicalLocation的多对多的表，以控制层次中指定EntityType的多个位置，所述多对多的表具有均指向EntityType的ID的字段EntityTypeID和ExistUnderEntityID。

支持实体克隆和缺省实体

参照图4，通过在EntityType表中引入DefaultEntityID列，可以指向一个实体，即该实体是该EntityType的缺省实体。

图4的模式支持“实体和分支克隆”的形式，其中，用户复制任意指定实体和其字段，并在层次中的任意期望的位置创建实体和其数据的副本。可以对单个实体、任意的实体集或层次中一整个分支的实体执行这种克隆。这具有许多有用的应用。

这种应用之一是定义缺省实体，然后在请求该类型的新实体时创建这个实体的副本。

这允许为缺省实体内的所有字段值定义初值，然后，在从缺省实体克隆新实体时进行反映。

支持缺省值

可以将实体名称视为其数据成分之一，或者，用户可以根据定义的字段值的集来创建名称。这对根据多字段形式的一个或多个用户的输入来提供有意义的实体名称是非常有用的。

在图5中，FieldType表中的新整数列DefaultValue允许字段值的定义，应该结合该字段值的定义并按某种顺序(通过将该顺序定义为DefaultValue的值)来创建该实体的名称。如果DefaultValue＞0，那么进行结合以便创建实体名称。

支持关系

为了支持实体之间的关系，图5的系统提供了在数据库中定义并实现除先前描述的层次关系之外的实体之间的关系的高通用性方法。

例如，使用引入到图4中的RelationshipType表和Relationship表，通过执行如下步骤，可以快速地定义“Staff”EntityType与“Client”EntityType之间的“Client Manager”的关系，这些步骤是：

1.定义Staff和Client实体类型(参见上面)

2.在RelationshipType表中输入记录并设定Name＝“ClientManager”，FromEntityTypeID＝“Staff EntityType的ID”且ToEntityTypeID＝“ClientEntityType的ID”。

现在，列出为Staff实体或Client实体之间的关系的任何软件可以通过查找Relationship表将“Client Manager”列出作为可创建的关系。

然后，为了创建类型为“Client Manager”的Staff实体与Client实体之间的关系，执行如下步骤：

1.在Relationship表中输入新记录

2.将FromEntityID设定为所期望的Staff实体的ID

3.将ToEntityID设定为所期望的Client实体的ID

4.将RelationshipTypeID设定为“Client Manager”RelationshipType的ID。

然后，这将允许用简单的SQL返回由指定员工等管理的全部客户。

在关系表中，可以定义任意数量的RelationshipType且可以设定任意数量的关系。

这里要注意的重要事项在于：在标准模式中，需要为每一对表提供单独的多对多的表(例如关系表)，期望在所述一对表之间存储关系。在某种系统(例如，警务和调查数据库)中，需要在所有的表之间建立关系。这意味着：每一个新的数据表将需要针对每一个现有的数据表的多对多的表，这给系统设计、开发和管理带来相当大的负担。

由于该模式不使用每个实体一个表，而是将所有实体均抽象为单个的实体ID表，所以，永远只需要一个关系表。

支持存储数据类型

对于数据类型是指布尔、货币、日期、二进制、本文等等。

在上面描述的CAS使用“variant”数据类型来将数据存储在Field表中。由于“variant”数据类型不能利用现有大量的不同数据类型，而现有的大量数据类型中不能用作“variant”的数据类型，所以，对于这种模式的任意大量使用是有限制的。

虽然有一种选择是将许多以不同数据类型存储的数据包括在Field表内，但对于每一个存储的值，每一个Field表将存在许多未使用的列，所以，这种作法并不是有效的。

根据本发明的模式的优选实施例针对每一期望的数据类型和每一期望的指针提供专用Value表。每一Vaule表均涉及Field表。数据存储在与Value表的定义数据类型相应的Value表中。

为了说明，图6中的例子示出Value表的子集。注意，在Field表中不再有Value列。

对于每一个字段，在Field表中有入口以及在Value表之一中有链接入口。虽然有一种选择是去掉Field表，但这意味着每一个Value表均直接指向Entity表，并且需要其自身的FieldType指针。这对该模式来说是一种可行的选择。然而，在SQL中，该字段作为指向FieldType的更加有用的链接，并且还提供更好的架构以保持值历史记录和其他状态数据，正如下面将要说明的那样。

从美国华盛顿州的雷蒙德的微软公司(Microsoft Corporationof Redmond，Washington，USA)得到的Microsoft SQL Server 2000提供了25个数据类型，因此，取决于需要哪个数据类型，可以定义高达25种的ValueX表(包括图7中示出的四个例子)。

每一个Value表均具有所期望数据类型的对应Value列。例如，ValueBoolean表具有数据类型为BIT的列BooleanValue，ValueDate表具有数据类型为DateTime的列DateValue。

为了定义应将何种Value表用于存储指定FieldType的数据，我们引入了DataType表。该表用作定义期望数据类型并提供表名以及其Value列名。这允许如此的过程：即，自动创建从定义的Value表中检索数据所需的SQL。

虽然可以利用一些系统表(例如SQL Server 2000中的sysobjects)来提供DataType表的一部分功能，但是，这些表的范围有限并且不能改变。

对于每一个Value表，在DataType表中均有一条记录，并且对于图6中所示的该组Value表，DataType表包含下列的表1中示出的值：

ID	TableName	ValueColumnName
ID	TableName	ValueColumnName	1234	ValueMoneyValueTextValueBooleanValueDate	MoneyValueTextValueBooleanValueDateValue

表1

虽然由此处继续进行下去的最容易的方式是在FieldType表中提供DataTypeID指针，但还是将ValueType表引入作为中间步骤。

为了能存取所有的可用数据类型，在ValueType表中必须有至少一个入口，ValueType表链接到每一个可用的DataType入口。

不过，现在可以在ValueType表中提供任意数量的附加入口，以使任意数量的允许数据类型的不同应用成为可能。

例如，可以引入称为“Due by date”的新ValueType，并映射为ValueDate表。然后，无论何时希望为表示“Due by date”的实体定义日期，都可以使用新ValueType，而不是使用标准DateValueType。然后，可以在系统范围内使用新ValueType，以报告并处理Due by date。这种能力有许多的用途，从而定义许多的ValueType。

在根据本发明的优选实施例的模式中，ValueType、DataType以及ValueX表的组合能针对各种值使用适当的数据类型。

支持实体指针数据类型

通过创建具有指向Entity表的指针的Value表，使用本发明的实施例，我们开始能够将所有标准模式建模。

在图7中，已用ValueEntity表代替ValueMoney表，在FieldType中引入两列新列，它们是ValueEntityTypeID指针和ValueEntityParentID指针。

ValueEntity表具有指向Entity表ID的EntityID指针。

可以选择在FieldType表中的ValueEntityTypeID指针和ValueEntityParentID指针的组合，以为实体指针字段定义期望的容许实体的范围。

为便于说明，如果不设定ValueEntityTypeID指针和ValueEntityParentID指针中的任何一个，那么字段就能指向任意的实体。如果仅设定了ValueEntityTypeID指针，那么字段能指向该EntityType的任意实体。如果仅设定了ValueEntityParentID指针，那么其能指向所选择实体的任意子实体。如果两者均被设定，那么字段能指向已定义EntityType的实体，所述实体是所选择实体的子实体。

可以根据用户的需要而引入定义容许实体的其他方法。

对这种结构最常见的使用是提供“查找列表”，并且使其与表指针的标准模式结构等同。

不是列出具有城市名称(伦敦、墨尔本、华盛顿等)的City表，而是列出具有这些EntityType City名称的实体。

为便于说明，使用在上面我们的客户表例子，如果我们需要城市查找功能，那么我们通常会在数据库中创建新的City表，在Client表中创建CityID列，并将该列链接到City表的ID列作为外部关键字。

与此相反，使用图7的模式，我们将Cities实体定义为文件夹，将City实体定义为Cities实体的子实体。然后，我们为ClientEntityType定义City FieldType，并且将ValueEntityTypeID设定为指向City EntityType(可选择地，也可以将ValueEntityParentID设定为指向Cities实体)。

根据本发明者的经验，在很大程度上来讲，ValueEntity是最常用的Value表。

支持其他模式指针

可以将Value表创建为指向该模式内的任意其他表。这具有许多潜在的应用。

如果将数据库用于连接到外部数据库、系统或资源，那么也可以将Value表创建为指向多个表、多个目录、多个设备等等。

支持可选的多个值

FieldType/Field功能性的基本假定是“在创建实体时，为针对EntityType定义的每一个FieldType创建字段”。

不过，该模式允许用于任意指定FieldType的任意数量的字段，而这在标准模式中却需要额外的表和关系。

图8示出了在FieldType表中的新列-IsMulitple、MultiplesToCreate和MaximumMultiples，可以将它们用于定义多种方式，多字段可以以这些方式起作用。通过将IsMultiple设定为True来激活多字段功能。

例如，如果IsMultiple为True，那么在创建实体时，创建与MultiplesToCreate中设定的字段一样多的字段。一旦创建，如果设定了MaximumMultiples，那么用户就可以添加高达MaximumMultiples的更多FieldType字段，否则，用户可以根据意愿添加任意的多个字段。如果设定了MultiplesToCreate，那么用户还可以删除下至MultiplesToCreate的多字段，否则，用户可以将该FieldType的所有字段删除。例如，可以将该功能用于提供存储任意数量的客户电话号码，或者用于提供存储来自表单(使用ValueEntity字段)中的多选列表框的选择。

支持字段改变历史/审计追踪

标准数据库模式的一个最苛刻需求是支持所有值的全部改变历史。目前存在的问题在于：对于每一个被存储的项目，标准模式为表中的列仅提供一个存储位置。一般是将改变历史存储在日志表中，并通过表和列名来引用改变。在标准模式中，一般很难显示当其在指定日期出现时的记录。

图8示出在FieldType表中的称为KeepHistory的新列。此外，现在，所有的Value表均有两个新列-IsCurrentValue和DateTimeLastWritten。

在FieldType的KeepHistory为True时，每当值改变就将新记录写入定义的Value表中，将IsCurrentValue设定为True，并且将字段的所有先前值的IsCurrentValue设定为False。仅仅在创建历史字段值时，才设定DateTimeLastWritten列。DateTimeLastWritten提供改变的时间戳，而且在软件不能执行上面的IsCurrentValue规则时，还提供恢复的途径。

因此，从模式返回当前数据的查询的必需组成部分是：它们必须在全部Value表中规定IsCurrentValue＝True。然而，为了及时检索当其在指定点时的数据，使用TOP 1和用于任意日期时间的“小于或等于DateTimeLastWritten”的简单查询会提供历史视图。

通过显示具有所有历史值的实体，可实现完整的审计追踪。

支持共享字段类型

能够共享若干个EntityType之中指定的FieldType是有用的。该模式允许这种共享布置，所需要的是定义并实现该功能的方式。

共享FieldType的一种方法如下：

1.创建称为“共享实体类型”的共享EntityType

2.为该EntityType创建“最后修改”FieldType

3.创建EntityType“Client”缺省实体

4.将Client EntityType的DefaultEntityID指向该缺省实体

5.从“共享实体类型”EntityType中将“最后修改”FieldType字段添加到该缺省实体中。

即使没有针对全部其它EntityType的缺省实体的EntityType直接定义缺省实体，所述全部其它EntityType也可以在它们的缺省实体中包括“最后修改”字段。

由于缺省实体克隆是基于实体和字段数据(仅使用来自EntityType表的DefaultEntityID)，所以，可以将针对任意其他EntityType定义的任意FieldType添加到缺省实体，从而形成该EntityType的所有创建的新实体的一部分。该强大的功能允许将单个FieldTypeID用于许多EntityType表中的公用字段。

支持值继承

当创建新实体时，对于值来说，从父(或任意其他)实体继承它们的数据是有用的。如果新实体具有这样的字段，所述字段具有与其父实体(或用户可能希望提供作为数据源的任意其他的实体)相同的FieldTypeID，那么能实现继承。在以上“支持共享字段类型”的部分描述了如何能共享FieldType。

图8示出了在FieldType表中的“继承”布尔列。当将其设定为True时，该FieldType表会在其创建父实体(或其他提供的实体)中搜索与自身相同的FieldType的字段，如果其发现了一个这样的字段，则将该字段的数据值复制到该FieldType表自身的数据值中。

该功能对于许多需求是有用的，这些需求之一是在将子实体添加到层次中时查找缺省值。

支持数据格式化

一种常见的需求是为了显示而对存储为指定数据类型的数据进行格式化。需要以某种方式对许多数据类型进行格式化，从而理解它们，并根据某一标准来阐明它们的意义或表示值。

图9引入了Format表，在FieldType表中引入新指针FormatID，在ValueType表中引入DefaultFormatID以及在DataType表中引入DefaultFormatID。

该Format表提供Name列、Format列以及DataTypeID列。

该Name列用于给予该格式的功能名称，而Format列用于存储格式串。

设定DataTypeID以定义该格式被设计用于的DataType。

通过设定DataType的DefaultFormatID，每一个新的ValueType均可以根据其使用的DataType来设定其DefaultFormatID。同样，任何新的FieldType也可以根据其使用的ValueType来设定其FormatID。

如果需要显示字段，则代码可以依次检验如下成分，直到发现已被设定的FormatID为止，这些成分是：

1.FieldType表的FormatID

2.ValueType表的DefaultFormatID

3.DataType表的DefaultFormatID

格式串与任意的格式功能对应，所述格式功能由程序设计语言和任意的自定义格式化结构支持，可以由用户他们自己的代码支持所述自定义格式化结构。

能应用的格式的例子如下表2所示：

数据类型	格式
数据类型	格式	布尔	Yes/No
布尔	On/Off	布尔	Yes/No

货币	$0,000.00
货币	$0,000.00	货币	0.00
日期时间	dd-mm-yy	货币	0.00
日期时间	dd-mm-yy	日期时间	dd-MMMM-yyyy

表2

支持字段组或行

为各种目的而将字段集进行分组是有用的。这种目的可能是一个值需要两个或更多个数据存储位置，或可能是在公共环境中将许多字段合并成一行。

在图10中引入FieldRowType表和FieldRow表。

注意，FieldRowType表包括与FieldType表相同的三个多重控制列。针对FieldRow，这可以实现针对Field的在上面部分“支持可选值或多个值”中详述的相同多重功能。

现在，FieldType表也包括FieldRowTypeID列，Field表包括FieldRowID列。

如果需要在实体下将字段集分组，那么针对EntityType(通过设定其EntityTypeID)来定义新的FiledRowType入口，并且合并通过将所有的FieldType的FieldRowTypeID设置为新的FieldRowType的ID而分组的所有FieldType。

当创建新的实体时，为每一个FieldRowType创建新的FieldRow，FieldRowType是针对实体的EntityType而定义的。当创建对应字段时，将它们的FieldRowID设定为FieldRow的ID。这样，以与通过定义的FieldRowType将FieldType进行分组的相同的方式将字段分组。

支持增量值

通常要求新实体具有对应唯一增量数字代码，或具有数字代码与一些其他字段或本年度等的组合。在标准模式中，这常常由数值ID列或单独的增量列提供。

在该模式中，有一些可被采用为提供增量值功能的方法。

这些可用的方法是：

1.使用SQL在数字Value表中查询指定FieldType的最大值，然后将该最大值加1，并将新值输入新的Value中。

2.在FieldType表中增加NextIncrementor列，当写FieldType的下一个Value时使用它的值，并将NextIncrementor列加1，然后更新FieldType记录。

3.使用指定EntityType的实体的计数来计算增量值。

显示服务

优选的是提供显示、编辑、列表和另外与数据库的数据交互的相容系统(consistent system)。

在标准模式中，不容易定义用户与数据交互的方式，因此，通常在代码中将其定义为逻辑上存在的“表单”，而并没有在数据库中定义。

根据本发明的优选实施例的模式，允许与EntityType表和FieldType表的直接关系，等同于分别与表和列的关系。如果需要，可以在一些数据库中使用系统表链接这些关系。

在该部分中详述的显示系统使用表单来针对规范的功能定义用户界面，所述功能包括：

·查看

·编辑

·列表

·搜索

·报告

该系统也提供具有多个选项卡的表单。

表单

表单是一种这样的机制：即，用于为指定EntityType的所选择的一组FieldType提供视图，并根据希望的布局来分组和定制。

例如，当其他雇员查看雇员表单时，由于不应包括某些保密信息，所以表单把那些数据排除。另一方面，当经理查看他下属的信息时，可以使用包括保密数据的另一张表单。

图11示出链接到EntityType表和FieldType表的Form模式组成部分。EntityType表和FieldType表与图2至图10所示的表相同。因此，图11是图2至图10的扩充。

该Form表具有Name、指向EntityType的ID的EntityTypeID和指向定义了表单功能(例如，查看/编辑、列表、搜索等)的FormType的ID的FormTypeID，所述EntityTypeID为EntityType提供其服务。

FormField表为Form表定义一组选择的FieldType。FormField具有Name、识别包含的FieldType的FieldTypeID以及FormGroupID，所述FormGroupID用于选择在其中显示FormField的表单组。FormField还具有ControlTypeID，所述ControlTypeID用于选择在显示或编辑FormField时要使用的控件。

为了定义Form表，在Form表中输入新记录并给它一个名称。将FormTypeID设定为相关的FormType(例如，查看)。将EntityTypeID设定为指向我们为其创建Form(例如，Client EntityType)的EntityType。

然后，在FormGroup表中输入一条或更多条记录，给每一条记录一个名称(例如，客户详细资料、注册详细资料等等)。

对于希望在Form上显示的每一个FieldType，在FormField表中输入一条记录。给每一条记录一个名称(注意，可以使用FieldType的名称，另外也可以复制该表单中的不同名称)，然后将各种ID指针这样链接：即，将FormID链接到新的Form入口，FormGroupID链接到适当的FormGroup入口，FieldTypeID链接到要显示的FieldType以及ControlTypeID链接到适于显示字段数据的ControlType上。

FormField表也可以包括许多支持列，以定义其特征，例如：

·帮助文本

·仅查看

·字体(

·颜色

·其他

ControlType表具有支持查看和编辑控件的列表，例如：

·复选框

·单选按钮

·文本框

·文本区

·日期控件

·其他

该列表可能包含一列由开发语言和/或HTML控件支持的控件，但其也可以包含一列由代码支持的自定义控件。

该ControlType表也可以包括许多支持列，以定义某些控件需的结构要求，例如：

·最大字符数

·宽度

·高度

·字体

·颜色

·其他

Form系统的应用例子如下所示：

例子1：查看表单

图12示出由使用该模式的系统生成的查看表单的例子。其在左边示出FormField名称以及示出FormGroup分组的例子。显示的数据来自所选择的实体，在此显示的是本发明者的Staff实体。因此，该表单被设计为显示Staff实体。

例子2：编辑表单

图13示出由使用该模式的系统生成的编辑表单的例子。示出了图12所示的编辑表单的一部分处于编辑模式下。同时也示出了ControlType的应用，所述ControlType包括文本输入框、具有其他项的下拉列表框(Dropdown with Other)、密码框以及文本区(TextArea)。

同时也示出了在表单中可以如何管理多重选项。包含多重Fieldype的FormGroup显示这样的对话框：即，其允许用户设置他或她希望增加的多重选项数量。每一个多重FieldType均具有允许用户删除任意现有的多重选项的删除复选框。当使用这些控件中的任何一个控件时，在用户点击提交按钮时请求动作发生，然后用户返回到编辑模式。

例子3：历史表单

图14示出了图12所示的表单的一部分处于历史模式下。

该表单允许操作员看到曾经对示出的字段所做的全部改变。

例子4：列表表单

图15示出定义用于列出EntityType的列的表单。

例子5：报告表单

图16示出用于构建报告生成器表单的表单。该表单用于根据所选择的FormField生成报告。以按定义的顺序显示。用户可以设定搜索条件，所述搜索条件包括比较运算符(例如＞4)、日期范围以及ValueEntity选择(使用下拉列表框控件)。

支持FieldRow的显示

图17示出链接到EntityType表、FieldType表以及FieldRowType表上的表单模式组件。EntityType表、FieldType表以及FieldRowType表与图2至图10所示的表相同。因此，图17为图2至图10的扩充。

图17引入了FormRow表以及FormField表中的新列FormRowID。

为了显示FormRow，用户必须定义对应的(多个)FieldRowType。

当用户希望在表单中显示一行控件时，首先，他或她在FormRow表中创建具有适当名称的入口(应当注意，用户可以复制该FieldRowType的名称或使用该表单中的不同名称)，然后，将FormID设定为新表单的入口，将FieldRowTypeID设定为他或她希望显示的FieldRowType的ID。

用户希望显示为所述FormRow的一部分的FormField具有指向所述FormRow的ID的它们的FormRowID列。

当显示Form的代码遇到具有指向FormRow的指针的FormField时，该代码可以集合属于该FormRow的所有其他FormField，并相应地对它们进行分组(例如，以表单的单行将它们示出)。

支持多选项卡式表表单(Tabbed Forms)

图18示出链接到EntityType表、FieldType表以及FieldRowType表的表单模式组件。EntityType表、FieldType表以及FieldRowType表与图2至图10所示的表相同。因此，图18为图2至图10的扩充。

本质上，选项卡式表单是一组表单，每一个表单均表示EntityType的不同部分或功能。

图18引入了FormTab表以及Form表中的新列FormTabID。

为了创建选项卡式表单集，用户输入新的FormType，并进行如上所述的配置。

用户为每一个Tab创建一个表单集，如上所述，将它们所有的FormTypeID设定为新的FormType。

在FormTab表中为每一个刚创建的新表单创建一个入口，给每一个入口一个Tab名称，并将FormTypeID设定为新的FormType。

将每一个新的表单FormTabID设定为其对应的FormTab入口。

当显示表单的代码发现设定了它的FormTabID时，其可以定位到它的FormType，并显示所有属于该FormTab集的Tab。

FormTab表包括作为用户可将过程链接到FormTab的提示的ProcessEntityID。在该模式中，可以容易地将过程定义为过程EntityType，同时ValueEntity字段提供过程路径。

全局显示引擎

在此描述的表单系统提供了全局显示引擎的存储系统，可针对该模式中定义的所有实体统一地实施该全局显示引擎。

这意味着可实施单个的代码集来对所有已定义的实体进行查看、编辑、列表、搜索以及报告。

全局报告引擎

以类似的方式，可以构件全局报告引擎以涓埃女冠其服务统一提供给数据库中定义的所有EntityType。

全局排序、ID枚举和数据库同步服务

排序

为了能在该模式中进行排序，可以在每一个表中包括数值排序列。通过以期望的数值顺序设定该列的值，SQL语句可以包括ORDER BY排序的子句来按定义的顺序返回记录。

ID枚举

取决于该模式的用法，与其交互的代码需要转换链接到任何一个该模式表标识符的功能。

如果ID是数字的，则可以手动地将代码中需要的ID包括在适当的枚举器中。该模式的推荐ID格式是GUID(全球唯一标识符)，大多数语言并不允许这样的枚举器。用户可以将GUID定义为常数或对象。

无论使用哪种形式的ID，都有从数据库中直接自动产生ID模块可能性，从而消除了人为误差以及大量的开发开销。该模式的发明者已实现了这样的系统，并自动生成了IDFactory的动态连接库，在已将新的枚举器项目添加到数据库中之后，通过重新运行IDFactory生成程序能快速地对其进行更新。

为了支持这种自动生成和/或标记模式中所有的那些记录，我们将布尔Enum列包括在每一个表中所述记录在代码中被激活(switched on)。然后，开发者通过将该记录的Enum列设定为True(非零)来将模式中的记录定义为在代码中被激活。然后，可以将其用于在模式中查询代码中需要的ID，并因此生成定义这些ID的代码。

数据库同步

该模式适于中心ID主数据库的系统定义，将这些定义的全部或部分地传递给实际运行的数据库，在这些数据库中也存储数据。

为冗余度和负载平衡的目的而维护不同服务器上的几个数据库，这也是常见的需求。

为了便于多个数据库之间的数据同步，可以将DateTimeLastModified列添加到该模式的每一个表中。当更新记录时，更新该模式中的记录的所有代码必须将当前数据存取时间写入那个记录的字段中。

然后，通过比较记录的LastModified字段来执行数据库同步。

数据存取服务

应当认识到，对于不熟悉的用户来说，一开始会难以理解根据本发明的模式的模式图。因此，可以以相对标准和可理解的方式将根据本发明的模式中存储的数据呈现出来。例如，是这样的情况：如果第三方报告或数据分析引擎需要对该数据进行存取，或如果与其他数据库接连。

视图

有一些方法来以标准表视图呈现数据，所述标准视图如下：

·连接视图

·子选择视图

·功能视图

用于生成视图的所有方法也可以生成临时表。

这些视图可以根据EntityType的定义返回标准表。

自动生成视图

重要的是，可以根据EntityType的定义而直接自动地生成视图生成SQL。这提供了自动生成视图的两种独立用法：

1.在重新定义EntityType时更新视图

2.动态实时(on the fly)生成视图并单独使用

这里的重点在于：通过以显示的表单上的单独使用视图或选定FormField和条件的报告表单作基础，可以获得非常优良的性能。

尽管已根据优选实施例对本发明进行了描述，但其本意并不是将本发明局限于这些实施例。对本领域的技术人员显而易见的等同方法、结构、设置、过程、步骤和其他改变均落入如下的权利要求的范围之内。

Claims

1.一种计算机软件产品，其包含由电子处理器执行的机器可读指令，以根据一种模式来提供数据库管理系统，所述模式包括：

第一个表，其存储各种实体类型的名称；

标识符，其指示在所述表的每一个中存储的数据的性质。

2.根据权利要求1所述的计算机软件产品，其中，所述模式包括应用于所述第一个表的第一层次关系和应用于所述第二个表的第二层次关系，以便于对层次实体进行定义。

3.根据权利要求1所述的计算机软件产品，其中，所述模式包括存储所述实体之间的关系的表。

4.根据权利要求1所述的计算机软件产品，其中，所述第一个表包括存储与实体类型对应的指针的列，所述指针指示位置，在所述实体类型的新实例创建期间可以从所述位置获得缺省值。

5.根据权利要求1所述的计算机软件产品，其中，所述第三个表包括存储以下数据的列，所述数据指示根据在所述一个或多个值存储表的列中存储的数据来产生新创建实体的名称。

6.根据权利要求1所述的计算机软件产品，其中，所述一个或多个值存储表中包括多个值表，所述每一个值表均包括特定类型值的列。

7.根据权利要求6所述的计算机软件产品，其中，所述值表中的一个或多个值表每一个均与所述模式的一个或多个表相关。

8.根据权利要求7所述的计算机软件产品，其中，所述一个或多个值表每一个均与所述第二个表相关。

9.根据权利要求8所述的计算机软件产品，其中，设置所述一个或多个值表以存储指向存储在数据结构外部的数据的指针，所述数据结构由所述计算软件产品创建。

10.根据权利要求6所述的计算机软件产品，其中，所述模式包括数据类型表，所述数据类型表将所述值存储表的名称与特定类型值的列的对应名称联系起来。

11.根据权利要求10所述的计算机软件产品，其中，所述数据类型表与所述第三个表相关。

12.根据权利要求11所述的计算机软件产品，其中，所述数据类型表与中间值类型表相关，并且其中所述值类型表指向所述第三个表。

13.根据权利要求1所述的计算机软件产品，其中，所述第三个表包括定义多字段功能的列。

14.根据权利要求6所述的计算机软件产品，其中，所述第三个表包括指示是否存储关于对应字段类型的历史数据值的列，并且其中所述值存储表每一个均包括存储所述字段类型的当前值、以及存储指示何时写入所述当前值的数据的列。

15.根据权利要求6所述的计算机软件产品，其中，所述第三个表包括这样的列，其存储指示新创建的实体实例的值是否是从另一个实体实例继承的。

16.根据权利要求6所述的计算机软件产品，其中，所述模式包括格式表，所述格式表具有存储数据存储格式的列。

17.根据权利要求6所述的计算机软件产品，其中，所述模式包括一个或多个存储指示字段集分组的值的表。

18.一种借助于电子处理器实现的存储数据的方法，所述数据与多个不同实体类型的实体和所述不同实体类型之间的关系相关，所述方法包括：

将所述实体类型的每一个的标识符存储在第一个表中；

19.根据权利要求18所述的方法，进一步包括：

通过将第一层次关系应用于所述第一个表且将第二层次关系应用于所述第二个表来存储层次实体。

20.根据权利要求18所述的方法，进一步包括：

将数据存储在一个或多个定义所述实体之间的关系的表中。

21.根据权利要求20所述的方法，其中，所述存储定义关系的数据的步骤包括：

将识别不同关系类型的数据存储在第五个表中；以及

将识别关系的数据存储在第六个表中。

22.一种根据权利要求18所述的方法进行操作的计算装置。