EP1405217A1

EP1405217A1 - A flexible virtual database system including a hierarchical application parameter repository

Info

Publication number: EP1405217A1
Application number: EP02737504A
Authority: EP
Inventors: Robert J. Tervin; Robert J. Santos; Shuen Mei
Original assignee: UBS AG
Current assignee: UBS AG
Priority date: 2001-06-14
Filing date: 2002-06-13
Publication date: 2004-04-07
Also published as: EP1405217A4; WO2002103573A1

Abstract

A virtual database system is disclosed that provides a flexible number and structure of database tables while using a fixed structure database system as its core. A table set (20), a column set (22), and an association set (24) are defined in an underlying fixed database environment. The data and relationships between these tables are used to define a virtual table (26) with a structure that can be varied as needed by application developers (and users) while the structure of the underlying fixed database remains unchanged. In a particular application, a hierarchical application parameter repository is implemented wherein parameters used by specific applications can be defined at various levels, such as for the application as a whole, for the application as used by a particular group, or as used by a particular user.

Description

A FLEXIBLE VIRTUAL DATABASE SYSTEM INCLUDING A HIERARCHICAL APPLICATION PARAMETER REPOSITORY

CROSS REFERENCE TO RELATED APPLICATION:

This application claims priority to U.S. Provisional Patent Application No. 60/298,286 filed June 14, 2001.

BACKGROUND AND SUMMARY:

There are many situations where a database system must be used by both application developers and application users. Often, the parties responsible for maintaining the integrity of the database system require that the structure of the various database tables and other constructs be locked so that changes cannot be made which would impact the operation of the various applications that access the database. However, during the development of an application that uses the database system, the structure of the various data tables and constructs used by the application can change. In a typical situation, the application developer would need to get approval for the change from a third party and than have the database unlocked so the change could be made. The process must be repeated if another change is needed. This is both a cumbersome and time consuming.

The present invention addresses this problem by providing a virtual database system that provides a flexible number and structure of database tables while using a fixed structure database system as its core. The virtual database tables and constructs can be varied as needed by application developers (and users) while the structure of the underlying fixed database remains unchanged, thus alleviating concerns regarding changes to the database.

The virtual database system can be used for a variety of applications. In a particular application, a hierarchical application parameter repository is implemented wherein parameters used by specific applications can be defined at various levels, such as for the application as a whole, for the application as used by a particular group, or as used by a particular user.

BRIEF DESCRIPTION OF THE FIGURES:

The foregoing and other features of the present invention will be more readily apparent from the following detailed description and drawings of architrave embodiments of the invention in which:

Fig. 1 is a block diagram illustrating the operating environment of the present invention;

Fig 2. is a diagram illustrating the high level architectural concepts of the present invention;

Fig. 3 is a diagram illustrating a fixed table set used for implementing the virtual table system of present invention;

Fig. 4 is an illustration of a virtual table definition;

Figs. 5a-5b illustrate a populated virtual table;

Fig. 6 is an illustration of a sparsely populated virtual table also showing changes to the virtual tables column structure;

Fig. 7 is a high level diagram of the virtual database translator system;

Figs. 8 -18 are flow charts illustrating the operation of various functions illustrated in Fig. 7;

Fig. 19 is a diagram of a hierarchical application tree;

Fig. 20 is a diagram of a conventional application parameter naming system;

Fig. 21 is a diagram illustrating the real and virtual tables used to implement the hierarchical application parameter repository aspect of the invention; Figs.22 and 23 are high level flow charts illustrating a method for getting and setting parameter values; and

Fig. 24 is a high-level diagram of the fixed table set for implementing the virtual table system and the hierarchical application parameter repository according to a preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS:

Turning to Figure 1, there is shown a high level diagram illustrating the environment in which the present invention operates. In particular, the present invention provides a virtual database system 10 which can be used by a number of application programs 12. The virtual database is configured to appear to an application program 12 as a conventional database system. The virtual database system 10 comprises a virtual database translator 14 which is connected to a fixed structure database 16. The fixed structured database 16 can comprise any conventionally known database environment. According to a particular aspect of the invention, the fixed structure database 16 is configured with a limited number of "real" data tables which are used to implement the virtual database system. Virtual tables can be defined, modified, and deleted by changing the contents of the real tables in the fixed database 16 without changing the structure or adding new tables to the fixed database 16. Because the structure of the tables in fixed structure database 16 does not need to be updated (although the table contents can change), these tables are also referred to herein as "fixed tables". In this manner, the application program 12 is provided with a flexible and easily changed database environment without compromising the integrity of the underlying fixed structured database 16.

According to a further aspect of the invention, a hierarchical application parameter repository is linked to the virtual database system. The repository provides a mechanism for storing and retrieving application parameter values and defining the values hierarchically, such that different values can be specified, e.g., at the level of an application, group, or user. The parameter repository is particularly structured to reduce storage requirements for application parameter names that have a high degree of redundant name segments.

In the description below, the virtual database system 10 and a particular implementation will be discussed. Next, a preferred methodology for accessing the virtual database system is addressed. Finally, the hierarchical parameter repository is discussed.

Turning to Figure 2 there is shown an illustration of the basic architectural concepts which define the virtual database environment. The virtual data tables provided by the system and the contents of the virtual tables are defined in a small and fixed number of logical groupings or sets. In particular, a first set 20 identifies potential defined tables, e.g., by providing a list of names or unique identifiers that can be attached to a defined virtual table. A second set 22 identifies columns which can be used in tables. A third set 24 specifies associations between, among other things, tables and columns.

A virtual table is defined when one or more columns in the column set 22 are associated with a "potential" table defined in the table set 20. A table in the set 20 can be associated with multiple columns in the column set 22 and one column can be associated with many different tables. The table set 20, column set 22, and association set 24 contain metadata which, taken together, defines the structure of the virtual tables which exist in the virtual database environment and which can be used by the application programs 12.

