WO2003030020A2

WO2003030020A2 - Handling relational metanodes in databases

Info

Publication number: WO2003030020A2
Application number: PCT/DK2002/000638
Authority: WO
Inventors: Niels Morville
Original assignee: Treewise Aps
Priority date: 2001-10-02
Filing date: 2002-09-26
Publication date: 2003-04-10
Also published as: WO2003030020A3

Abstract

A method for handling a large part of all database data access, monitoring and maintenance in an abject oriented multi-tier application, by using structural metadata. A 'relational metanode' is defined as a means for identifying business objects in a database. Structural and other metadata is used to construct prototype class instances called 'managers', that operate on metanode data instances called 'units'. Managers provide access to the unit's data, transactional control, access to referenced data and managers of referenced metanodes. Managers provide metadata on the compositeness of their nature facilitating tool building and frameworks. Remote interfaces to managers are made available enabling multi-tier applications. Client application frameworks can be built using client foundation classes interacting with arbitrary managers.

Description

Handling relational metanodes in databases

This invention relates to the field of computer software and, more specifically, to multi-tier software applications. Even more specifically, the invention relates to operating on database data.

Computer systems comprising a software application and a database have to manage at least two data formats: One is the format defined in the database, the other is the format used to hold data inside the software application during execution. These formats should match each other for the system to function properly. In most cases, however, the two formats are defined separately; one is defined in the computer language of the database, while the other is defined in the computer language of the software application. In many cases these two languages are not the same. This "format matching" does not only apply to "granular" data such as text, integers, floating point numbers, money amounts, etc. It also applies to composite data such as records, e.g. data about an employee, data about a product, etc. Hence, there needs to be agreement between the application and the database about how such a record is composed. More complex compositions of data like an invoice or an organisational chart needs similar agreement including how elements interrelate.

In recent years a computer system architecture called multi-tier architecture has become increasingly popular. In a multi-tier system architecture, a software application is split up in two or more parts, typically including a server-part and a client-part which communicate with each other, for example by a request/response mechanism where the client sends a request to the server which returns a corresponding response. Here again, matching formats must be ensured between the different parts of the software application.

During the life cycle of a multi-tier system, the programming team may manually ensure that formats match, for example between database, server application software and client application software. However, this is a cumbersome and error prone process, especially with regard to implementing changes in the design of the data model of the system. A related problem is caused by the fundamentally different ways of holding data in two of the most successful technologies of resent years, namely relational database management systems and object oriented programming. In a relational database, data is stored as records in tables where the tables are interrelated via references between them. In an object-oriented approach, data is managed as objects, comprising attributes and functions, which provide an interface to the attributes of an object. The objects are instances of predefined classes defining the types of attributes and the functions or methods of the corresponding objects. When data needs to be loaded from the relational format and represented in the object-oriented format, or extracted from the object-oriented format and saved in the relational format, one faces a process, where data is extracted often in their most granular format in the language of the model one extracts from, momentarily held in an intermediate format, and then transferred to the recipient model using the language of that model. This task may be compared to parking a car in a parking lot by disassembling the car into its parts and storing the individual parts in the parking lot. In this analogy, when the car is checked out again, the individual parts are checked out and, subsequently, the car is reassembled from its parts. Consequently, a manual programming of the functions for loading data from a relational database into an object-oriented format is a very labour intensive process, thereby increasing the production cost of a multi-tier system, making it difficult to maintain and update, and increasing the likelihood of errors, potentially causing erroneous results and/or an increased downtime of the system.

The above problem has been partially addressed by introducing object- oriented databases, where transforming objects to and from their persistent form is dealt with. However, existing object-oriented databases have the disadvantage that they do not scale well, thereby causing problems, particularly in connection with large databases. Furthermore, a transition from a relational database to an object-oriented database requires transferring the existing data models and large amounts of data.

Consequently, there is a need for methods that bridge the worlds of the relational model, which defines persistent data and its relations and the object-oriented model which defines objects as data and functions operating on them. These methods should overcome the need for multiple definitions of the same persistent data, i.e. data that persist in the database between invocations of an application.

US patent no. 6,085,198 discloses an integrated three-tier application framework, where schemas of metadata provide a description of the data classes associated with the system. A schema describes the elements of each data class, such as attribute names, method names, etc. The schema is utilised during the design of the system in order to automate a part of the design process, namely the production of class definitions in the client and server tiers in order to reduce redundant programming. The schema data is further utilised to create database tables by extracting the attribute names and data types for persistent data and generate corresponding "create table" commands.

However, it is a problem of the above prior art method that, when the underlying data model changes, class definitions have to be regenerated based upon updated schema data, thereby increasing the maintenance cost of the application.

US patent no. 5,937,409 discloses an interface for accessing data in a relational database from an object-oriented environment where a relational mapper assigns a table in the database for each class type supported by the database. Furthermore, the relational mapper generates a mapping between objects and columns of a table for the corresponding class type. However, it is a problem of the above prior art method, that a change in the data model requires a re-definition of class-types and, thus a re-compilation of the application, thereby increasing the maintenance cost of the application.

Hence, it is a problem of the above prior art methods that they require that persistent data model classes and interfaces are regenerated when a change in the underlying data model occurs. For any non-trivial application system such changes occur throughout the life cycle of the system. It is a further problem of the above prior art methods that the classes generated by them have inherent drawbacks: 1) Handling them increases development cost.

2) They add complexity, which increases error potential.

3) They increase runtime memory consumption. 4) They increase program load time.

According to the invention the above and other problems are solved by a computer-implemented method of operating on data in a database, the method comprising the steps of - obtaining structural data defining at least a first structural element, the first structural element including a first data entity including one of a) a database table with a primary key and b) a second structural element, the first structural element further including a number of referencing data entities, each including one of a) a database table with a foreign key referencing the first data entity and b) a third structural element including a second data entity with a foreign key referencing the first data entity; - obtaining database metadata about said database tables, primary and foreign keys; - constructing at least a first class instance adapted to provide access to data records of database tables of said first structural element via a set of functions.

Hence, according to the invention, a definition of the persistent data is provided which describes a plurality of structural elements of a predetermined type together with a set of universal functions pertaining to the persistent representation of all data entities of that predetermined type. Consequently, when the data model changes, different composite entities may be described in the metadata as different instances of the predetermined type of structural elements, thereby allowing the reuse of previously defined functions for accessing this general type of structural elements. Therefore, according to the invention, a change in the data model does not require a re-generation of access functions and subsequent re- compilation of program code, thereby greatly reducing the time and resources necessary for developing and maintaining a multi-tier application. Furthermore, the likelihood of introducing errors in the application is reduced, and a common software component for interfacing between an object- oriented application and a relational database is provided, thereby reducing necessary memory requirements of an application.

