关系数据库管理系统中用于支持动态运行时间对象定义的方法和装置

摘要

一种用于提供关系数据库中的动态运行时间对象定义的方法和系统。在应用程序(100)和数据库对象之间引入中介层。该层可以中介对数据库对象,例如表(1500),的访问,并允许应用程序嵌入逻辑名而不是物理名。如果需要,在应用程序运行时,可以动态维护中介层。中介层最好可以在多种关系数据库上运行,克服关系数据库厂商引入的对SQL的特定厂商扩展。

说明书

发明领域

本发明涉及数据库系统和方法。

背景技术

访问关系数据库的应用程序通过名字来引用数据库中的对象(表，列等等)。这样就会在应用程序和数据库对象之间产生紧耦合。当对数据库或应用程序进行更新时这种紧耦合会造成复杂化。在多个应用程序引用相同的对象以及应用程序本身在安装位置于不同的时间更新时，这种复杂化情况会进一步加重。

以上问题的传统解决方式是使用关系数据库所通常提供的“视图”结构。但是，由于众所周知的更新视图的缺陷并且视图在其定义中通常包括非标准SQL语法，因此使用数据库视图也是有问题的。能够在不同厂商的关系数据库上运行是一种理想的性能。

发明内容

本发明致力于实现一种能在关系数据库中进行动态运行时间对象定义的方法和装置。

在本发明的一个示范性实施例中，在应用程序和数据库对象之间引入一个数据和处理层。该层可以中介对物理层的访问并使得应用程序可以嵌入逻辑名而不是物理名。如果需要的话，在应用程序运行时，本发明还允许对该层的维护能够动态发生。中介层最好能够在多种关系数据库上运行，并克服关系数据库厂商引入的对SQL所做的特定厂商扩展。

本发明的一个示范性实施例是通过Platinum Technology公司的POEMS数据交换机(也叫做“DEX”)和POEMS服务处理机“ptsprdbm”来实现的。DEX存储中介层所使用的数据，处理工作由ptsprdbm服务处理机来完成。在该实施例中，DEX中介层可以看作是提交给DEX的消息与DEX的物理表布局之间的一种映射。这种映射允许与物理表的复关联，因此便使更高的层与物理实现的改变隔离开来。同样，中介还定义逻辑事务，这些逻辑事务把一个或多个应用程序请求与要在表或表系上执行的操作关联起来。

在一个示范性实施例中，每一个应用程序都会产生一个或多个请求，它们被发送到DEX。对于每个请求，DEX返回一个结果。可以有一个或多个ptsprdbm进程同时运行。每个应用程序请求由一个ptsprdbm服务处理机进程处理。中介层数据存储在DEX的元数据主题区域内。运行在相同机器上的所有ptsprdbm实例都引用相同的元数据。元数据把应用程序的请求映射到物理表上。因此应用程序不需要知道物理表的标识符。物理表会随时间变化，并且如果保持了元数据映射，应用程序就将与这些变化隔离开来。

例如，客户机程序可以通过一条消息请求与被称之为“机器”的逻辑实体有关的数据。逻辑名“机器”可以与被称之为“机器”的物理表相对应，也可以不相对应。中介层的责任是把逻辑事务名正确地转换为物理表名和列。

在另一个例子中，客户机程序可以提交一条被映射到名为“机器的ip address”的逻辑事务的消息，这里“机器名”＝absun10。在这个例子中，所引用的元素应当认为是必须转换成物理对象的逻辑对象。这种需要是因为所请求的数据同样会改变格式。例如在版本1的POEMS中，对于每个机器而言物理数据库只存储一个ip_address。但是在版本2的POEMS中，对于每台机器而言，物理数据库则可以存储一列ip_address。这会造成一个不同的结果集合返回给客户机程序，可能会中断客户机应用程序。使用中介数据，为版本2定义一个该服务处理机知道怎么处理的新的逻辑事务，这样就可以返回给客户机程序一个正确的结果集合。

按照本发明使用中介数据层的一个优点在于：应用程序可以定义包含有新的逻辑事务的新消息并使得DEX服务处理机能够正确地处理这些新消息而不用对现有的服务处理机作出修改。应用程序只需要在DEX元数据表中加入一行来定义一个新的逻辑事务。服务处理机知道如何把这些新消息映射到加入到元数据表中的逻辑事务数据并因此为这些新消息构建正确的SQL命令。