In addition to defining the structure of a virtual table, the present architecture further includes a data object set 26 which contains the actual data used to populate specified cells in a given virtual table. Each data object in the set 26 contains information which identifies a particular table, a particular column and row in that table, and the data contained in the cell at the intersection of the specified column and row. By implementing no more than the three meta-data sets 20, 22, 24 and the object set 26 in a suitable core database environment and appropriate functionality, as discussed below, a flexible virtual table database environment can be provided. Tables can be added, populated, and modified by adding entries to these four central sets without altering the structure of the implementation of the set in the database core.

Although the actual data which represents the name of a given table, column, or the contents of a given cell can be directly stored in the defined tables, columns and data object sets 20, 22, 26, preferably and additional set of tags 28 is provided which stores each unique data instance. Rather than containing identification or population data, the table definition and population sets 20, 22, 26 contain pointers to the appropriate entry in the tags set 28. As a result, unnecessary duplication of resources to store commonly entered and reused data is reduced. In addition, a change to the underlying data instance will immediately be reflected everywhere that instance is linked.

A variety of techniques can be used to store these limited number of sets in a conventional database system which forms the fixed structure database core 16 of the virtual database system 10. Provided that the sets can be adequately specified and their contents modified, the technology used to implement the underlying database 16 can vary. In a preferred implementation, the fixed-structure database 16 is a conventional relational database system. However, the basic architecture can be implemented in other systems, such as an object-oriented database and minor variations in implementation which may be necessary will be apparent to those of skill in the art.

As illustrated in Fig. 2, the complete virtual database environment 10 can be implemented using five discreet tables in a fixed database environment 16 - one table for each of the data sets 20-28. In a preferred implementation, however, a single master table which is used to store the data comprising table set 20, column set 22, and data object set 26. A second association table is used to store data which defines the association set 24. Finally, a third table is used to store the set of tags 28. As a result, only three tables need be implemented in the fixed structure database 16 in order to provide a practically unlimited number of virtual tables of flexible structure without requiring the addition of new data tables to the fixed structure database 16. The total number of virtual tables which can be defined and utilized is limited only by the operating capacity of the system of which the virtual database is implemented.

Advantageously, the small number of real data tables which are implemented in the fixed structure database 16 allows the database structure to be optimized to work with these data structures and also simplifies initial system setup and maintenance because of the relatively streamlined architecture. Further, the virtual database environment simplifies developing software applications in a database environment which must be tightly controlled in order to preserve system integrity. The table structure for complete and stable software can be directly implemented in the underlying core database system 16. However, tables used for systems under development can be implemented using the virtual database system, thereby permitting the developer to easily modify the structure of the tables for the new software without unlocking the tables in the core database. Similar considerations apply for applications in which users can customize the layout and contents of data tables used by the application.

Turning to Figure 3 there is shown an illustration of the three primary tables used to implement sets 20-28 of the virtual database environment in a relational database environment. The three defined tables are a master maps table 30, an association table 32, and a master tags table 34. The master maps table 30 is used to define the members in the table and column sets 20, 22 as well as store the data used to populate the virtual tables (e.g., the data objects set 26). The data entries shown in Fig. 3 are initial values that can be used to define the tables and columns sets 20, 22 as virtual tables.

The association table 32 is used to specify an association between different rows in the master maps table 30 for use in defining virtual tables. This is discussed more fully below. The master tags table 34 is a directory of unique data values, such as words or numbers. Each unique data value has a corresponding tag which is used for referencing the value. In a particular implementation, multiple master tags tables 34 can be provided, each of which is configured to store information of a specific data-type, such as string or numeric.

The master maps table 30 is comprised of four separate columns. The ID column 302 is used to store an identifying number or value which can be referenced in other columns of the master maps table 30. The TED column 304 is used to reference the identity of a particular table to which the given master maps row relates. The CID column 306 is used when a row in the master map table 30 indicates data for populating a cell in a virtual table and contains entries indicating the virtual table at issue and the row and column where the population data belongs. Finally, the tags column 308 is used to reference an entry in a master tags table 34 which provides a value for the respective table, column, or cell contents specified by the master maps table row. (The various tables implemented on the fixed database 16 will also generally contain one or more internal key columns which provide a unique identifier for each row in the table and which is used by the fixed structure database 16 when accessing the tables.) In implementations where multiple master tags tables are provided, and as discussed in more detail below, each one for a specified data type, the CID column can also be used to specify the data type to which the tag refers.

The master maps table 30 is initially populated with data that defines the table set 20 and column set 22 into which the defined list of tables and columns will be placed. Row 310 defines a virtual "meta-table" which stores the table set 20. A unique predefined "table definition" ID, here specified as "1", is used to indicate membership in the table set 20. A value of 1 in the TDD column 304 of row 310 indicates that this entry is a member of the table set. (In other words, the set of tables contains itself). The tag field of 1 identifies a tag value "table names" which is used to name the set of tables to give meaning to human operators. A tag does not need to be defined but is useful for functions such as displaying the set of defined tables.

Similar to row 310, row 312 in the master maps table 30 is used to define the initial meta-table to contain the set of columns 22. A predetermined "column definition value", here the ID of "2", is used to indicate membership in the column set. The column set definition row 312 has a TDD = 1 which indicates that the set of columns is itself a table which appears in the table names table. The column set definition row has a tag which links to the value "column names" which, as with the table names tag, is useful for display and manipulation of the set of columns but is not required.

In addition to the initial meta-table definition rows 310, 312, in a preferred implementation, two default column definitions (rows 314, 316) are also defined. These rows specify that the tags 1 and 2 represent members of the column set 22. To minimize the number of entries in the master tags table, the column definition rows 314, 316 point to the same tags as used to define the sets themselves. However, there is no requirement that this be so and any tag value could be referenced as desired. The association table 32 is initially configured to indicate that column 3 (e.g., the row having DD=3 in the master maps table 30) appears in table 1 (the meta-table of tables) and column 4 appears in table 2 (the meta-table of columns). For reference, a representation of the table set 20 and column set 22 is also shown in Figure 3.