According to an embodiment of the invention, the structural data defining structural elements describe the layout of the persistent parts of business objects in a database. The term business objects refers to any real world object pertaining to the subject area of the application where data about the business object is stored in the database, possibly distributed in a number of database tables. Examples of business objects include "employee" in a human resource database, "product" in a product database, "production process" in a production control system, "train" in a train traffic management system, etc. According to the invention, software objects are constructed as instances of classes of an object-oriented framework by a computer implemented method based on these metadata. In the following, these class instances will also be referred to as managers.

Consequently, a general type of structural elements is provided enabling the representation of even very complex business objects, and providing a corresponding single set of access functions for accessing a wide variety of complex business objects. The invention builds on the recognition that even very complex data structures as found in a relational database, can be described in very simple terms as a general type of structural elements. In the following, these structural elements will also be referred to as relational metanodes, or just metanodes. Once these metanodes have been defined, managers are constructed according to an embodiment of the invention, where the managers include functions for operating on instances of a metanodes's data. Managers thus automate the process of reading updating, deleting and inserting instances of the data of a metanode. Consequently, the trivia of maintaining the persistent parts of business objects in the database is taken care of. Transactional contrql is also provided in which managers may update the persistent parts of their business objects stand- alone or as part of larger transactions. Consequently, it is an advantage of the invention that a development process is achieved where large parts of all database data access and maintenance software are pre-implemented in all tiers of a multi-tier application framework.

The term obtaining data comprises loading data from a storage medium or other data source e.g. from a communications network such as a local area network, a wide area network, the Internet, or the like.

According to a preferred embodiment of the invention, the method further comprises the step of providing at least one memory space for sharing data about the first structural element among a plurality of constructed class instances. Consequently, data caches are provided which are generated based on the metadata and which are used by managers and other objects for sharing and monitoring loaded data. This further reduces memory consumption and facilitates what is generally known in the industry as transaction monitoring. After successful completion of a transaction, managers may notify other objects of changes made through the caches. Managers may be monitored for observing changes to the persistent data.

Business objects often reference other business objects, for example an invoice may have a reference to a customer. According to a preferred embodiment of the invention, a selected one of the database table of the first data entity and the second structural element further comprises a number of references to other structural elements. Consequently, managers also provide access to other managers of related metanodes. Hence, it is an advantage of the invention that managers provide access to referenced managers and their data. Alternatively or additionally, a selected one of the database table of one of the referencing data entities and the third structural element further comprises a number of references to other structural elements.

According to another preferred embodiment of the invention, the constructed first class instance further comprises at least one function for providing information about said first class instance. Hence, it is an advantage that managers further provide information on how they are put together and what types of data they hold. These functions will be referred to as introspection functions. According to a further preferred embodiment of the invention the method further comprises the step of constructing at least a second class instance adapted to provide to another remote computer process access to the set of functions of the first class instance. Consequently, a further class instance provides access to the functions of the first class instance from another remote computer program or process, thereby enabling multi-tier applications. One embodiment of this invention provides access to managers to users and processes on other tiers in a multi-tier environment, for example via a communications network, such as a local area network, a wide area network, the Internet, or the like.

The invention further relates to a computer-implemented method of accessing a first class instance constructed according to the above described method, the method comprising the steps of

- constructing at least a third class instance with a set of functions for accessing said first class instance;

- obtaining information about said first class instance via at least one function of said first class instance for providing information about said first class instance.

Hence, according to the invention, general classes are provided for accessing the first class instance utilizing the introspection functions by communicating with the first class instance directly or via a second class instance, to facilitate communication with any particular manager. Building on these general classes enables the building of (sub-) frameworks, for example client frameworks for accessing and manipulating data. Whatever services the (sub-) framework may offer it may do so parameterised with any given metanode or metanodes. Such (sub-) frameworks have parts of its application logic generic, i.e. it can do it on any (subset of) managers, e.g. obtain the number of columns the manager has in its first data entity, and there will typically also be manager specific logic, e.g. some display component. The manager specific component may be compiled or linked to the (sub-) framework making a "normal" application, or be dynamically loaded from the (sub-) framework taking the name of the manager specific logic as a parameter to application invocation. The invention further relates to a server computer comprising

- means for accessing a database for storing a plurality of data records in a plurality of database tables;

- processing means adapted to execute a server application program for accessing selected ones of said data records;

- means for obtaining structural data defining at least a first structural element, the first structural element including a first data entity including one of a) a database table with a primary key and b) a second structural element, the first structural element further including a number of referencing data entities, each including one of a) a database table with a foreign key referencing the first data entity and b) a third structural element including a second data entity with a foreign key referencing the first data entity;

- means for obtaining database metadata about said database tables, primary and foreign keys; the processing means being adapted to, under the control of the server application program, construct at least a first class instance adapted to provide access to data records of database tables of said first structural element via a set of functions.

Similarly, the invention relates to a data processing system comprising means for performing the steps of the above method of accessing a firsts class instance.

The invention further relates to a computer program comprising program code adapted to perform, when run on a data processing system, the method described above and in the following.

The computer program may be embodied as a communications signal in a communications network, such as an intranet, extranet, internet, a local area network, a wireless or wired network, etc. The computer program may further be stored on a computer-readable medium. The term computer-readable medium may include magnetic tape, optical disc, digital video disk (DVD), compact disc (CD or CD-ROM), mini- disc, hard disk, floppy disk, ferro-electric memory, electrically erasable programmable read only memory (EEPROM), flash memory, EPROM, read only memory (ROM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), ferromagnetic memory, optical storage, charge coupled devices, smart cards, PCMCIA card, etc.

The invention will be explained more fully below in connection with a preferred embodiment and with reference to the drawing, in which:

Fig. 1 is a general block diagram of a 3-tier system.

Fig. 2 is an illustration of how metanodes are composed.

Fig. 3 is a block diagram of a three-tier application framework in accordance with one embodiment of the invention.

Fig. 4 is a block diagram, which details parts of fig. 3.

Fig. 5 is a flow diagram of a process for constructing manager instances in accordance with one embodiment of the invention.

Figure 6 shows a block diagram of the database table types and the operations of the main program on them in accordance with one embodiment of the invention.

In the following, the invention will be described in the context of a multi-tier application framework. In the following description, numerous specific details are set forth to provide a more thorough description of embodiments of the invention. It will be apparent, however, to one skilled in the art, that the invention may be practiced without these specific details. In other instances, well known features have not been described in detail so as not to obscure the invention.