对物理数据库的改变也可以以类似方式进行处理。一个新的逻辑事务可以被定义为把旧的消息映射到一个新的表格布局上。这可以通过为每个事务使用一个版本号来完成，或通过从元数据中删除原始事务来完成。

元数据还可被用于把用户所创建的表集成到DEX中。用户可以使用标准SQL创建一个表，然后在DEX元数据表中加入行来描述这个新表。用户还可以创建per_triggers以便在现有的表被更新时，新表能够被自动更新。

附图说明

图1是根据本发明的一个示范性系统的框图；

图2是根据本发明的一个示范性进程的流程图。

具体实施方式

图1是根据本发明的一个系统的示范性实施例的框图，该系统通过POEMS数据交换机(DEX)1000来实现。POEMS DEX在PLATINUM条款公共服务参考指南这本书中进行了描述。DEX 1000包括多个物理表1500，并且可以与一个或多个应用程序100交互。应用程序100的例子包括ProVision Director和TS Reorg。

按照本发明，在应用程序100和DEX 1000的物理表1500之间提供一个中介层1100。中介层1100包括一个或多个POEMS关系数据库服务处理机(ptsprdbm)进程1150的实例和元数据主题区域1200。中介数据1250存储在元数据主题区域1200中。中介数据1250如下所述由ptsprdbm服务处理机1150使用。

中介层1100提供提交给DEX 1000的消息与DEX的物理表布局之间的映射。这种映射允许与物理表的复关联，因此便使更高的层与物理实现的改变隔离开来。多个逻辑名可以引用相同的物理对象并且逻辑名还可以随时间而变化。同样，中介还定义逻辑事务，这些逻辑事务把一个或多个应用程序请求(例如PEC消息)与要在表或表系上执行的操作关联起来。一个操作对应于数据操纵语言(DML)动词：插入、更新、选择和删除中的一个。

每个应用程序100创建一个或多个请求并把这些请求发送给DEX1000。DEX 1000为每个接收到的请求返回一个结果。一个或多个ptsprdbm服务处理机程序1150可以在任一时间同时运行。每个应用程序请求由一个ptsprdbm进程1150处理。所有在同一台机器上运行的ptsprdbm实例都引用相同的元数据。物理表可以有一个或多个。元数据把来自应用程序的请求映射到向物理表的请求。因此应用程序100不需要知道物理表1500的标识符。物理表1500可以随时间变化，并且如果保持了元数据映射，应用程序就将与这些变化隔离开来。

中介元数据1250可以进行更新，例如通过更新POEMS或应用程序100来对其进行更新。例如，一个新的应用程序100可以具有与置入元数据主题区域1200的应用程序相关的新的中介数据。这种功能所提供的灵活性在于：使用本发明系统的各种产品可以单独进行发展，而不需要所有的应用程序同时进行更新。最好，这种更新由服务处理机1150执行，这一点与向应用程序100提供对中介元数据1250的直接访问相反。

转换发生在DEX服务处理机1150中。服务处理机1150使用中介数据1250来执行这种转换。服务处理机1150最好使用一种标准的、开放式接口，如开放式数据库连接性(ODBC)，来连接元数据主题区域1200和/或应用程序100。

在另一个可供选择的实施例中，定制的POEMS ODBC驱动程序把服务处理机1150的转换层封装起来。然后，该驱动程序就可以由第三方应用程序使用以访问DEX(例如InfoReports)。

在一个示范性实施例中，中介数据1250包括如下的表系：

per_table：该表包括表格的总清单。DEX中的每个表在该表格中都有一个表目。

per_column：该表格包括DEX中每个表格的每个列的表目。与每个列相关联的属性是一个表中该列的类型、大小和位置。

per_data_type：该表包括所有支持的数据类型的总清单。

per_key：该表包括用于在DEX表上建立主关键字和外关键字的属性。

per_logical_object：该表识别逻辑事务，它被用于查找事务细节以及与该事务相关联的任何触发器。

per_tran_column：该表识别属于一个逻辑事务的列以及该列是否参与了SQL“where”子句的构建。

per_trigger：该表把触发器与一个或多个逻辑事务关联起来。

如下为用于把中介数据1250存储为元数据的一个示范性模式：