Also shown in Fig. 3 are the contents of the table set 20, the column set 22 and the structure of the defined virtual meta-tables. The table set 20 contains two defined table identifiers entitled "Table Names" and "Col. Names" (as specified by the tag references to the master tags table 34). Similarly the column name set 22 also contains two defined column identifiers entitled Table Names and Col. Names. The associations in table 32 indicate that each table has a respective column contained in it. The initial data in the master map table 30 and association table 32 thus define the virtual Table Name table 20' which contains a column entitled Table Names and the virtual Col. Names table 22' containing a column entitled Col. Names. The virtual Table Names column of the Table Names table 20' also contains data (not shown for clarity) indicating the two defined tables, namely Table Names and Col. Names. The virtual Col. Names table 22' contains similar data.

Pre-definition of these virtual meta-tables is provided to permit easy manipulation of the virtual meta-tables. In particular, by defining the meta-tables 20', 22' to contain the table names and column names sets 20, 22 in this manner, these virtual tables can be operated upon using substantially the same methods as used to process other virtual tables defined by a user. As a result, the database functionality provided to access more general virtual tables can be leveraged for use with the meta-tables and the number of special-case routines which must be provided by the virtual database software environment for operating on the meta-tables is limited. However, the definition of these sets in the master maps, association, and master tags tables 30-34 is not an architectural requirement of the invention.

Membership in the table set 20 and column set 22 is indicated by the appropriate value in the TID field (e.g., a "1" or a "2"). Thus, the contents of these sets is implicitly defined in the master maps table 30 (as will be more fully explained by the following description) and appropriate software routines specially configured to operate on the table set 20 and column set 22 can be provided as needed.

After the initial meta-data has been defined in the virtual database system, the virtual table environment is configured and can be used to define, populate, and manipulate a variety of virtual tables. The creation and modification of an example table will be discussed with reference to figures 4-6.

Turning to Figure 4, there is shown the data table environment of Fig. 3 further containing definitions for a sample virtual table entitled "Members" which contains three columns: name, telephone, and e-mail. To initially define this virtual table, the data values which are used to define the name of the table and the columns in the table are added to the master tags table 34. Next, the master maps table 30 is updated to define a table called "members". This is accomplished by adding a new row 320 with a unique ID (here, ID=5) and which has a TED = 1 and a link to the members tag, indicating that DD=5 is a member of the table set 20 and has a name of "members". In a similar manner, the three columns (name, telephone, and e-mail) are defined with new rows 322, 324, and 326 in the master maps table 30 having TDD=2, indicating that those rows are members of the column set 22.

To complete the definition of the virtual table "members", entries must be made to the association table 32 to specify that the new columns are present in the virtual members table. Rows 328, 330, and 332 in the association table 32 indicate that the master map rows having DDs of 6, 7, and 8 are all associated with the row having DD=5. With reference to master maps table 30, the table identified by row 5 contains the columns defined by rows 6, 7, and 8.

For reference, also shown in Fig. 4 is the complete contents of the table set 20 and column name set 22 as contained in the master maps table 30 and the structure of the members virtual table 400 defined by the association data.

Once a virtual table structure has been defined, the virtual table can be populated with real data. Turning to figure 5 a, there are shown additional data entries to the master maps and master tags tables 30, 34 which populate two rows of the virtual table members 400. Each cell in a virtual table is populated individually by adding a row to the master maps table 30 which identifies the virtual table at issue, the column in that table, and the particular row in which the cell appears. The table and column are identified by referencing the appropriate table and column DD in the TDD and CDD fields of the master maps table 30. The row is identified by referencing a key which uniquely identifies each row in the virtual table. In accordance with a particular implementation of the invention, the "unique" key for a row in a virtual table corresponds to a value in the DD field of the master maps table 30. Although a key is unique for a given row in a virtual table, when that row contains multiple columns, the key DD value can appear multiple times in the master maps table 30 since several different cells can be separately defined for a specific row of a virtual table.

With reference to the example of Figure 5 a, the virtual table members 400 contains two populated rows (key DD = 9 and key DD = 10). Each row defines a name, telephone number and e-mail address of a given member. Each populated cell in the virtual table is defined by a corresponding row in the master maps table 30. For example, row 336 of the master maps table 30 has TDD=5 and a CDD=6. Cross-referencing these values to the DD column of the master maps table 30 indicates that this row relates to the "name" column of the "members" table. The ID value of 10 specifies the row at issue in that table has a key = 10 and the contents of the cell defined by the intersection of the row and column is specified by the tag value which, in this case, is "Jane". This row (key = 10) has three populated cells and therefore there are three rows in the master maps table 30 which contain an DD = 10. Similarly, a second row identified with a key = 9 has three defined cells in it and has three corresponding entries in the master maps table.

As further illustrated, both rows in the member tables specify the same telephone number. Through the use of the master tags table 34, the unique data item specifying the telephone number only needs to be stored once. Re-use of the unique data object is easily facilitated simply by referencing the defined tag, reducing the resources required to specify this data, particularly for commonly used data. In the embodiment discussed above, a single master tags table 34 is used. In certain implementations, it is impractical to use one tags table to store data values of different types. Accordingly, in a preferred implementation, multiple master tags tables are provided, each associating a given tag with a value of a specific data type. As in a conventional database system, a virtual column is specified to contain data of a given data type. The CDD field for a specific meta-data column or row entries in the master maps table 30 is used to specify the data type or a particular master tags table which should be used to evaluate tags in descendant rows referencing that specific meta-data row. Although this CDD value can directly identify a given master tags file, preferably, the linkage is indirect and specified via the association table 32.

For example, Fig. 5b shows the data environment of Fig. 5a having two separate master tag files, a first master tags table 34a containing text values and a second master tags table 34b containing numeric data (which is assumed, for purposes of the present example, to encompass formatted telephone numbers). The CDD fields (which are undefined in Fig. 5a) identify which of the two master tags files should be used when obtaining a value for a referenced tag.