A description is given below of an embodiment of a three-tier application architecture including computer apparatus suitable for providing an execution environment for the software apparatus of the invention. Three-tier application architecture:

Fig.1 gives an overview of a three-tier architecture. Client tier 108 consists of computer systems that provide a user interface, often graphic (GUI), generated by client 107, such as a browser or other user interface application. The computer systems of the client tier are often desktop computers like a PC, but may as well be special purpose browsers, other visual display units, adapted telephones or other multipurpose devices, such as PDAs, handheld computers, etc. Client 107 provides the user interface and, in some embodiments of the invention, may include further application logic.

Application tier 105 with application server 104 manages further application logic. The distribution of application logic between server and client tier depends in part on the type of application and in part on the choice of design. The application can be of any type; e.g. financial, scheduling, personnel, project management, process control, scientific, etc. The computer system running application server 104 may be a general-purpose computer with a general purpose operating system varying in size from an average PC to large multi-CPU (Central Processing Unit) computers. Database tier 102 holds the database(s) accessed by application server 104. Database server 101 manages the database, its definition, rules for data relations and the operations that may be performed on it. The computer systems running database server 101 may be similar to the one running application server 104. Connection 106 is used to communicate between client tier 108 and application tier 105. This may be any type of connection, e.g. a direct connection, a LAN (Local Area Network), a WAN (Wide Area Network) such as the Internet. Through connection 106 application specific data and logic is communicated, as well as general or application specific methods are invoked. Connection 103 is used to communicate between application tier 105 and database tier 102. This may again be any type of connection. Through connection 103 application server 104 reads and maintains the application specific persistent data in database server 101. Application server 104 and database server 101 may run within the same computer, as may client 107. Application server 104 may also provide connections to other application servers, which in turn may provide connections to clients. Thus the term multi-tier is often used instead of three- tier.

General Software Apparatus: An embodiment of this invention includes a software apparatus that can support a multi-tier architecture and will thus have a number of components enabling an application server to communicate with a database server, enabling a client to communicate with an application server and enabling a client to interface with a user. And that is just mentioning a few. All these components may be implemented as instances of object classes in accordance with known object oriented programming practices - other implementations are possible. In one embodiment of the invention such a general software apparatus from Sun Microsystems, Inc. based on the programming language Java™ is used. The general software apparatus from Sun Microsystems includes, among other things, packages like JDBC (Java database connectivity) enabling access to databases and RMI (Remote Method invocator) enabling communication between client and server. Other embodiments may use different packages that may use different programming languages or the same package using alternative techniques. Other examples of object-oriented programming languages include the C++ programming language, Delphi, Smalltalk, etc.

Object-Oriented Programming:

Within object-oriented programming an object is a programming unit that comprises a data structure, i.e. one or more instance variables, and the operations, functions or methods that can use or affect that data. Thus, an object consists of data and one or more functions that can be performed on that data. This joining of data and functions into a unitary building block is known as "encapsulation." An object may be adapted to perform one of its methods upon receipt of a "message." Here, the term message refers to a command or instruction sent to the object causing it to execute a certain one of its methods. A message comprises of a method identifier, e.g. a method name, and, optionally, one or more arguments. Object-oriented programming languages are predominantly based on a "class" scheme. The class-based object-oriented programming scheme is generally described in Lieberman, "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems," OOPSLA 86 Proceedings, September 1986, pp. 214-223.

A class defines a type of object comprising specifications of variables and/or methods for that class. An object class is used to create a particular instance of an object including the variables and methods defined for the class. Multiple instances of the same class can be created from an object class. Each instance that is created from the object class is said to be of the same type or class. For example, an employee object class can include "name" and "salary" instance variables and a "set-salary" method. Instances of the employee object class can be created, or instantiated for each employee in an organization. Each object instance is said to be of type "employee." Each employee object instance includes "name" and "salary" instance variables and the "set-salary" method. The values associated with the "name" and "salary" variables in each employee object instance contain the name and salary of an employee in the organization. A message can be sent to an employee's employee object instance to invoke the "set-salary" method to modify the employee's salary (i.e., the value associated with the "salary" variable in the employee's employee object).

A hierarchy of classes can be defined such that an object class definition has one or more subclasses. A subclass inherits its parent's (and grandparent's etc.) definition. The parent class is also referred to as a "superclass." Each subclass in the hierarchy may add to or modify the behaviour specified by its parent class. The Java programming language also provides a mechanism known as an "interface" which comprises a set of constant and abstract method declarations. An object class can implement the abstract methods defined in an interface. An object is a generic term that is used in the object-oriented programming environment to refer to a module that contains related code and variables. A software application can be written using an object-oriented programming language whereby the program's functionality is implemented using objects

General database apparatus: An embodiment of this invention uses a database. To describe the invention it is necessary to first introduce some common concepts about databases. The concepts are primarily found in relational databases (including what is called object relational databases) but they also apply to some extent to other types of databases. A description of these concepts may, for example, be found in Microsoft SQL Server 7.0 Books Online. - Tables are database objects that contain all the data in a database. A table definition is a collection of columns. In tables, data is organized in a row-and-column format similar to a spreadsheet. Each row represents a unique record, and each column represents a field within the record. For example, a table containing employee data for a company can contain a row for each employee and columns representing employee details such as employee number, name, address, job title, and home phone number.

- Column: In a database table, the area, sometimes called a field, in each row that stores the data about an attribute of the object modelled by the table. Their maximum length and the type of data that can be placed in them characterize individual columns. A column contains an individual data item within a row.

- Primary key: The column or combination of columns that uniquely identifies one row from any other row in a table.

- Foreign key: The column or combination of columns whose values match the primary key in the same or another table. A foreign key does not have to be unique. A foreign key is often in a many-to-one relationship with a primary key

- Metadata: The data about definitions of tables, columns, primary keys, foreign keys (and more) are often called metadata and can usually be read from the database that holds them. The availability of database metadata enables building tools.

Database foundation classes:

One embodiment of this invention includes a number of classes that encapsulates the more fundamental aspects of a database. The following list briefly describes examples of some of the more basic classes of one embodiment of the invention:

The names of the classes above merely serve as examples and will be used in the following in describing an embodiment of the invention. Instances of classes like Column, Key and Tabular may be constructed with values taken from database metadata. Instances of classes like Values and Record may be constructed from "regular" database data (and database metadata) using known object-oriented mechanisms.

Relational metanodes: At the core of this invention is an addition of a new conceptual layer to a database. Metanodes are used to define composite units in the database.