CREATE TABLE per_source(per_source_idiht NOT NULL，								source_description varchar(255)NULL，product_id int NULL，per_source int NULL，per_last_updated smalldatetime NOT NULL，per_status smallint NULL，CONSTRAINT XPKper_source PRIMARY KEY(per_source_id))CREATE TABLE per_tran_col_type(column_typesmallint NOT NULL，column_type_desc varchar(31)NOT NULL，per_source int NULL，per_last_updated smalldatetime NOT NULL，per_status smallint NULL，CONSTRAINT XPKper_tran_col_type PRIMARY KEY(column_type))CREATE TABLE per_logical_objectobject_idint NOT NULL，object_namevarchar(30)NOT NULL，per_source int NULL，per_last_updated smalldatetime NOT NULL，per_status smallint NULL，CONSTRAINT XPKper_logical_object PRIMARY KEY(object_id) )CREATE TABLE per_table								table_namevarchar(30)NOT NULL，storage_typechar(10)NULL，subject_areaCHAR(18)NULL，delete_policy CHAR(18)NULL，sequence_nbrnumeric(10，0)NOT NULL，per_sourceint NULL，per_last_updatedsmalldatetime NOT NULL，per_statussmallint NULL，CONSTRAINT XPKper_tablePRIMARY KEY(table_name))CREATE TABLE per_key(table name varchar(30)NOT NULL，kev_id smallint NOT NULL，key_type char(1)NOT NULL，fbreign_tablevarchar(30)NOT NULL，per_source int NULL，per_last_updated smalldatetime NOT NULL，per_status smallint NULL，CONSTRAINT XPKper_key PRIMARY KEY(table_name，key_id))CREATE TABLE per_data_typedata_typesmallint NOT NULL，data_type_desc varchar(31)NOT NULL，per_source int NULL，per_last_updated smalldatetime NOT NULL，per_status smallint NULL，								经CONSTRAINT XPKper_data_type　　PRIMARY KEY(data_type)　　)　　CREATE TABLE per_column　　column_namevarchar(30)NOT NULL，　　table_name char(18)NULL，　　table_sequence smallint NOT NULL，　　column_sizeint NOT NULL，　　null_flagsmallint NOT NULL，　　sequence_flagsmallint NOT NULL，　　per_source int NULL，　　per_last_updated smalldatetime NOT NULL，　　per_status smallint NULL，　　CONSTRAINT XPKper_column　　PRIMARY KEY(column_name，table_name)　　)　　CREATE TABLE per_key_column　　column_name varchar(30)NOT NULL，　　table_namevarchar(30)NOT NULL，　　table_namevarchar(30)NOT NULL，　　key_idsmallint NOT NULL，　　per_0source int NULL，　　per_last_updatedsmalldatetime NOT NULL，　　per_statussmallint NULL，　　CONSTRAINT XPKper_key_column　　PRIMARY KEY(column_name，table_name，table_name，key_id)　　)								CREATE TABLE per_tran_typetran_typesmallint NOT NULL，tran_type_name varchar(31)NOT NULL，per_source int NULL，per_last_updated smalldatetime NOT NULL，per_status smallint NULL，CONSTRAINT XPKper_tran_type　　PRIMARY KEY(tran_type))CREATE TABLE per_tranobject_idint NOT NULL，tran_typesmallint NOT NULL，tran_version char(10)NOT NULL，per_source int NULL，per_last_updated smalldatetime NOT NULL，per_status smallint NULL，CONSTRAINT XPKper_logical_tra　　PRIMARY KEY(object_id，tran_type) )CREATE TABLE per_triggerobject_idint NOT NULL，tran_typesmallint NOT NULL，trigger_sequence smallint NOT NULL，trigger_obj_name varchar(30)NOT NULL，trigger_tran_typesmallint NULL，per_source int NULL，per_last_updated smalldatetime NOT NULL，								　　per_statussmallint NULL，　　CONSTRAINT XPKper_trigger_det　　PRIMARY KEY (object_id，tran_type，trigger_sequence))　　CREATE TABLE per_logical_column　　object_idint NOT NULL，　　logical_col_id smallint NOT NULL，　　logical_col_name varchar(30)NOT NULL，　　column_namevarchar(30)NOT NULL，　　table_name varchar(30)NOT NULL，　　per_source int NULL，　　per_last_updated smalldatetime NOT NULL，　　per_status smallint NULL，　　CONSTRAINT XPKperlogical_col　　 PRIMARY KEY(object_id，logical_col_id)　　)　　CREATE TABLE per_tran_column　　object_id int NOT NULL，　　logical_col_idsmaUint NOT NULL，　　tran_type smallint NOT NULL，　　column_type smallint NOT NULL，　　join_column varchar(30)NULL，　　join_tablevarchar(30)NULL，　　where_flagsmallint NOT NULL，　　order_by_sequence smallint NOT NULL，　　group_by_sequence smallint NOT NULL，　　sub_tranvarchar(30)NULL，　　per_sourceint NULL，								per_last_updatedsmalldatetime NOT NULL，per_statussmallint NULL，CONSTRAINT XPKper_trans_detaiPRIMARY KEY(object_id，logical_col_id，tran_type))CREATE TABLE per_index_typeindex_typesmallint NOT NULL，index_type_desc char(20)NOT NULL，per_sourceint NULL，per_last_updatedsmalldatetime NOT NULL，per_statussmallint NULL，CONSTRAINT XPKper_index_type　　PRIMARY KEY(index_type))CREATE TABLE per_index(table_namevarchar(30)NOT NULL，index_sequencesmallint NOT NULL，index_typesmallint NULL，per_sourceint NULL，per_last_updatedsmalldatetime NOT NULL，per_statussmallint NULL，CONSTRAINT XPKper_index　　 PRIMARY KEY(table_name，index_sequence))CREATE TABLE per_index_column(column_sequence smallint NOT NULL，table_namevarchar(30)NOT NULL，								　　index_sequence smallint NOT NULL，　　table_name varchar(30)NOT NULL，　　column_namevarchar(30)NOT NULL，　　per_source int NULL，　　per_last_updated smalldatetime NOT NULL，　　per_status smallint NULL，　　CONSTRAINT XPKper_index_column　　 PRIMARY KEY(column_sequence，table_name，index_sequence)　　)　　CREATE TABLE per_config　　per_versionchar(10)NOT NULL，　　sp_version char(10)NOT NULL，　　doc_versionchar(10)NOT NULL，　　install_date smalldatetime NULL，　　per_source int NULL，　　per_last_updated smalldatetime NOT NULL，　　per_status smallint NULL，　　CONSTRAINT XPKper_config　　PRIMARY KEY(per_version，sp_version，doc_version)　　)　　CREATE TABLE per_status(　　per_status_nbr smallint NOT NULL，　　per_status_namehar(31)NOTNULL，　　per_source int NULL，　　per_last_updated smalldatetime NOT NULL，　　per_status smallint NULL，　　CONSTRAINT XPKper_status　　PRIMARY KEY(per_status_nbr)								　　)