More particularly, the CDD field in a specific meta data row identifies the tag file to be used for tags in "descendant" rows which reference the specific row. For example, in Fig. 5b, meta-data row 335, which defines the "telephone" column, has a CID=21. This value, as provided by entry 21 in the association table 32, references the "numeric" master tags table 34b. Data row 337 in the master maps table 30 (corresponding to the "telephone" cell in row key = 9 for the virtual member tables 400 shown in Fig. 5a) has a CDD=7. Cross-referencing row DD=7 (row 335) reveals that the Tag DD=8 should be evaluated with reference to values in the numeric value master tags table 34b as illustrated by the reference arrows in Fig. 5b. The appropriate master tags table to use when evaluating tags in other row entries in the master tags table 32 are evaluated similarly by determimng the meta-data row referenced in the given row and using the CDD specified in the parent row to determine which master tags table to use. As a further example, row 335 of the master maps table 30 has a TDD=2, referencing the meta-data row DD=2. Row DD=2 has a CDD=20 and thus the tag in row 335 (and all other column-definition rows) is evaluated against the "text" master tags file 34a.

Alternative mechanisms to identify the data type for a given tag can also be used. For example, an additional "tag-type" column could be added to the master maps table 30 to contain information specifying the data type for a tag in each row. This addition would simplify determinations of tag data types, since each would be expressly defined, and would also permit columns to be defined with multiple data types, since data types could be specified for each virtual table cell. However, this alternative could greatly increase the size of the master maps table 30 because the tag data type would need to be specified for each entry. In contrast, the preferred embodiment shown in Fig. 5b uses otherwise undefined CDD values and thus does not require adding further columns to the master maps table 30. Moreover, less typing data is required overall because each type definition is used for all "descendant" rows which reference it. (E.g., by defining the "telephone" column as having tags from the numeric master tags file, all cells in that column automatically inherit the numeric type).

Figure 6 is an illustration of the ease with which the present invention permits the underlying structure of a virtual table to be modified by adding entries to the master maps table 30. A new column can be added to a virtual table simply by adding an additional row of data to the master maps table 30 and a corresponding row in the association table 32. Additional tags can also be defined as required. Advantageously, adding rows to the underlying master maps, association, and master tags tables 30, 32, 34 does not alter the structure of those fixed tables, only their contents. As a result, after these tables are initially defined in the core fixed database system 16, their structure can be "locked", helping to preserve system integrity while still providing a flexible virtual database environment.

In the example shown in figure 6, a new row 338 is added to the master maps table 30 so as to add a new column "fax" to the column set 22. Row 340 added to the association table 32 specifies that the new column is a member of the table 5. These two entries are sufficient to define a new column of facts in the virtual table of members 400.

Also shown in Fig. 6 are new rows 342, 344 added to the master maps table 30 and which populate the name and fax columns of a newly-defined row ID=12 in the "members" virtual table 400. As will be appreciated, because the cells in each row are defined individually, the overall virtual table can be sparsely populated and system resources used only when storing data within a particular cell. If a cell is empty, then no resources are used to represent that fact. This can greatly reduce the amount of system resources needed to store a large but sparsely populated virtual table.

As discussed more fully below, by processing the information stored in the master maps and association tables 30, 32 and the one or more master tags tables 34 , the structure and content of a virtual table can easily be extracted and presented to an application program for subsequent use. The virtual table can be easily modified by adding appropriate rows to the underlying meta-data tables 30, 32, 34 and deletions of the contents of data cells, rows, columns, and even entire tables can be accomplished by removing the appropriate rows from the master maps and association tables.

Turning to figure 7 there is shown a high level block diagram of the various functional elements which comprise the virtual database translator 14 (Fig. 1). The translator 14 contains a number of different functional module groups which together implement a basic set of database functions that allow the virtual database system to appear to an application program 12 as if it were a conventional database. In addition to the functional modules, a separate virtual database interface 15 can be defined which permits application programs 12 to interact with the translator 14 using conventional programming techniques. Also shown in Fig. 7 is a database management system 17 which can be used by the translator 14 when accessing the contents of the fixed structure database 16.

The function groups illustrated in figure 7 have been arranged into broad groupings including a set of virtual element creation module 72, deletion module 74, table formatting module 76, data retrieval modules 78 and lower level virtual element mapping modules 80. These groupings are for convenience and discussion purposes only and the particular programming modules and functionality can be organized and arranged in a wide variety of different configurations. Moreover, as will be recognized by those of skill in the art, various of the specifically discussed functions can be combined and it may not be necessary to define all of the functions in particular implementations.

The virtual element creation module set 72 comprises functions which permit an application to define a new virtual table, add a new column to a virtual table, and populate a cell within a virtual table. The virtual element deletion module set 74 contains functions which allow an application program to delete a cell, row, or column of a virtual table or an entire virtual table itself. The data retrieval module set 78 contains functionality which permits an application program to retrieve the contents of a virtual table and also retrieve a list of the defined tables and the defined columns, e.g., the contents of the tables and columns sets 20, 22.

A table formatting module 76 can be provided to format retrieved virtual table data in a manner which is suitable for the programming environment. The particular table format used depends in large part on the operating environment present on the implementing system and the manner in which the application programs are allowed to access the data. For example, in one embodiment, the table formatting module 76 can be configured to return virtual table and other data in a format compatible with an Excel spreadsheet or a Microsoft Access database. A lower level element mapping module set 80 can be additionally provided and which comprises functionality for mapping a specific value name, such as "members" to a corresponding tag number, table ED, or column DD, so that application programs can reference tables and columns by their names.

A separate data cache 82 can be provided for use as a temporary repository for data retrieved from the fixed structure database 16. The cache 82 can also be used to store images of particular virtual tables so that repeated use does not require that the structure and contents of the virtual table be continually rebuilt from the source data in the master maps, tag, and association tables 30, 32, 34. Any suitable caching system known to those of skill in the art can be used and the types of data which is cached and the manner of caching is a matter of design choice.