Fig. 2 is an illustration of a metanode and its possible sub-components according to an embodiment of the invention:

Definition: A metanode 200 is a "primary" 201 and zero or more "referencing sets" 202.

Definition: A primary 201 is either (201 A) a database table 203 with a primary key and zero or more "referenced metanodes" 204, or (201 B) a metanode

205. Definition: A referencing set 202 is either (202A) a database table 206 with a foreign key (referencing the primary) and zero or more referenced metanodes 207, or (202B) a metanode 208 of which the primary has a foreign key to the primary of the metanode 200. Definition: A referenced metanode (subcomponents of 204 and 207) pertains to a database table, and is a foreign key to the primary of a metanode.

In the following, the term unit is used to denote a metanode instance, i.e. an instance of the data defined by a metanode. A unit is to a metanode what a row is to a table. Instead of referring to the primary of a metanode, the short form main is used in the follwoing, e.g. a main table is short for a metanode's primary's table.

Example 1 - an employee metanode: The simplest of metanodes are those, that are tables and their units are rows. Data about an employee could be such a metanode, but say we augment employee data with addresses, i.e. an employee may have a set of addresses. The employee metanode now also has a referencing set.

Example 2 - an invoice metanode: The primary of the invoice is the invoice- header table; that has a reference to another metanode: a customer (it may also reference an employee metanode: the sales person); and it has a referencing set: the invoice lines. The invoice lines reference the invoice- header and another metanode: a sales good through a goods-number.

Example 3 - a product group metanode: The primary of a product group is a table, which among other data contains a product-group-id and a parent- group-id. There are two referencing sets.

1 ) A product metanode having a primary which references the product- group-id to which the product belongs, and

2) the product group metanode itself referencing the product-group-id from the parent-group-id (i.e. containing the sub-groups of the group).

Example 3 illustrates that hierarchies are special cases of metanodes or, more strictly, some metanodes contain collections of graphs and a graph may be a hierarchy. An advantage of working with metanodes rather than tables or schema information is that it enables operations on "real" objects rather than their sub-components. It also captures how they are interrelated through foreign keys, thus facilitating services on a higher level than table level; e.g. given an organisational unit one may query a metanode for the employee unit that it references through its manager-field foreign key. It is a further advantage of the invention that all business objects with a reasonable representation in a relational database may be described as metanodes.

Definition: A metanode definition is data about a metanode identifying the metanode and its constituent parts. In this document, a metanode definition is said to contain metanode metadata. A metanode definition may include additional data beyond the "pure" structural data, e.g. about the referencing sets, whether the relations are one-to-one or one-to many, or e.g. about a reference, whether it "extends" the data (for object oriented inheritance) or is a "plain" reference. It should be noted, that in this document, the term structural metadata is not exclusively associated with database metadata such as keys, relations or table definitions, but also comprises metanode definitions.

It should further be noted that the notion of metanodes is different from both the notion of relations and the notion of entity in an entity/relation (E/R) model. In contrast to relations metanodes include hierarchies and other possible circular references, thereby going beyond a simple relational model. Furthermore, metanodes differ from entities in an E/R model: Entities do not have referencing sets. A metanode may, however, be thought of as a sort of super entity sharing some concepts with entities, such as being "weak" (i.e. existence dependent of some other entity) or "regular" (i.e. independent). It should be noted that metanodes build on the relational model; they do not build on an E/R model which is primarily used in the design phase of a development process. In the above definition of a metanode the term "database table" is used mainly for readability; in context ©₄f the relational model it might be more stringent to use the term "the schema of a (base) relation". In one embodiment of this invention metanode definitions are saved in tables within a database. But it could just as well be in a file in a file system. The format of a metanode definition may vary depending on the chosen storage type. An illustrative and simple example of a format for definition of a metanode in a textual format is the following DTD (Document Type Definition) in XML (extensible Mark-up Language) with an example of an invoice metanode.

<?xml version- ' 1.0"?> <!DOCTYPE Metanode [

<! ELEMENT Metanode (Primary, RefSet*)> <!ATTLIST Metanode name PCDATA #REQUIRED> <! ELEMENT Primary (NodeName | TableRef)> <! ELEMENT RefSet (RefNode | RefTable)> <!ATTLIST RefSet name PCDATA #REQUIRED>

<! ELEMENT TableRef (TableName, RefNode^*)> <! ELEMENT RefNode (FKName, NodeName)> <!ATTLIST RefNode name PCDATA #REQUIRED> <!ELEMENT RefTable (TableName, FKName, RefNode^*)>

<!ELEMENT NodeName, TableName, FKName (#PCDATA)>

]>

<TableRef> <TableName>INVOICE_HEADER</TableName> <RefNode name- 'Customer Ref '> <FKName>FKJNVOICE_HEADER_CUSTOMER</FKName> <NodeName>Customer</NodeName>

</RefNode>

<RefNode name="Sales Ref > <FKName>FK_INVOICE_HEADER_EMPLOYEE</FKName> <NodeName>Employee</NodeName> </RefNode>

</TableRef> </Primary>

</RefSet name="lnvoice lines"> <RefTable> <TableName>INVOICE_LINE</TableName>

<FKName>FK_INVOICE_LINE_INVOICE_HEADER</FKName> <RefNode name="Goods Ref> <FKName>FK_INVOICE_LINE_SALES_GOOD</FKName> <NodeName>SalesGood</NodeName> </RefNode>

</RefTable> </RefSet> </Metanode>

Figure 6 shows a block diagram of the database table types and the operations of the main programs on them in accordance with one embodiment of the invention. Database component 603 holds the various tables, subdivided into three groups:

1) Database metadata tables 604 hold information about tables, columns, relations etc.

2) Production data tables component 606 holds the business data of the subject area of whatever applications use the database.

3) Structural metadata tables component 605 holds metanode definitions.

Database design tool component 601 maintains the database metadata tables component 604 as depicted by connection 608. Application server component 607, explained in more details below, reads data from database metadata tables component 604, as depicted by connection 611 , and reads data from structural metadata tables component 605, as depicted by connection 612. After such reading, application server 607 may read and write to and from the production data tables component 606, as depicted by connection 613. According to one embodiment of the invention a metanode editor component 602 maintains structural metadata tables component 605, as depicted by connection 610, based on reading data from database metadata tables component 604, as depicted by connection 609. Preferably, however, metanode definitions in component 605 should be part of the general database metadata in component 604 and be editable with the same design tool component 601 used for defining other database components. This also allows the tools to present a zoomed out view of the database design on metanode level - thus providing designers with a better overview.