图2所示的流程图描述了根据本发明的服务处理机1150的示范性操作方法。

如图2所示，在步骤2010中服务处理机1150(的一个实例)接收来自应用程序100的请求。这种请求被封装在应用程序请求内部的数据结构也就是请求数据结构或RDS中。在步骤2020中，服务处理机对这种应用程序请求进行解包并提取RDS的成员。数据成员包括标识符，标识符在步骤2030中由服务处理机使用来访问存储在DEX中的元数据。在步骤2040中，对照元数据对标识符进行处理。更明确一些说，服务处理机使用元数据来对请求内容接触引用并把请求的内容映射到元数据上。这种处理造成了RDS中的标识符被转换为物理表1500中使用的标识符。

解除引用这一步所返回的结果是一组用于当前的数据库实例的有效物理名。在步骤2050中，服务处理机获得该组物理名。然后在步骤2060中服务处理机使用这些数据来构建一个可以直接对数据库执行的SQL语句。再之后，在步骤2070中服务处理机执行SQL语句并收集SQL语句处理的结果。在步骤2080中，执行SQL语句的结果被重新映射到在步骤2010中所接收到的RDS中的逻辑名中。然后在步骤2090中把这些结果返回给与逻辑名相联的应用程序，以上逻辑名是应用程序在发出请求时所使用的。以此方式，应用程序便完全与物理数据库以及其中所使用的标识符隔离开来。

在本发明的另一个实施例中，还要存储与DEX数据有关的附加元数据，包含关于哪个实体对数据具有权威性的信息(也就是说，哪个应用程序拥有物理表中的数据，哪个应用程序就可以对这些数据进行更新或删除)。

在再一个示范性实施例中，显示信息和格式化信息被存储起来以用于每个逻辑对象，并且还可以为应用程序使用，用于在监视器或报告中呈现通过中介层访问的数据。在元数据中存储显示信息和格式化信息可以使得使用这些数据的应用程序能够动态呈现返回给它们的数据。