Figures 8 — 18 are flow charts which illustrate a particular methodology which can be used to implement the various functions specified in figure 7. Each of the flowcharts will now be discussed. For simplicity, the various virtual database functions are discussed with reference to a single master tags table 34. In an embodiment having multiple master tag tables for various data types, the described functionality can be extended to include the data typing and CDD cross-referencing necessary to manage and use the various master tag tables. Such data-type aware functionality can be implemented in various ways and appropriate methods will be known to those of skill in the art.

Turning to figure 8 there is shown a flow chart of a method for retrieving a list of the defined table and column names in the virtual database. This functionality is useful for providing information to an application program for building and editing virtual tables. Initially, the system receives a request to list those defined virtual tables or columns in the system. (Step 800). The master maps table 30 is accessed and those entries which indicate members in are in the table 20 or column set 22 (e.g., rows having a TDD =1 or 2, respectively) are retrieved. (Step 802). The tag value in each retrieved row is evaluated against the master tags table 34 to obtain the value of the identified members of the table or column set. (Step 804) The retrieved list can be returned as a collection or list of name data to be used by the requesting application. Preferably, however, the data is formatted as a table having a single column and is returned to the user in a manner similar to that used to return virtual table data. The name of the returned table is specified by the tag which is present in the default table set identifier in the master maps table 30, e.g., row 10=1 but can alternatively be specified in the formatting routine.

The table is formatted with a column that contains the members of the table or column set 20, 22. The column is given a name in accordance with the tag indicated in the appropriate master maps table row. (Step 806) Referring to the example data shown in Fig. 3, the table containing members of the table set 20 and the column within that table are both defined as "table names". Finally, the data can be formatted in accordance with general system requirements and perhaps options specified by the calling application and then returned to the calling program. (Step 808).

Figure 9 is a flow chart illustrating a general method for retrieving the contents of a virtual table. Initially, a request is received by the virtual table system to retrieve the contents of a virtual table having a specified DD (Step 900). The row in the master maps table 30 having the specified table DD is retrieved and the defined tag is mapped to the master tags table 34 in order to obtain the name of the virtual table. (Step 902). Alternatively, if the table is specified according to its name, a GetTableDD function can be implemented in order to map the name to a corresponding DD in a master maps table 30. A method for doing this is illustrated in figure 11, discussed below. After the table DD is identified, the association table 32 is accessed to identify the columns which have been associated with the particular table. (Step 904). The corresponding rows in a master maps table for the associated columns are accessed and the defined tags are mapped to the master tags table 34 to identify the names given to the columns in the virtual table. (Step 906). The retrieved table and column names are then used to build the structure of the virtual table. (Step 908). The particular form in which the table structure is defined is dependent upon how the virtual tables are to be represented in system memory and returned to an application program. Different formats are available and will be known to those of skill in the art.

After the virtual table structure has been identified, the data populating the virtual table is retrieved. First, the rows in the master maps table 30 which contain a TDD equal to the defined table DD are identified. The DD for each identified row in the master maps table 30 identifies a particular row in the virtual table and the corresponding CDD value identifies a particular column. The two values thereby define a unique cell in the virtual table the contents of which is specified (indirectly) by the tag in the respective row of the master maps table 30. (Step 912). After all of the table-populating rows have been processed, the populated virtual table is formatted as appropriate, and possibly in further accordance with user input options, and the virtual table is returned to the calling program. (Step 914).

Figure 10 is a flow chart illustrating a method for defining a new virtual table. After receiving a request from an application program to define a new virtual table with a specified name, the tag corresponding to the desired virtual table name is retrieved from the master tags table 34 or, if needed, a new tag is defined. (Step 1000). Next, a new entry in the master maps table 30 is created having a unique DD, a TDD referencing the table set (TDD=1) and having a tag which references the table name entry in the master tags table 34. (Step 1002). Next, input is received identifying the columns which are to appear in the new table. (Step 1004). (The table definition can be an interactive or iterative process. Alternatively, the application program can pass all of the table definition parameters at once).

Before columns are added to a virtual table, they must be defined as members of the column set 20. If a new column is needed (Step 1006), a new or prior tag value is defined or identified having a value for use as the column name. (Step 1008). A new entry in the master maps table 30 is then created having a unique DD and a TDD= to 2, signifying membership in the column set, and further referencing the appropriate column name tag. (Step 1010). Finally, each column which is to appear in the new virtual table is linked to the table by an appropriate entry in the association table 32. (Step 1012).

In many functions, an application program will reference a virtual table by its name, and not its reference number. Accordingly a GetTableDD function can be provided to map a key word to a corresponding table DD number. With reference to the flow chart of Figure 11, the function receives a key word table name as input. (Step 1100). The key word is mapped to the master tags table 34 to obtain the tag with a value equal to the key word. (Step 1102). If there is no defined tag for the specified value (Step 1104) then an error code can be returned (Step 1110). Otherwise the tag value is mapped to the collection of defined tables in the master maps table 30 (e.g., those rows having a TDD=1) to identify a particular row in the master maps table having the appropriate tag value. (Step 1106). If no row is identified then an error code can be returned. (Steps 1108, 1110). Otherwise, the DD for the master maps row is returned to the calling program (Step 1112).

Figure 12 is a flow chart for a function which will return a column DD corresponding to specified key word. The key word received as input is mapped to the master tags table 34 to obtain the tag value corresponding to the key word. (Steps 1200, 1202). If no tag is defined, an error code can be returned. (Step 1204, 1210). Otherwise, the identified tag is mapped to those rows in the master maps table 30 which have a TDD=2, indicating membership in the set of defined columns. (Step 1206). The DD from the identified row is returned to the calling program. If no such row is present, an error code can be returned. (Steps 1208-1212).

More generally, a number of operations on a virtual table require determining a tag which corresponds to a specified value. A particular implementation of a general GetTag function is illustrated in figure 13. Initially, the value data is received as input (Step 1300) and that value is mapped to the master tags table 34. (Step 1302). Preferably, and unlike the more specific GetTableDD and GetColumnDD functions, if the specified value is not present in the table (Step 1304), the value is added to the master tag table and a new corresponding tag value is defined. (Step 1306). The previously or newly-defined tag is then returned. This GetTag functionality is particularly useful when new tables, columns, and cell contents are defined because the act of definition implies that a new tag value be created if one does not already exist. Preferably, the GetTag function is implemented with a flag which would disable the automatic updating of the master tags table 34 and thus permit the system to easily determine if a tag has been previously defined or if the reference is to an undefined value.