In one embodiment of the invention one program, the metanode editor component 602, allows a user to define, edit and store metanode definitions, while another program, the application server 607, reads the definitions and uses the definitions as described below. This may as well be just one program. Another embodiment of this invention may not include an apparatus for defining or editing or storing metanode definitions. According to an embodiment of this invention, metanode definitions are read in one form or another. This may be supplemented with reading database metadata (about tables, columns, foreign keys etc.) pertaining to the metanode definitions referenced tables, metanodes etc. In one embodiment of this invention, this is read directly from the database's metadata repository, but it could also be part of the data source, that holds the metanode definition, or come from a third source.

Managers: With the definition of a metanode and its underlying metadata (tables, columns etc.) an embodiment of this invention constructs a class instance of a class, which can operate on metanodes. Class instances, which operate on a specific type of metanodes, are called managers. In computer language terms managers can be likened to variables; a manager holds either a new (unsaved) value or an existing (loaded) unit. The abstraction chain of metanode / metanode definition / manager, i.e. conceptual / metadata / variable, is similar to e.g. database table / table metadata / actual table, or e.g. integer / -2147483648 to 2147483647 / integer variable. The preferred method is to make managers as prototype/factory classes, so that a manager can make a copy of itself. Whenever a new manager is needed, one just gets a copy from the original (or from a copy of a copy of the original, and so on). However other methods may be used. The first thing that happens to a manager, besides construction, is that it is associated with a "session" (introduced later), which in turn is associated with database connections, which again is associated with a user.

The main benefits of constructing managers for objects that have a persistent representation in a relational database are as follows:

1) The programming effort for converting objects between their persistent form to and from a format readily accessible within the object oriented world is removed from the development process.

2) The need to write application logic classes (for the application tier) for specific business objects disappears (the manager is the business object) if there is no special handling of the data, e.g. client-side input validation possibly combined with database tier logic is all that is needed. Even if there is a need for application-tier logic only business logic needs to be implemented; data access and persistence handling is pre-implemented.

3) Run-time application-tier business objects can now share a set of common functions by being, extending or mapping functions to that of their manager. I.e. they all conform to one interface pertaining to the data they hold and reference. This has large implications since it enables both server and client side logic to offer services parameterised with managers or manager types.

4) Finally encapsulating relational database persistency related aspects of all these objects reduces the amount of code to a set of core-classes with the potential for a much higher degree of being error free. According to the present invention and in contrast to the prior art methods described above, metadata is used directly, i.e. no generation or compilation steps are required. In outline, the above prior art methods generate source code for handling specific business objects (or rather their sub-components). According to the present invention a class is provided that encapsulates the behaviour of the persistent data of all business objects. Based on metadata, instances of this class are generated that handle the persistent data of specific business objects. In other words, the prior art methods do not achieve benefits 2, 3 and 4. Furthermore, according to the invention, at least two steps are taken out of the development process, thereby making the process simpler, less error prone, and faster. Implementing database design changes becomes even less troublesome. This invention uses only metadata, thus having one, and only one, system-wide definition of persistent data, thereby avoiding potential errors caused by multiple definitions. In terms of developers using an embodiment of the invention, two other aspects are of importance:

According to the present invention a new layer of metadata is added which describe the metanodes of the data model, thereby giving software designers and data model designers an opportunity for increased insight.

Many database designers have their preferred design tool with which they edit the database metadata. However, users of the above-mentioned prior art methods have to extract this data, reformat it and then inco porate it in some schema information. According to the present invention the database metadata is used directly. Having introduced general database concepts, metanodes and briefly touched on managers (elaborated on later) a description of an implementation in a multi-tier framework can be given.

Implementation in a multi-tier framework:

Fig. 3 is a block diagram of an implementation in a three-tier application framework in accordance with an embodiment of the invention. The three-tier application framework comprises one or more clients 312 in the client tier, application server 311 in the application tier and database server 300 in the database tier. As represented by lines 308 clients 312 are coupled to application server 311 to exchange method calls and data. As represented by line 301 , application server 311 is coupled to database server 300 to exchange database calls and data. In some embodiments other application servers may be coupled to application server 311 , they may in turn have their own clients or run processes that require data access.

Within the application server 311 a set of data objects are maintained in data pools 303 for the clients it serves. Application server 311 is responsible for transforming data from the format of database server 300 into the format of the data objects and, similarly, from the form of data objects into the format of database server 300. Additionally, queries are transformed into the particular query format expected by database server 300, such as SQL.

Clients 312 comprise client-side application logic and graphic user interface component 310, client-side session and manager control component 309, and client-side remote communication management component 307B. Application server 311 comprises server-side remote communication management component 307A, client server session components 305, server process 306, server manager factory component 304, server data pools 303 and database connectivity component 302 (e.g. a Java data base connectivity or JDBC TM component).

Client-side components:

Client-side application logic and GUI components 310 provides the software mechanism by which the user is able to view the data and other output associated with a particular application, to generate input in the form of additions deletions and modifications of data, and to otherwise exert control over the data and format of what is displayed. Client-side application logic and GUI components 310 interfaces with client-side session and manager control component 309, and client-side remote communication management component 307B.

Client-side session and manager control component 309 provide the software mechanism for obtaining a session on the server and through the session obtaining access to managers on the server. In one embodiment of the invention it also provides the mechanism for interacting with arbitrary managers by utilizing manager's introspection mechanism; it thus either reads, or reuses already read, metadata about the sort of managers it interacts with in order to provide records and or record sets with the proper data types (and other metadata) for use by client-side application logic and GUI component 310. Other embodiments may have this "hard coded", i.e. part of the client application logic contains this metadata, and accesses server managers directly through client-side remote communication management component 307B. For example: the information, that the 7th column of an employee record is named BIRTH_YEAR and contains an integer, can either be read from the server through an employee manager's introspection function, or it can be part of client application logic. Client application logic may need to have such information for e.g. display purposes, but they will be much more easily maintained, if they only carry such information where absolutely necessary, and limit such knowledge to e.g. an employee has a column named BIRTH_YEAR containing an integer i.e. being flexible as to what position the column has in the record. In other respects, the main function of the client-side session and manager control component 309, is to make it look like client-side application logic and GUI component 310 is interacting directly with the server, i.e. calling manager functions as if it was part of server-side software. This shields the client side developer from the intricacies of communicating via a network. Part of client- side session and manager control component 309 is, that it "observes" its server counter part. This implements the client side aspect of what is generally known as transaction monitoring. Users of a system, which implements transaction monitoring, will have the data displayed on their screen updated, if some other user changes those data. Transaction monitoring is not regarded as new in the context of this invention, see further under server-side components. In one embodiment of the invention, the session is observed for messages to the user and for forced server shutdown, and managers are observed for changes in the data they hold. The client-side application logic and GUI component 310 may in turn elect to observe client-side session and manager control component 309, which will pass on messages of changes. Such messages may originate from other users or processes changing data, or it may originate from a transaction requested by the client itself.