Figure 14 is a flow chart illustrating a basic method for populating a cell in a previously defined virtual table. A populate cell request receives as input the identity of the table and column at issue, the key for the row containing the cell at issue, and the data to place in that cell. (Step 1400). If necessary, the DD for the specified table and column are retrieved. If the table and column are not previously defined, appropriate errors can be returned to the calling program. (Steps 1402-1412). Once the table and column DD have been determined, the specified key for the row is examined.

Specifying a row key equal to zero or null can be used to indicate that a new row should be defined in the specified virtual table. (Step 1414). Alternatively, another predefined input or program flag can be used to specify a new row definition. If a new row is to be defined, a unique DD value is generated (relative to the previously defined DDs in the master maps table 30) and used as the key for the row. (Step 1416). The tag corresponding to the desired cell value is then retrieved, perhaps with the addition of that value to the master tags table 34 as provided by the GetTag function of Fig. 13. (Step 1418). Finally, a new row in the master maps table 30 is created having an DD equal to the specified or newly-defined row key, a TDD equal to the table DD, a CDD equal to the column DD, and a tag equal to the tag corresponding to the data which should be in the cell. (Step 1420).

Figure 15 is a flow chart of a function to delete the contents of a cell in a virtual table. The function receives as input a table name, column name, and row key identifier. (Step 1500). If necessary, the DD for the specified table and specified columns are retrieved and, if an improper reference is made an appropriate return code issued. (Steps 1504-1512). The corresponding row in the master maps table having an DD equal to the row key, a TDD equal to the table DD and a CDD equal to the column DD is identified and deleted from the master maps table 30. (Step 1514).

Similarly, figure 16 is a flow chart illustrating the deletion of a row in a virtual table. The system receives as input a table name and the key identifying the row in the virtual table to be deleted. (Step 1600). The identity for the specified table is retrieved and, if an improper reference is made, an error code returned to the calling program. (Step 1602-1606). Each row in the master maps table having an DD equal to the row key and a TDD equal to the identified table name is then identified and subsequently removed from the master maps table. (Step 1608).

Figure 17 is a flow chart illustrating one method of deleting a column in a virtual table. The system receives a table name and column name identifier as inputs and subsequently retrieves the corresponding table and column DDs, for example, by using the GetTableDD function of Fig. 11 and GetColumnDD function of Fig. 12. Error return codes can be returned in the case of an improper table or column reference. (Steps 1700-1712). Next, the row in the master maps table 30 which defines a column, e.g., the row having an DD equal to the column DD and a TDD=2 is a identified and deleted. (Step 1714). Then, each row in the master maps table which references the column for the specified table is also deleted. (Step 1716). Finally, the association between the identified table and the deleted column is removed from the association table 32. (Step 1718).

Figure 18 is a flow chart of a method for deleting a virtual table. The system receives the table name as input and determines the corresponding DD for that table, returning an invalid table error in the case of an improper reference. (Steps 1800-1806). All rows in the master maps table having a TDD equal to the table DD are identified and deleted. Next, all column associations to the specified table are deleted from the association table 32. Finally, the row in the master maps table which defines the virtual table, i.e., the row having an DD equal to the table DD is deleted. (Steps 1810, 1812).

As will be appreciated, this set of functionality provides the tools which are required for an application program to create, manipulate and utilize a virtual database system which is based on a fixed table structure containing only three predefined tables. More complex functionality can be provided by building upon this set of basic database functions. For example, an SQL query engine can be specified which will receive database queries from an application program and issue the appropriate low level database commands to the virtual database system. As a result, for all intents and purposes, the virtual database system will appear to an external application as if it is an entire database system and the application program can operate without knowledge of the fact that a fixed structure database 16 is at the core of the virtual database system 10.

In addition to storing table data, many application also have additional data which must be maintained and which is used to configure and operate the application. Such data includes parameters which define various initialization options and operating states, the location of files, security permission data, flags to enable or disable program features, user specified configurations, etc. When an application is used by multiple groups and users, it will also often be necessary to customize the application's appearance and functionality according to specified preferences, needs, and authorities for various groups and users.

According to a further aspect of the invention, a hierarchical application parameter repository is provided which is configured to efficiently store parameter values for multiple applications and also provide automatically hierarchical specifications of parameter values. Advantageously, the hierarchical parameter repository is linked to the virtual database system and at least some of the tables used by the repository system are implemented as virtual tables. As a result, the repository can be implemented using only a small number of "real" tables in the fixed database system 16 while additional virtual tables are implemented as needed.

Fig. 19 is a tree diagram of an application and user hierarchy 1900. In general, a typical computing environment has a plurality of applications 1902.1-1902. n. Each application can be used by a number of specified users 1906.1-1906.m. The users are generally organized into groups, such as departments and divisions. While multiple groups may use a common application, various aspects of the application will often need to be customized for each group. Similarly, users are generally permitted to customize particular aspects of an application, such as its appearance and whether certain features are automatically enabled or must be manually started.

An application that is written to be used in this type of environment will conventionally include various parameters that can be assigned values to define how the application is customized. (In the present discussion, parameters are also and interchangeably referred to as "properties"). One technique for defining such values is hierarchical. The property is first assigned a default value at the application level. Each group using the application can then specify a value for the property which will override the application-level value. Similarly, users can be permitted to specify a value which will override higher-level group and application values. This type of hierarchy will be referred to herein as "AGU" (Application, Group, User). The present hierarchical application parameter repository will allow the AGU concept to be easily and essentially transparently implemented in a multi-user application environment.