Client-side remote communication management component 307B provides the software mechanism by which objects and method calls are transmitted between the client 312 and application server 311. The objects exchanged can be serialized, that is broken down into a set of data bytes containing the object state, which may later be reconstituted (i.e. "de-serialized") to generate a copy of the original object. As mentioned above in one embodiment of the invention the client-side session and manager control component 309 performs an initial reading of metadata, which means, that after this is performed, the exchanged objects contain little but raw data (basically an array or an array of arrays of database field values).

Serialization provides a useful mechanism for object transmission. A serialized object may be transmitted between remote clients and servers as data streams or packets in accordance with known communication protocols, such as the protocol implemented by the Remote Method Invocator (RMI) API. Also serialized objects may be written to a shared portion of memory by one application and read out of the shared memory by another application. Client-side and server-side remote communication management component 307A and 307B implements methods to perform serialization and de- serialization functions. Data transport, such as the transmission and reception of serialized objects, may be implemented using any known communication protocol.

It is a major benefit of the uniform interface that all managers share, that a general implementation can be made to perform the functions of components

307A, 307B and 309 - to the extend of interaction with managers. Server-side components:

Server-side remote communication management component 307A performs the same general functions for application server 311 as its counterpart component 307B does for client 312, such as serialization, de-serialization and data transport. Method calls and objects received by the server-side remote communication management component 307A from client-side remote communication management component 307B are directed to server- side components 305 or 306 as specified by the call. Method calls or objects destined for the client tier are directed to the client-side remote communication management component 307B.

Server-side server process component 306 receives requests from server- side remote communication management component 307A or from local processes to log on to the system, and, if granted, constructs a server-side client session component 305, which holds one or more database connections, and returns a pointer to the constructed server-side client session component 305. Two server-side client session components 305 are depicted to illustrate that one exists for each client connected, and there may be any number of them. Server-side client session component 305 receives requests from remote communication management component 307A or from local processes to obtain access to managers or other application logic specific components, constructs the component using the server-side object factory component 304, and returns a pointer to it. In one embodiment of this invention all managers and application logic specific components are constructed using factory methods based on a pool of prototype objects found in object factory component 304, shared by all server-side client session components 305 and the server-side server process component 306. The prototype is identified with a name and object factory component 304 returns a copy of it. Other embodiments may do so differently; specifically application logic specific components may implement other strategies, e.g. direct construction without prototypes having factory methods. Server-side data pool component 303 is used by managers and application logic specific components, and described below in connection wjth fig. 4 giving a zoomed in view of the server side client session component 305 and other interacting components. Server side JDBC component 302 provides the conversion between general database calls made by managers and application logic specific components and database-specific commands (e.g. SQL) and communication protocol required by the particular implementation of database server 300 (e.g. Oracle, Sybase, etc.). Connection 301 represents the communication link between JDBC component 302 and database server 300. In some embodiments, other database connectivity components may be used in place of or in addition to JDBC component 309.

Database server 300 may be any form of structured persistent store, which allow metanodes to be meaningfully defined, i.e. directly or indirectly support notions of tables, primary and foreign keys. For example, database server 300 may comprise a flat-file data management system, a relational database management system (RDBMS), an object relational database management system, etc.

Fig. 4 is a block diagram detailing parts of fig. 3. Component 401 corresponds to 302, component 402 corresponds to 303, component 403 corresponds to 305, and component 406 corresponds to 307A. Server-side client session component 403 is shown with three types of subcomponents of each there may be zero or more instances. Manager sub-component 404A is used directly through server-side remote communication management component 406 as shown with connection 410. The connection could as well have been with a server side-process; this is also the case with the other subcomponents of server-side client session component 403.

Manager sub-component 404A and manager sub-component 404B (in the following just called managers for brevity) provide access to units of the metanode upon which definition they were constructed (explained later). One needs to specify what unit it is, by identifying the value or values of the main table's primary key column or columns. When this is done one may read the values of the unit's primary or referencing sets.

In one embodiment of this invention, reading the unit's main record and referencing record sets does this. But it could* as well be more fine-grained, e.g. on field level, or coarser, e.g. in-totality. Thie. same embodiment identifies a specific referencing set by an index or by name (the latter being the preferred method), and it groups together the specification of the unit's primary key with reading the main record, as follows:

The RecordSet returned by a call to the getSubSet function may however be very large. As mentioned above metadata about a metanode may contain other data than the pure structural data. In one embodiment of this invention metadata about referencing sets include a page size; which if set to a value larger than zero enables paged access to the records of the referencing set. When a page size is set the getSubSet function retrieves the first page and functions named getNextPage and getPreviousPage enables paging through the set. There are also functions for getting and setting the page size during run-time. In other embodiments alternative methods for handling large sets may be implemented.

In the same fashion one may get access to the values of referenced metanodes main records as either records (if the reference is from the primary) or as record sets (if the reference is from a referencing set). From one embodiment using a naming scheme as follows:

The above functions are of course convenience functions for the developer making it easier to access referenced data - no need to extract the reference in form of a foreign key value and load the data based on the reference - the manager knows there is a reference and how to retrieve the data.

Updating, deleting and inserting units may be done along similar lines. Insertions require no specification of an initial primary key. From one embodiment as follows:

The function, that sets the values of an extended record, shows that an embodiment of this invention may support multiple inheritance in the data model. Normally, one would not allow setting a referenced record, e.g. setting the customer record from an invoice manager. But when metanode metadata specifies that a reference from the main table should be handled as an extender this becomes reasonable. In one embodiment of this invention one or more "extends" indicators for a metanode's references from the main table is handled as follows: The resulting manager can set the main record of its main table, of any of the managers it extends, and recursively any manager they may extend. Similarly the resulting manager references direct references and recursively references of extended managers. The referencing sets of the resulting manager are again the union of its own direct and those of extended managers. Note that this retains the uniform interface all managers share, and that an advantage of the method is support for multiple inheritance.