As discussed more fully below, the AGU parameter repository is preferably configured to efficiently manage parameters which are named in accordance with a common naming convention. There are a variety of naming conventions which are used for internal variables, such as program parameters. Figure 20 is a diagram of a conventional application parameter naming system. An application typically has a number of internal modules and sub-modules. Parameters are generally named using one or more prefix segments which indicate the hierarchical location in the application of the parameter followed by a more generic name. For an application with a single layer of modules, parameters could be represented in the form <applicatiori>.<module>.<name>. Thus, for example, application FOO 2000 contains three modules: Main 2002, System 2004, and Display 2006. A background color parameter used by the display module can then be specified as foo. display. bkg_colof '.

This hierarchical naming system ensures that parameters are uniquely named across the various program modules while still permitting the use of commonly used names. However, it also introduces a very large degree of repetition in the parameter names. For example, the parameters associated with the display module all have the prefix "foo. display". This makes storage of the full parameter names unwieldy. Advantageously, the preferred implementation of the hierarchical parameter repository according to this aspect of the invention implements an efficient method for storing and referencing parameter names.

Fig. 21 is a diagram illustrating the real and virtual tables used in a preferred implementation of the hierarchical application parameter repository aspect of the invention. The application hierarchy shown in Fig. 19 is represented by the Application User Map table 2100 which provides a unique reference number for each node in the hierarchical tree. This reference number is referred to herein as the "AGU" number. Each defined parameter or property has a unique property DD (PDD). The Property Values table 2110 stores the value assigned to each parameter or property and different values can be assigned to the same property for different AGU numbers. This permits a parameter to be assigned, for example, a default value for the application which can be overridden by a value defined at the group level (and further overridden by a user-defined value). The Config Map table 2120 is used to implement a hierarchical parameter naming system, such as shown in Fig. 20, and provide a PDD value for each parameter. These tables, and the additional tables shown in Fig. 21 will now be discussed in more detail.

The application user map table 2100 is configured to have a uniquely numbered row (identified by the AGU number) that corresponds to each node in the application hierarchy. Each separate application, user, group, or other hierarchical set, is given a respective DD. For example, the hierarchy shown in Fig. 19 contains application with DDs 101 and 102, groups having DDs 201, 202, and users with DDs 300-302. A column in the table 2100 is provided for each level in the hierarchy and is used to store a respective DD for a node at that level.

In the three-level AGU hierarchy of the example, three columns are provided - an ADD column 2104 for storing an application DD, a GDD column 2106 for storing a group DD, and a UDD column 2106 for storing a user DD. Hierarchies with additional levels of definition would have a corresponding greater number of hierarchy columns. A specific node in the application hierarchy is represented in a row of the application user map 2100. The row indicates the respective DD values of the various nodes on the path from the application node to the specific node at issue. If the node is an "internal node" (and has descendant nodes), the DD values in the columns for lower levels in the hierarchy can be assigned a null, zero, or other value indicating the intermediate node status.

Although the actual names of the applications, groups, and users can be reflected in the table (e.g., "FOO", "Development", "John Smith"), preferably numeric identifiers are used which are cross-referenced to one or more corresponding reference tables 2140. Although these tables can be implemented in the fixed database system 16, preferably they are implemented as virtual tables in the virtual table system and, most preferably, each level in the hierarchy has an associated cross-reference table as shown. Various cross-referencing techniques can be used.

The Config Map table 2120 provides an efficient, mechanism for mapping a parameter name to a property DD. A parameter name generally comprises one or more segments, such as <application>.<module>.<name>. The relationship between the segments can be represented in a hierarchical tree format, such as in Fig. 20. The config map table 2120 is a preferred manner of representing such a tree. The table 2120 has three columns, a PDD column which contains property DD numbers, an FDD column which references a parent or "father" PID (or is a null or zero value if it is a top-level entry). The third column contains data which indicates the name for respective segments. While the segment names can be represented directly in the config map 2120, preferably the values are represented by suitable tags and a TAGDD table 2130 is provided to cross-reference the tag DD to a segment value. Most preferably, the TAGDD table 2130 is implemented as a virtual table.

By following the chain of FDD to PID links, and combining the segment names, the entire parameter name can be reconstructed and a unique PDD value for that parameter is provided by the PDD for the lowest or leaf node in the chain. For example, the PDD for the parameter ^foo. display. bkg_color'^'' can be determined by first translating the segments into the corresponding tag values, e.g., 50.51.52. These values can then be cross-referenced to the TAGDD column in the config map table 2120. The PED-FDD chain is traversed using conventional techniques to identify the unique path which has these tag values and thereby the unique PDD for that parameter. In this example, the unique property DD value for the parameter "700. display. ,bkg_color" is 20. Similarly the unique PID for the sample parameter "foo.display.resolution" is 21.

In order to retrieve a hierarchical parameter value, a GetY a\ue(parameter) function is implemented which can be called by an application program. The functionality is summarized in the flowchart of Fig. 21. In addition to passing the parameter name, the operation system (or other functionality) also passes information which indicates the various hierarchical details of the environment from which the call was made, e.g., the application name, the group, and the user. (Step 2200) Upon receiving a call, the PDD of the parameter is determined. (Step 2022) In addition, the passed hierarchical names are also translated into corresponding DD numbers, such as an ADD, GDD, and UDD, by cross-referencing appropriate tables, such as virtual reference tables 2140. (Step 2204)

After the translation is complete, the value of the parameter is hierarchically determined by retrieving the defined value for the parameter for the AGU hierarchy in a top- down sequence and replacing a higher-level value with a lower-level value, until the AGU hierarchy has been traversed. The final value is then returned to a caller. More specifically, starting at the top level of the hierarchy (step 2206), the AGU number for each hierarchical level in the hierarchical details passed to the GetValue function is determined and the value of the parameter for that AGU number is determined. (Step 2208) . If a parameter value is defined at that level (step 2210), the current value of the parameter is set to the retrieved value (step 2212). If there are additional levels in the hierarchy (step 2214), the process continues at the next level of the hierarchy. (Step 2216). After all specified levels in the hierarchy have been examined, the final current value of the parameter is returned. (Step 2218).