The value setting functions above (excepting the clear function) should not be seen stand-alone. In general updating a database is done in transactions, and transactions may involve multiple managers (and database operations unrelated to manager operations), and may conflict with other transactions done by different users. In order to do this safely, managers also have functions with names like lockQ, beginQand saveQ. The managers involved in a transaction share a "session", which coordinate the transaction. The session has a commit()function and informs the involved managers whether a transaction was committed or rolled back. The typical sequence of function calls are managerl .lockQ, manager2.lock(), managerl.setXxxxQ, manager2.setXxxx(), managerl .beginf), manager2.begin(), managerl .saveQ, manager2.save(), session. commitQ. The sequence first locks the managers, i.e. prevents others from trying to change their persistent data during the length of the transaction, then new values are set, the begin function locks on database level and checks that settings are valid, the save performs the database update and finally the commit function tells the database that the transaction is now finished. The transactional functions are well documented in the computer literature see for instance Database Programming with JDBC and Java, by George Reese, 1997 O'Reilly & Associates. The transactional functions are however a little cumbersome for the programmer, so the preferred method is for the session / manager complex to implement e.g. the X/Open XA protocol to semi-automate transactional management.

The functions for reading, updating and inserting as well as some of the functions for transactional control is performed using connection 407 to the server-side JDBC component which is shared by all the subcomponents of server-side client-session component 403.

Part of the transactional behaviour of a manager is to support transaction monitoring. In one embodiment of this invention this works as follows: All managers will upon reading a database row or set of rows, register the row or rows in a shared data pool pertaining to the table the row or rows were from. Server-side data pool component 402 holds these pools. If the row was already present in the pool the manager swaps its reference to the row to the one in the pool. And the manager starts to "observe" the row as depicted by connection 408 and 409; this is a standard functionality found in most development package in one embodiment the Java TM Observer and Observable classes and interfaces. When a transaction is completed, i.e. session.commitQ is successful, all managers involved in the transaction will have their committedQ function called. This will, in turn, trigger that all rows changed by the manager will be marked as changed and those rows will be asked to notify observers (if any). Any manager observing the row will thus have its updateQ function called. Managers are, besides being observers, also Observable, so the update-function will, in turn, call the update-function of observers of the manager, as depicted with connections 410, 411 , 412 and 413. This introduces the following manager functions:

Details of the observer, observable and transaction monitoring are well documented in the computer literature (again see for instance Database Programming with JDBC and Java, by George Reese, 1997 O'Reilly & Associates), as a person skilled in the art will know. There is however one aspect of transaction monitoring that needs a little elaboration. Rows alone do not capture the membership aspect of referencing sets, i.e. the set of rows that have a unique foreign key value. Having a different type of pool also part of server-side data pools component 402 that does not have rows, but sets of row references solves this. Entries in the pool are identified by their foreign key value. Rows belonging to tables that have such pools cooperate with the pools when rows insert new, change or delete (nulls) their foreign key value.

An example may explain the purpose of these "set-pools": Invoice lines pertain to invoice orders but also pertain to the product they reference. The set of invoice lines pertaining to a given product is advised of changes through the "set-pool" (if not directly through observed rows). In this way the "order manager" need not be aware of some object interested in invoice lines across orders, the "set-pools" handle this automatically. The general problem solved is that metanodes overlap; in this example the invoice metanode and the product metanode (or a metanode building on the product metanode).

Transaction monitoring is not the only possible "transactional side effect". In one embodiment of this invention one may elect, on database table level, to have a logging of historic values, i.e. updates will write the old values to a log before overwriting the data. Other embodiments may offer to send or receive messages of some kind when changes occur. For example in order for systems that share some data to be kept synchronized.

In one embodiment of this invention, it is not allowed to use the set-function on a referencing set, if the set is based on a metanode. This is the preferred method. For example, it may not be allowed to use the set-function on the main table of the set of products, which refer to the same product group id in the above example 3, as a record set. The embodiments reasons that, if a product needs to be updated, it should be updated through a product manager - not the product group manager. Neither does the embodiment have set-functions for referenced metanodes. Another embodiment of this invention, however, may allow this.

A manager may, however, provide access to managers of referenced metanodes, which may allow you to update their units. In one embodiment as follows:

"MetanodeModel" is an interface and covers that the returned object is either a manager or an application specific object that governs an underlying manager. The above functions are again convenience functions for the developer making it easier to access referenced managers / MetanodeModels. They are, however, also part of enabling frameworks that use structural similarities between different managers; e.g. as found in hierarchies.

There is a final aspect of managers and that is their ability to provide information about what the underlying metanode looks like and what type of data it contains. Access to this information may be implemented through a set of manager functions, but the preferred method is just one manager function "getMeta()" which retrieves a MetanodeMeta class object that can be queried. The introspection functions of one embodiment are as follows:

The list above may be supplemented with functions that distinguish between "direct" sub-sets and references as opposed to "extended" sub-sets and references. Functions may also provide access to foreign key definitions as well as utilities such as iterate functions. The above functions are instrumental in making frameworks. They provide the means for an object to ft >

"see" what kind of manager it is interacting with. ξ om this information it knows what type of records and record sets is going to e interchanged, i.e. it can construct the metadata part of records and record sets. It can then subsequently construct the actual records and record sets with their proper types, using the pre-constructed metadata, based on raw data alone. The functions are also instrumental in avoiding the need for constructing business object classes where for example simple input validation is ail that's required.

In one embodiment of this invention managers do not provide access control i.e. verifying that the current user is permitted to perform various operations. In other embodiments managers may provide access control. This may either be on the level of type of metanode or more detailed on the level of metanode units.

Server-side client session component 403 also has an application logic component 405A, which contains a manager component 404B. An application logic component like 405A may contain any number of managers. The figure also illustrates that application logic may wish to provide a completely different, extended, restricted or otherwise modified interface to surrounding components. Subcomponent application logic 405B may provide other services than those mentioned above; one such important service is to provide initial access to managers e.g. a set of managers of some type that fulfil some criteria. Subcomponent application logic 405B may or may not use data pools for monitoring data as illustrated with connection 409.

Managers themselves may also provide initial access. In one embodiment of the invention managers also provide a finder function as follows:

Vector find(Criteria criteria) Get a vector of MetanodeModels matching some criteria.

In that embodiment the Criteria class is an interface. Classes implementing the interface find MetanodeModels based on e.g. a specific foreign key value, sets of main table column criteria, list of primary key values etc.

Manager construction:

Fig. 5 is a flow diagram of a process for constructing metanode unit handling instances (i.e. managers) in accordance with one embodiment of the invention. The steps are performed by a server side server process 306 in figure 3 on start-up of the application server. The initial step 501 "Read metanode definitions", defines the scope for an invocation of an embodiment of this invention. Having read the metanode definitions an invocation will know what managers to construct. Managers must however be constructed bottom-up, so the next step is 502 "Read table definitions pertaining to metanode definitions". In one embodiment of this invention, these first two steps are reversed because the input source defines first tables then metanodes - this is not the preferred method. The preferred method is that the metanode definitions (or selected metanode definitions) should define the scope of an invocation. If, however, an embodiment of this invention supplements database metadata with further metadata pertaining to table schema level, as one embodiment of this invention does (in order to offer further functionality also on this level), it makes sense to read table metadata first. The next step 503 "Construct columns, schemas, tables and data pools", serves to lay the foundation using some database foundation classes as explained above, and data pools. Data pools are basically hash tables with record keys as key containing observable rows. Step 504 "Read foreign keys pertaining to metanode definitions" completes the reading of metadata, allows construction of foreign key objects and gives final information on how managers can be composed and how they interrelate. Step 504 in conjunction with information about referencing sets also enables building the set data pools introduced above, which is step 505 "Construct data pools for handling sets". Thus primed construction of managers can commence. Managers can be quite complex and the preferred way of constructing them is by constructing sub-components first and then using those sub- components in constructing the manager. In one embodiment of the invention there exists a set of classes, which rather closely reflect the possible subcomponents of a metanode. This is the preferred way, but there are other possibilities. In one embodiment the sub-components of a manager consists of instances of the following classes:

From the same embodiment the class that has full functionality to service all metanodes is the MetanodeManager and is constructed with a MetanodeModel, handling the primary, and a set of ForeignKeyMonitors, handling the referencing sets, as parameters. Much of what a MetanodeManager does is to redirect (or fan out) function calls to pertinent subcomponents. The MetanodeManager and all of its subcomponents are constructed with a name to identify the component; the MetanodeManager's name is the same as the metanode name. To give a more complete understanding, the construction of the subcomponents follows: The JoinMonitor is constructed with the foreign key, which references the metanode, and a (reference to a prototype) manager for the metanode. The MultiJoin is constructed with a set of JoinMonitors.

The ExtendedModel is constructed similarly to the JoinMonitor, as is the ExtendedModels similarly to JoinMonitors.

The RowManager is constructed with the Table holding its records and a MultiJoin and an ExtendedModels. It may be noted that the construction of managers, or rather their subcomponents, rely on the preceding steps of 502 "Read table definitions pertaining to metanode definitions", 503 "Construct columns, schemas, tables and data pools" and 504 "Read foreign keys pertaining to metanode definitions". It is during these steps that class instances of e.g. Table and ForeignKey are constructed, which are the parameters to the constructors of manager sub-components.

The FkeySetManager is constructed with the Table holding its record sets and the foreign key that references the primary. The JoinSetManager is constructed with an FkeySetManager and a MultiJoin. The PrimaryFkeyMonitor is constructed with the Table holding its record sets, the foreign key that references the primary and a (reference to a prototype) manager for the metanode.

In the embodiment described above an important issue was left out for the sake of clarity. It is important to note that metanodes may have circular references, and hierarchies in particular have self-referencing metanodes. A way to deal with this is to make the construction process a multi stage process, i.e. managers are constructed partially and then adjusted before they are complete. In the embodiment described above construction of components that reference other managers (through MultiJoin, ExtendedModels or PrimaryFkeyMonitor) is a two or more stage process. Which brings us back to fig. 5.

Step 506 "Construct non-referencing primaries and referencing sets" is the phase were manager sub-components come in to being, without assuming that other referenced managers exist yet. Step 507 "Construct non- referencing managers" assembles possibly incomplete managers that may now be referenced. Step 508 "Construct metanode references" constructs the sub-component that references other managers. Step 509 "Add metanode references to the managers" completes the manager construction sub-process initiated in step 506. Step 510 "Add managers to object factory pool" is the step that makes managers and their remote interfaces available within the application framework. Instead of adding the manager and its remote to the object factory pool, application specific objects may at this stage be constructed. The application-tier application object is then set with the manager it governs, and then the application specific object-remote pair is added to the factory pools.

Thus, metadata driven handling of structural elements in databases has been described in conjunction with one or more embodiments. The invention is defined by the claims and their full scope of equivalents.

Claims

1. A computer-implemented method of operating on data in a database, the method comprising the steps of - obtaining structural data defining at least a first structural element, the first structural element including a first data entity including one of a) a database table with a primary key and b) a second structural element, and the first structural element further including a number of referencing data entities, each including one of a) a database table with a foreign key referencing the first data entity and b) a third structural element including a second data entity with a foreign key referencing the first data entity; - obtaining database metadata about said database tables, primary and foreign keys; - constructing at least a first class instance adapted to provide access to data records of database tables of said first structural element via a set of functions.

2. A method according to claim 1 , characterised in that the method further comprises the step of providing at least one memory space for sharing data about the first structural element among a plurality of constructed class instances.

3. A method according to any of the claims 1 through 2, characterised in that a selected one of the database table of the first data entity and the second structural element further comprises a number of references to other structural elements.

4. A method according to any of the claims 1 through 3, characterised in that a selected one of the database table of one of the referencing data entities and the third structural element further comprises a number of references to other structural elements.

5. A method according to any one of the claims 1 through 4, characterised in that the constructed first class instance further comprises at least one function for providing information about said first class instance.

6. A method according to any one of the claims 1 through 5, characterised in that the method further comprises the step of constructing at least a second class instance adapted to provide to another remote computer process access to the set of functions of the first class instance.

7. A computer-implemented method of accessing a first class instance constructed according to a method according to any one of the claims 1 through 6, the method comprising the steps of

- constructing at least a third class instance with a set of functions for accessing said first class instance; - obtaining information about said first class instance via at least one function of said first class instance for providing information about said first class instance.

8. A server computer comprising - means for accessing a database for storing a plurality of data records in a plurality of database tables;

- means for obtaining structural data defining at least a first structural element, the first structural element including a first data entity including one of a) a database table with a primary key and b) a second structural element, the first structural element further including a number of referencing data entities, each including one of a) a database table with a foreign key referencing the first data entity and b) a third structural element including a second data entity with a foreign key referencing the first data entity; - means for obtaining database metadata about said database tables, primary and foreign keys; the processing means being adapted to, under the control of the server application program, construct at least a first class instance adapted to provide access to data records of database tables of said first structural element via a set of functions.

9. A computer program comprising program code adapted to perform, when run on a data processing system, the method of any one of the claims 1 through 7.

10. A computer program according to claim 9, characterised in that it is embodied on a computer-readable medium.