For example, if the GetValue function is passed hierarchical details that translated to ADD=101, GDD=102, UDD=300, the AGU for the highest level of the hierarchy (ADD-101, GDD=null, UDD=null) is determined and the corresponding property value is determined. Here the value for AGU=1, PID=20 is "red" and thus the current return value is initially set to "red".

Traversing the AGU hierarchy, the AGU for the next hierarchical level (ADD=101, GDD=102, UDD=null) is determined and the property values table 2110 is accessed to determine if a parameter value has been defined at that level. In the example, AGU=2, PID=20 is defined with a value of "blue" and this value is used to replace the current return value. The process continues to the lowest level of the hierarchy which provides a parameter value of "green". If a parameter is not defined at a given hierarchical level, the existing return value is retained. The process continues until the entire hierarchy has been traversed after which the final value ("green" in the example) is passed back to the calling program.

A similar function SeWa\ue(parameter, value) can be defined. A high-level flowchart of this function is shown in Fig. 23. When this function is called, the calling program passes the parameter name and value to set as well as data indicating the hierarchical position the value is to be defined (e.g., application and group names for a parameter defined at the group level). (Step 2300). The parameter is translated to determine the corresponding PDD. (Step 2302). If no PDD is defined (Step 2304) , the config map table 2120 and tagid virtual table 2130 can be updated as needed to define the new parameter (Step 2306). The hierarchical data is also translated to determine the corresponding DDs at the hierarchical definition level and thereby the AGU number. (Step 2308) If the parameter is aheady defined at that level in the property values table 2110 (step 2310), the prior value is replaced (step 2314). Otherwise, a new row is added to the property values table 2120 containing the appropriate AGU and PDD numbers (step 2312) and the new property value added to that row.

An addition to the tables illustrated in Fig. 12, an additional "Property Perms" table 2170 (not shown in Fig. 21) can be provided to indicate which parameters are read-write, read-only, etc. Restrictions can be defined hierarchically such that, for example, a parameter is read-write at the group level, but not at the user-level. When the SetValue function is called, the property perms table 2170 can first be accessed to determine if there are any restrictions on setting the specified parameter.

In addition to providing a hierarchical parameter repository, the present system can also provide a set of virtual tables for use by the applications themselves to store whatever data is appropriate, such as startup or initialization data. An AGU Table Map 2150 (fig. 21) provides a cross-reference between AGU numbers and an DD in the master maps table 30. As discussed above, the master maps DD can be used to reference a virtual table, a column, or a row within a virtual table. In a particular embodiment, each application can have a corresponding virtual table 2160 and the AGU table map 2150 associates the DD of the corresponding table with the application-level AGU value. Group and user-level AGU values can then be used to reference particular columns or rows within the application table.

In the example shown in Fig. 21, the application level AGU DD for application 101 is 1 and this is linked to virtual table DD 30. User 302 of application 101 in group 201 has an AGU of 6 and this is linked by the AGU table map 2150 to DD 50, which is a row in table 2160. Other variations are also possible. Any type of information can be stored in the tables and rows and this mechanism provides an efficient way to dedicate virtual table storage space to application, groups, users, etc. for use as needed. Fig. 24 is a high-level diagram of the fixed table set for implementing the virtual table system and the hierarchical application parameter repository according to a preferred embodiment of the invention. As illustrated, the complete virtual database system and a linked hierarchical application parameter repository can be implemented using only a small number of simple relational tables with a fixed structure. (Multiple master tag files defined for specific data types are not shown for clarity). New tables can be added to the virtual table system without changing the structure of the underlying tables shown. The application parameter repository provides automatic hierarchical parameter valuation according to a defined application-group— user hierarchy. By linking the repository the virtual table system, the number of tables which are implemented in the fixed database core is minimized and applications, groups, users, etc. can easily be linked to specific virtual tables or portions thereof according to their position in the application hierarchy.

The invention, in its various aspects, can be implemented utilizing various conventional database systems and operated on a wide variety of different computing platforms including conventional stand-along and networked database environment and other types of computing systems, including so-called "smart appliances", personal digital assistants, and other electronic devices which need to store data in a flexible manner. The methodology of the invention will typically be encompassed by a collection of database table definitions which implement the fixed database structures in the core database or software code to create these database structures. The various functional elements discussed with respect to Fig. 7 and elsewhere can be implemented using conventional programming languages and techniques which will be known to those of skill in the art. The resulting computer software can reside in RAM, ROM, or on a computer program product, such as a magnetic or optical disk. While the invention has been particularly shown and described with reference to preferred embodiments thereof, various changes in the form and details can be made without departing from the spirit and scope of the invention. In particular, while the invention has been largely discussed in terms of a relational database system, other types of database technologies can be used. Similarly, the particular arrangement of tables used to support the virtual database and parameter repository can be modified. For example, the various tag and name-value cross-references tables can be combined in various ways and could be implemented entirely within the fixed database core, entirely as virtual tables, or various combination of real and virtual tables. In addition, the contents of the application user map could be divided into various portions, such as separate tables to represent the table set, the column set and the various row populating elements. Other variations are also possible.

Claims

CLAIMS:

1. A method for providing a virtual database system, the method comprising the steps of: defining in a fixed database system, a table set, a column set, and an association set; and defining at least one virtual table; wherein the association set specifies an association between at least one column identified in the column set and at least one table identified in the table set.

2. The method of claim 1 further comprising the steps of: defining in the fixed database system, an object set; and populating at least one virtual table with data identified in the object set.

3. The method of claim 2 further comprising the steps of: defining in the fixed database system, a tags set; and populating at least one virtual table with data identified in the tags set; wherein the tags set contains each unique data instance, and the table set, column set, and object set each contain at least one pointer to at least one entry in the tags set.

4. A method for providing a virtual database system as disclosed and described herein.

5. A virtual database system as disclosed and described herein

6. An application parameter hierarchy implemented using a virtual database system as disclosed and described herein

7. A method for providing hierarchical application parameters via a virtual database environment as disclosed and described herein.