DATABASE ACCESS

The present invention relates to a method and apparatus for providing access to a database.

In the modern world, a great deal of important information is stored as data in databases. It is usual for a database to have been designed for use with a suite of proprietary applications which are arranged to access and manipulate data stored in the database. It is increasingly the case that the data, data structures and general organisation of a particular database remain useful long after the proprietary applications which were designed to provide access to the database have become obsolete.

For example, a large number of mainframe computer systems still exist which provide access to relational databases. While relational databases remain an integral part of modern computer systems, mainframe computer systems have been superseded. As such, it would be useful to be able to access the data in the relational database without the need to continue using the outdated mainframe system.

One solution to provide access to relational databases of the type described above is to migrate the data from the existing relational database system into a new "off-the-shelf computer system. However, such migrations involve the translation of data from one data structure to another which means that such migrations are often time consuming and difficult, and result in imperfect data after migration.

An alternative solution involves designing a new computer program which accesses the data held in the old database; again, this can be a long and difficult process. The error prone and time consuming task of migrating old data to a new system is replaced with the error prone and time consuming task of developing a new system which is capable of working with the old data held in the old data structures in the databases.

It is an object of the present invention to obviate or mitigate at least some of the problems outlined above.

According to a first aspect of the present invention there is provided a method for providing access to a database in a computer system. The method comprises: obtaining data indicating data stored in said database, generating a schema based upon the obtained data, and modifying the generated schema to generate a modified schema comprising configuration data usable to configure a computer program to access the database. The data obtained indicating data stored in the database may indicate the structure of data stored in the database. The computer program may access the database and display data stored in the database.

In this way, the invention provides a method of generating a schema based upon a database, and modifying that schema so that it can be used as a basis for generation of an application configured to access data stored in the database. The generation of the schema based upon the obtained data may be an automated process based upon a set of rules, and the way in which data is structured in the database. The modification can also be an automated process. The modification may be based upon the generated schema and a further set of rules which specify how configuration data should be generated based upon elements of the schema.

The database may be a relational database. Such a relational database may store data in a plurality of tables, and relationships may be defined between the plurality of tables.

Said data indicating data stored in said database may be metadata read from said database. That is the obtained data may comprise data indicating the structure of the data stored in the database and relationships between different parts of the database. For example, the metadata may comprise details of database structures in said database. The structures may be, for example, tables, columns, joins, and keys although any suitable and useful properties of the database may be described by the metadata.

Modifying the generated schema may comprise adding data to the generated schema defining parameters for at least one search operation. Such a modification may be based upon elements of the generated schema. For example, such a modification may be based upon tables in the database and keys within those tables as represented in the generated schema. In this way, the modification may be arranged to encode within the schema data indicating searches which can be performed on the database using the computer program.

Modifying the generated schema may comprise adding data to the generated schema defining parameters specifying how data stored in said database should be displayed in a user interface of the computer program. That is, the modification may indicate how data returned from a search should be displayed to a user. Where the computer program provides a graphical user interface, the modification made to the schema may define how graphical user interface elements should be arranged to display data.

Modifying the generated schema may comprise adding data to the generated schema defining relationships between data stored in said database, said relationships being based upon said obtained data. For example modifying the generated schema may comprise adding a plurality of set definitions to the generated schema, each set definition defining data taken from one or more tables of the database.

The data defining relationships between the data stored in said database may comprise at least one hierarchical relationship between data stored in the database and data referred to by that data. For example, where data in the database refers to other data in the database, a relationship between the referencing data, and the data that is referenced may be defined.

At least one first script may be applied to the generated schema. The at least one first script may be arranged to modify the generated schema to generate an intermediate schema. The modified schema may be generated by modifying the intermediate schema. In this way, a developer can provide a script to modify the schema. In particular, a developer can modify the manner in which the schema represents data stored in the database or the manner in which it will be presented by the generated computer program, thereby affecting the way in which the generated application accesses and/or displays data in the database. The at least one first script may modify a part of said schema indicating data stored in the database.

The method may further comprise applying at least one second script to the modified schema to generate a final schema. The final schema may be usable to configure a computer program to access the database. That is, where the modified schema has been generated, a script may be applied to the modified schema to customise the schema and to thereby affect the computer program that is generated.

The at least one second script may define functionality for said computer program. For example particular functionality may be defined by the modified schema, and the second script may supplement the particular functionality with additional functionality.

The at least one second script may be arranged to cause said computer program to modify data read from said database before said data is processed and/or displayed by said computer program .

The method may further comprise generating an information file from said generated schema. For example, one or more HTML files representing components of the generated schema may be generated. The generated information file may comprise components identifying parts of the generated schema. The generated information file may comprise at least one command suitable for inclusion in said at least one first script. The method may also comprise generating a further information file from said modified schema. Said further generated information file may comprise at least one command suitable for inclusion in said at least one second script.

The schema and/or the modified schema may each be defined by a single file. That is, the processing described above may generate a single schema file which may be subject to manipulation in the manner described above to generate a modified schema file.

The method may comprise generating a computer program based upon said modified schema or said final schema. Generating the computer program based upon said modified schema or said final schema may comprise processing said modified schema or said final schema and generating computer program code based upon said modified schema or said final schema.

The modified schema may comprise a plurality of elements and processing said modified schema may comprise identifying a respective part of a template file based upon each of said elements, each part of the template file defining computer program code to be generated.

Said modifying said generated schema may generate a modified schema comprising additional elements which enable the association of further information with rows in the database. Said modifying may be configurable such that said additional elements of said schema enable said association on a restricted basis, such that associations may only be made and/or viewed by certain users of said computer program, or associations may only be made between said further information and a subset of rows in the database, or more particularly only the rows of a subset of tables in the database.

Said additional elements of said modified schema may be used, at least in part, as a basis for generating database structures for storing said further information. Said generating said computer program may comprise generating said database structures for storing said further information.

Said rows of said database may be searchable based upon said further information associated with said rows. Said further information may be searchable independently of said rows.

Said further information may comprise a plurality of data items, each data item of said plurality of data items being associated with one or more rows in the database. Said data items may be configured such that identifying a data item is sufficient to identify the rows with which the data item is associated. Each of said data items may comprise data indicative of a body of text. Each of said data items may be stored as a row in a database. Each data item may represent a note.

Said modifying may be such that schema elements are added to the generated schema which configure the computer program to provide functionality to enter said further information.

A computer system may comprise more than one database. Accordingly, a computer program may be generated, according to a method in accordance with the first aspect of the present invention, for each of the databases in the computer system.

A gateway computer program may be provided. Said gateway computer program may provide access to the or each generated computer program. Said gateway computer program may be configured to allow the performance of administration tasks in relation to the or each generated computer program through the gateway computer program.

Said generated computer programs may operate with reference to respective administration databases.

Said gateway computer program may be associated with a gateway administration database, said administration tasks performed by said gateway computer program comprising modifying data held in said gateway administration database. Said generated computer programs may operate with reference to said gateway administration database.

Said administration tasks in relation to either the local administration databases or the gateway administration databases may include adding, deleting or modifying data relating to one or more of: user names, privilege roles, password length, password pattern, password expiry, password reuse and expiry dates, number of password retries and inactive period before expiry.

According to a second aspect of the invention, there is provided a method for providing access to a database in a computer system. The method comprises obtaining data indicating data stored in said database; generating a schema based upon the obtained data; modifying the generated schema based upon at least one script to generate a modified schema; and generating a computer program providing access to the database based upon said modified schema.

Aspects of the invention can be implemented in any convenient way. For example methods provided by aspects of the invention may be provided by way of computer programs. Such computer programs can be carried on carrier media (or computer readable media). Such carrier media include tangible carrier media (e.g. discs) and intangible carrier media (e.g. communications signals). Computer programs provided by aspects of the invention can be run on suitable computer apparatus. Aspects of the invention can also be provided by way of suitable apparatus.

Embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic illustration of a database application generator in accordance with an aspect of the present invention;

Figure 2 is a flow chart showing processing carried out by the database application generator of Figure 1 ;

Figure 3 is a schematic illustration showing a flow of information between processes in the database application generator of Figure 1 ;

Figure 4 is an entity relationship diagram showing the tables and relations in an example database;

Figure 5 is a schematic illustration showing an overview of a schema generated by the application generator of Figure 1 ;

Figures 5A to 5D are excerpts of XML code from an exemplary XML schema generated from the database of Figure 4 by the application generator of Figure 1 ;

Figure 6 is a schematic illustration showing an overview of a modified schema generated by the application generator of Figure 1 ;

Figures 6A to 6E and 6G are excerpts of XML code from an exemplary modified XML schema generated from the database application generator of Figure 1 ;

Figure 6F is a schematic illustration of a user interface element generated from the XML code of Figure 6E;

Figure 7A is a script which is applied to schema generated from the database of Figure 4 by the application generator of Figure 1 ; Figure 7B is a fragment of XML code generated by application of the script of Figure 7A;

Figure 8A is a script which is applied to schema generated from the database of Figure 4 by the application generator of Figure 1 ;

Figure 8B is a fragment of XML code generated by application of the script of Figure 8A;

Figure 9 is a screenshot showing a HTML page displayed to provide information relating to the structure of a schema generated by the database application generator of Figure 1 ;

Figures 1OA to 1OC are excerpts of information provided by the HTML page of Figure 9 relating to a particular part of the schema generated by the database application generator of Figure 1 ;

Figures 11 to 13 are scripts which are applied to a modified schema generated from the database of Figure 4 by the application generator of Figure 1 ;

Figure 14A is a script which is applied to the modified schema generated from the database of Figure 4 by the application generator of Figure 1 ;

Figure 14B is a fragment of XML code generated by application of the script of Figure 14A;

Figures 15A, 15C and 15E are scripts which are applied to the modified schema generated from the database of Figure 4 by the application generator of Figure 1;

Figures 15B, 15D and 15F are fragments of XML code generated by application of the scripts of Figures 15A, 15C and 15E respectively;

Figure 16 is a screenshot taken from an application generated by the database application generator of Figure 1 to access data stored in the database of Figure 4;

Figure 17 is a screenshot taken from an application generated by the database application generator of Figure 1 showing searches which can be performed on the database of Figure 4;

Figure 18 is a screenshot taken from an application generated by the database application generator of Figure 1 showing an interface used to carry out a search and display search results; Figure 19 is a screenshot taken from an application generated by the database application generator of Figure 1 showing an interface used to display data retrieved from the database;

Figure 20 is a screenshot taken from an application generated by the database application generator of Figure 1 showing a security menu providing various administration functions;

Figures 21 to 23 are screenshots taken from an application generated by the database application generator of Figure 1 showing interfaces used to manage user privileges;

Figures 24 and 25 are screenshots taken from an application generated by the database application generator of Figure 1 showing interfaces used to set variable values;

Figures 26A to 26D show elements provided by a schema definition used to define schemas in an embodiment of the invention;

Figure 27 is a schematic illustration showing generation of an application based upon a generated schema;

Figure 28 is a schematic illustration of a network of computers on which a computer program generated by an embodiment of the invention is implemented;

Figure 29 is a flowchart showing processing carried out to deploy a generated application for use; and

Figure 30 is a schematic illustration of a network of computers on which two applications, generated by an embodiment of the invention and being managed centrally by a gateway application, are implemented.

As shown in figure 1 , a database application generator 1 receives as input a database 2 which is to be used as a basis for generation of a database application. The application generator 1 further receives as input a schema definition 3 and a set of configuration parameters 4. The database application generator 1 uses information from the database 2, schema definition 3 and configuration parameters 4 to generate an application 5 which is capable of interacting with the database 2 to display and/or manipulate data held in the database 2. The application 5 is generated by the database application generator 1 as Java byte code which is interpretable by a Java Runtime Environment (JRE), however it will be appreciated that the application may be generated in any suitable form. The database 2 is a relational database created using a relational database management system (such as an Oracle relational database, by Oracle Corporation, 500 Oracle Parkway, Redwood Shores, CA 94065). Data in the database 2 can be accessed and manipulated using Structured Query Language (SQL) commands. In the embodiments described herein, the database application generator 1 and the generated application 5 access and manipulate data in the database 2 using the Java Database Connectivity (JDBC) Application Programming Interface (API), which is known in the art, and provides a convenient and standardised mechanism for communication with the database 2.

In order to generate the application 5, the database application generator 1 processes metadata relating to data stored in the database 2 together with data taken from the configuration parameters 4 to generate a schema representing the application 5 in accordance with the schema definition 3. The generated schema is defined in the Extensible Mark-language (XML). The generated schema comprises a plurality of elements of various types, each element type having one or more associated attributes.

The syntax of the schema (i.e. the rules which govern the possible types of elements, their attributes and the possible relationships between elements) is defined by the schema definition 3. In general terms, the schema definition 3 defines a number of valid elements which a schema may contain and also defines relationships between the schema elements and their attributes including, for example, which elements (or attributes) may be contained within other elements, how two elements (or attributes) may be related to one another, and whether the existence of a particular element (or attribute, or attribute value) precludes or requires the existence of other elements or attributes. The database application generator 1 is arranged to process data taken from the database 2 and the configuration parameters 4 to ensure that a schema representing the generated application 5 is in accordance with the schema definition 3. As such, the database application generator 1 may run a process which takes a schema generated by processing carried out by the database application generator 1 and validates this schema using the schema definition 3.

Figure 2 shows an overview of the processing carried out by the database application generator 1 in generating the application 5. At step S1, the database application generator 1 extracts metadata relating to tables and relations from the database 2 and uses this metadata to produce a first-pass schema which describes the structure of the database 2. The first-pass schema includes elements which represent tables, views, columns, keys, indices, foreign keys and stored procedures and the relations between them taken from the database 2. At step S2, the first-pass schema is modified by scripts which add extra information relating to the database 2 (in the form of elements and attributes). The scripts are specified by a user and allow the application 5 which is generated by application generator 2 to meet particular requirements. Applying the scripts to the first-pass schema generates a second pass schema. The second pass schema generated by the processing of step S2 is further modified by processing of step S3 which is arranged to further amend the schema to generate a third-pass schema, the third-pass schema including additional elements which define the application 5 to be generated.

At step S4 the third-pass schema is further modified by scripts. The scripts applied at step S4 are intended to modify the third-pass schema so that the generated application 5 properly satisfies developer requirements. The modified schema resulting from the processing of step S4 is used, at step S5 to generate the application 5.

It should be noted that the processing of some steps shown in Figure 2 may be repeated a number of times. For example any suitable number of scripts may be applied at each of steps S2 and S4. Additionally, having applied scripts at step S2 or S4, in some embodiments processing may then return to step S1 or S3 as appropriate.

The schema generated by the processing of Figure 2 is representative of the computer program 5 which is to be generated. The generated schema can, at any step in processing of Figure 2 be validated against the schema definition 3. Indeed, in some embodiments the schema is validated against the schema definition 3 each time it is modified in some way. This validation involves checking that the elements in the schema conform to the syntax defined in the schema definition 3. During the validation process, any elements in the schema which do not comply with the schema definition are removed from the schema.

Figure 3 shows operation of database application generator 1 in further detail. Metadata from the database 2 is read by a schema extraction process 6 which generates a first-pass XML schema 7. The schema extraction process 6 is arranged to carry out the processing of step S1 of Figure 2 described above, and the first-pass XML schema 7 therefore includes data describing the general structure of the database 2 and its constituent elements.

The database application generator 1 is further configured to process the first pass XML schema 7 to generate a first set of HTML files 8. The first set of HTML files 8 provides, in a user readable form, details of the structure of, and contents of, the first pass XML schema 7. A post extraction update process 9 is arranged to process the first pass XML schema 7 by modifying the first pass XML schema 7 based upon user specified scripts 10, so as to generate a second pass XML schema 11. In general terms, the user specified scripts 10 are arranged to modify the first pass XML schema 7 so that the application 5 which is ultimately generated meets particular requirements. The second pass XML schema 11 is processed to generate a second set of HTML files 12 which provides details of the structure and contents of the second pass XML schema 11.

A derivation process 13 is arranged to process the second pass XML schema 11 output from the post extraction update process 9, and generate a third pass XML schema 14 based upon its processing. In general terms the derivation process 13 is arranged to process the second pass schema 11 to add details required to define operation of the application 5. The details added generally specify how the application 5 will allow users to interrogate the database 2, and how the application 5 will display data retrieved from the database 2. For example, the derivation process 13 will add to the second pass schema 11 data indicating searches of the database 2 that can be carried out using the application 5 and indicating how the results of those searches should be displayed.

The database application generator 1 is also configured to process the third pass XML schema 14 and generate a corresponding third set of HTML files 15, which can be conveniently viewed to provide details of the structure and contents of the third pass XML schema 14.

A post derivation update process 16 is arranged to process the third pass XML schema 14 by modifying the third pass XML schema 14 in accordance with user specified scripts 17. The post derivation update process 16 outputs a fourth pass XML schema 18.

The application generator 1 assigns icons to represent particular parts of the database 2 in a graphical user interface. A re-assign icons process 19 is arranged to ensure that parts of the database having particular icons in a previous version of an application have corresponding icons in the version which is currently being generated. This is achieved by use of an icon file 20 which is input to the re-assign icons process 19 and indicates icons already assigned to particular parts of the database. The re-assign icons process 19 therefore takes the fourth pass XML schema 18 and adds data corresponding to icon assignments represented in the icon file 20, to generate a fifth pass XML schema 21.

The fifth pass XML schema 21 is input to an auto-assign icons process 22 which assigns icons to parts of the database with which icons are not associated in the fifth pass XML schema 21. The auto-assign icons process 22 outputs a sixth pass XML schema 23 in which all parts of the database requiring icons have appropriate icon assignments. Additionally, the auto- assign icons process 22 updates the icons file 20 to represent all icon assignments - both those applied by the re-assign icons process 19 and those applied by the auto-assign icons process 22.

It will be appreciated that when the database application generator 1 is applied to a particular database 2 for a first time, the icons file 20 will be empty, and no assignments will be made by the re-assign icons process 19. In such a case, all icons are assigned by the auto-assign icons process 22.

The sixth pass XML schema 23 output from the auto-assign icons process 22 is input to a validation process 24. The validation process 24 is arranged to ensure that the sixth pass XML schema 23 complies with the schema definition 3. To the extent that parts of the sixth pass XML schema 23 do not comply with the schema definition 3, those parts of the schema definition are deleted to generate a seventh pass XML definition 25. Additionally, the validation process 24 may provide output indicating to a user changes that have been made to ensure that the seventh pass XML schema 25 complies with the schema definition 3. The database application generator 2 also generates a set of HTML files 26 which represents the seventh pass XML schema 25.

Although the validation process 24 is shown as a separate process in Figure 3 for ease of description, in some embodiments each time the schema is modified in some way it is subsequently validated with reference to the schema definition 3. That is, validation may form an integral part of each of the schema extraction process 6, the post extraction update process 9, the derivation process 13, the post derivation update process 16, the re-assign icons process 19 and the auto-assign icons process 22.

It has been explained above that respective sets of HTML files are generated based upon the first pass XML schema 7, the second pass XML schema 11 , the third pass XML schema 14, and the seventh pass XML schema 25. Each of these sets of HTML files allows a convenient view of the corresponding XML schema to be provided. It will be appreciated that in alternative embodiments of the invention others of the XML schemas can be used as a basis for generation of corresponding sets of HTML files, instead of or in addition to the XML schemas used as a basis for the generation of sets of HTML files in the preceding description.

The seventh pass XML schema 25 is used as a basis for the generation of Java source code. As such the seventh pass XML schema 25 is input to a Java source generation process 27 which outputs Java files 28. The Java source generation process 27 may make use of JXP to process the XML files to appropriately generate the Java files 28 as is described in further detail below. In general terms, a plurality of classes and relationships therebetween are defined by the Java source generation process 27. The Java source generation process 27 is arranged to appropriately create the relevant classes, so as to create an application in accordance with the schema.

The Java files 28 are input to a Java source compilation process 29 together with resource files 30. The Java source compilation process 29 outputs Java Archive (.jar) Files 31 which make up the generated application 5. The Java source compilation process 29 additionally outputs language files 32 which are used by the generated application 5. The language files 32 include natural (i.e. human) language components which are included in the generated application 5, and as such can be translated between natural languages to allow the generated application to be used by users with knowledge of different languages.

The generated application 5 is configured to be operated over a computer network. As such, the generated application 5 comprises client components and server components. The client components are provided to client computers over the computer network. A web config generation component 33 generates configuration data for a webserver which is to provide the client components to the client computers. The web config generation component 33 receives property files 34 and outputs configuration data 35 for the web server. The configuration data 35 is provided to a web server deployment process 36 together with the generated Java Archive files 31. The web server deployment process 36 processes the Java Archive files 31 to generate Web Archive (.war) files 37 which is used to provide the application to client computers. Deployment of the generated application 5 is described in further detail below.

Examples of operation of the processing described with reference to Figure 3 are now presented with reference to an example database shown in Figure 4, representing data relevant to a zoo. An overview of data stored in the database of Figure 4 is now presented before the processing of the database is described in further detail.

A zoo table 40 stores general information relating to a zoo including name and address information, opening time information, and ticket price information. An address field of the zoo table 40 identifies a record of an address table 41. Each unique address used in the database is represented by a record of the address table 41. An addressjine table 42 is used to store address lines, and each record of the addressjine table 42 is associated to a particular address by a value stored in an addressjd field which identifies one of the records of the address table 41. A seq field of the addressjine table 42 orders lines of a particular address, that is orders records of the addressjine table 42 associated with a particular record of the address table 41. An employee table 43 stores data relating to individuals employed by a zoo. The employee table 43 comprises fields storing data relating to employees including name, address and salary details. Address data relating to a particular employee is stored using the address table 41 and addressjine table 42 described above. To achieve this, an address field of the employee table 43 identifies a record of the address table 41. Each employee may have a supervisor, and as such a supervisor field in the employee table 43 identifies another record of the employee table 43 which represents an employee's supervisor.

A holiday table 44 is used to store data relating to holidays (i.e. vacations) taken by employees. Each record of the holiday table 44 relates to a particular holiday taken by a particular employee, and as such an employeejd field in the holiday table identifies a record in the employee table 43 storing data relating to the employee associated with a particular holiday.

A zoo_employee table 45 associates employees with zoos. That is, the zoo_employee table 45 stores records comprising a zoo_id identifying a record of the zoo table 40 and an employeejd identifying a record of the employee table 43.

An animal table 46 is used to store data relating to animals who are housed in zoos represented in the database. Data relating to each animal is stored including name, and date of birth information. Each animal is associated with a particular zoo by a value stored in an at_zoo field which identifies one of the records of the zoo table 40. Each animal represented by data stored in the animal table 46 may have a parent whose data is also stored in the database. As such, a parent field of the animal table 46 identifies a record of the animal table 46 storing data relating to an animal's parent. Of course, a particular animal may have more than one parent.

An animal_type table 47 stores data relating to types of animals, and a type field of animal table 46 identifies one of the records of the animal_type table 47 to specify an animal's type.

An animal_partner table 48 is used to store relationships between pairs of animals. Each record of the animal_partner table 48 stores an animaljd and a partnerjd field, both of which identify a record of the animal table 46.

The database stores data relating to a plurality of skills in a skill table 49. Each skill has a name, and identifier and a description. Each skill is associated with a particular animal type and an animal_type_id included in the skill table 49 therefore identifies one of the records of the animaMype table 47. Employees posses various skills. As such, an employee_skill table 50 represents relationships between employees for which data is stored in the employee table 43 and skills for which data is stored in the skill table 49. To do this, the employee_skill table

50 has an employeejd field identifying a record in the employee table 43, and a skilljd field identifying a record in the skill table 49.

Referring back to Figure 2, it will be recalled that the schema extraction process 6 is arranged to generate the first pass XML file 7 representing components of the database 2. Figure 5 shows tags included in the first pass XML file 7. A top level <schema> tag defines the schema, and encloses a plurality of other tags.

An <application> tag defines properties of the generated application 5 at a top level. Each <schema> tag comprises a single <application> tag. A <privilege> tag defines a privilege that will be associated with particular functions in the generated application. <item>, <record>, <recordltem>, <join> and <joinCondition> tags> are used to represent the structure of the database upon which the generated application is based, as described in further detail below.

Figure 5A shows the <application> tag created by the schema extraction process 6 from the zoo database. Its attributes are now described.

A classPrefix attribute specifies a textual prefix which will be used in all generated class names, in this case the prefix to be used is DnvZoo, and this was determined by the schema extraction process 6. defaultDateFormat and defaultDateTimeFormat attributes respectively specify how dates and times should be displayed in the generated application 5. It will be appreciated that there are many well-known methods (such as regular expressions) for defining how date formats, and such methods can be applied here. An id attribute contains an internal identifying name used in the schema so as to reference the application element from within the schema. The value of the id attribute is unique within the schema so as to allow a particular element to be uniquely identified. A screenName attribute specifies text which is included in the title bar of the generated application 5. A source attribute specifies a part of the generation process responsible for creation of the application element.

Examples of privilege elements created by the schema extraction process 6 are shown in Figure 5B. Privilege elements are used in the schema to administer permissions and include id, and description attributes. The id attribute specifies a unique identifier for the privilege, while a description attribute provides a textual description.

A particular user of the generated application 5 is associated with a subset of the privileges defined in the schema from which the application is generated. A privilege is associated with a particular element of the schema by adding a privilege attribute to the particular element which references the defined privilege.

The schema extraction process 6 defines some standard privilege elements: "user", "developer", "data_structure", "designer", "technical" and "security" as shown in Figure 5B. Each of these defined privileges can be attached to particular elements of the schema using user defined scripts of the type described below. The "technical" privilege is also used by the schema extraction process 6 which applies the "technical" privilege to elements of the schema, during schema generation, which are for developer use and should not be viewable by a user or developer of the system. Such elements include those representing internal index columns and/or system tables in the database 2. It will be appreciated that these elements are still viewable by any user who is associated with the "technical" privilege.

As has been indicated above, the <item>, <record> and <join> tags are used to represent the structure of the database 2 in the generated schema.

Examples of two <item> tags generated by the schema extraction process 6 from the zoo database are shown in Figure 5C. Each <item> tag represents a field (i.e. column) in one or more of the tables of the zoo database. Where a column appears in more than one table, it is represented by a single <item> tag. That is, the schema extraction process generates a plurality of item elements, each of which is unique and each of which represents one or more columns in the database.

Attributes of each <item> tag include a screenName attribute which is used to indicate how the item will be identified in the user interface of the generated application 5. An id attribute provides a unique identifier for that item to allow the item to be referred to within the schema. A className attribute is defined for every item element, and contains a name of the Java class which will be generated for the element in the application 5, the class name being generated by the schema extraction process 6. A storedData attribute indicates a type of data which is stored in the part of the database which resulted in generation of the item. For example, it can be seen that in the case of the "Animalld" item (which corresponds to the animalj ^' d field of the animal table 46, and the animal partner table 48) the storedData attribute indicates a data type of INTEGER. In the case of the "Colour" item (which corresponds to the colour field of the animal table 46) the stored data is of type VARCHAR. Each of the example <item> tags also includes a storedSize attribute indicating a number of displayable characters stored in the corresponding fields of the database. In the case of the INTEGER datatype, a stroedRadix attribute indicates a number base used to store the values in the database. The storedType attribute stores data indicating a vendor specific name for the data type indicated by the storedData attribute. Item elements may also have a number of formatting attributes which govern how data from a column corresponding to the item element is displayed, including information about the size of each data value and whether or not the column value may be wrapped at the end of a line. It will be appreciated that an item element might sensibly carry attributes which define any aspect of the treatment of a column data from the database 2 if that definition may be applied to every column with which the item element is to be associated.

A smartClass attribute specifies a class name for a class arranged to handle data of the type indicated by the storedData, while a source attribute indicates the source of the item, which will in the case of items created by the schema extraction process 6 be set to "database" to indicate that such items were created.

By allowing an item element to correspond to more than one column in the database 2, duplicate columns in different tables can share attributes. For example, as shown in Figure 4, both the animal table 46 and the zoo table 40 each have an "id" field. These two fields are both represented by a single id element in the schema.

It can be seen that column name (i.e. the name of the column in the database) is not an attribute of the item element. This allows item definitions to be shared even when column names are different. The column name is supplied when the item is used within the definition of a 'record' as is described below.

Record elements (defined using the <record> tag) are used to represent three kinds of structure: database tables, database views and application views. A record element is created for each table and view in the database 2 by the schema extraction process 6. Figure 5D shows the record element created to represent the animal table 46 of the database of Figure 4.

It can be seen that the record element comprises class name, screenName, id and source attributes which correspond to like named attributes of the item element described above.

A tableType attribute indicates a type of structure (e.g. table or view) which is represented by the record. A primaryKey attribute identifies a recordKey element (described below) which represents the primary key for the database structure represented by that record item. A table attribute identifies the name of the table or view in the database 2 represented by the record (i.e. "animal" in this case given the name of the animal table 46. The record element shown in Figure 5D contains recordltem elements and a recordKey element.

A recordltem element is always defined within a record element and corresponds to an item element defined elsewhere in the schema using an <item> tag of the type described above. A recordltem element can be considered to be an instance of an item element within a record, for example representing a particular column within a table represented by that record.

As can be seen in Figure 5D each recordltem element comprises id and source attributes which operate as described above with reference to other elements. An item attribute indicates an id value of the item element upon which the recordltem is based, and localName attribute contains the name of the recordltem as it will be represented within a Java class in the generated application 5. A column attribute indicates the name of a column in the database which is represented by the recordltem element.

A recordKey element is created within a record element during the schema extraction process 6 so as to represent each key (that is each primary and non-primary key, and each index) in the table represented by the record. The recordKey element contains one recordKeyltem element for each column of the table which is part of the key for that table. That is, where a key is defined by a plurality of columns a recordKey element will contain a plurality of recordKeyltem elements, one for each column.

It can be seen in Figure 5D that the recordKey element includes a className attribute indicating a class name which is to be used to represent the key in the generated application. An id attribute provides a unique identifier for the element within the schema, while a source attribute indicates the source of the attribute as has been described above. A unique attribute indicates whether the key is unique in the database 2.

The recordKeyltem element again includes a source attribute of the type described above. An item attribute identifies the item within the record which acts as the part of the key represented by the recordKeyltem element, and a sortOrder attribute indicates an order in which records should be sorted, where 'A' denotes ascending, and 'D' denotes descending. The schema extraction process 6 is arranged to apply a value of 'A' to the sortOrder attribute by default.

It can be seen, therefore, from Figure 5D that the record element representing the animal table 46 includes a recordKey element indicating that the key is the id field, as can be seen is the case from Figure 4. It can further be noted that the primaryKey attribute of the record element indicates that the primary key of the record representing the animal table 46 is represented by a recordKey element having an identifier "PK_animal" as can be seen is the case in Figure 5D.

Having described the use of item tags representing columns, and record tags representing tables and other structures, the use of join elements to represent relationships between database structures is now described with reference to Figure 5E which shows an example join element included in a schema created by the schema extraction process 6 from the example database of Figure 4.

Figure 5E shows the join element created to represent the relationship between the address table 41 and addressjine table 42. Referring back to Figure 4, it can be seen that records of the addressjine table 42 reference a respective record of the address table, and it is this relationship that is represented by the join element of Figure 5E.

The join element includes a className attribute which specifies a class name which will be used to represent the join in the generated application 5. An id attribute provides an identifier for the join element. leftRecord and rightRecord attributes respectively represent the LEFT and RIGHT elements of an SQL join statement performed on the database. Each of the leftRecord and rightRecord attributes references one of the record elements by using the identifier of the record element. In this case, it can be seen that the leftRecord attribute references a record element representing the addressjine table 42 while the rightRecord attribute references a record element representing the address table 40.

A joinCondition element within the join element defines a condition associated with the join. More particularly the joinCondition element specifies a joinLeftltem attribute to identify an item of the record specified by the leftRecord attribute and a joinRightltem attribute to identify an item of the record specified by the rightRecord attribute. In this case, it can be seen that addressjd is specified for the record associated with the leftRecord attribute of the join element (which in this case represents the addressjine table 42), while id is specified for the record associated with the rightRecord attribute of the join element (which in this case represents the address table 40).

Referring back to Figure 2, the preceding description has explained operation of the schema extraction process 6 to produce the first pass XML schema 7 which has been described with reference to Figure 5. As described above, the first pass XML schema 7 is modified by a post extraction update process 9 which applies one or more user defined scripts 10 to the first pass XML schema 7. In general terms, the scripts applied by the post extraction update process 9 3959

20

modify the first pass XML schema 7 described above to add schema elements and modify elements created by the schema extraction process 6. The use of such scripts is described in further detail below. The second pass XML schema 11 which is output from the post extraction update process 9 is input to a derivation process 13 which modifies the second pass XML schema 11 to generate the third pass XML schema 14. For the purposes of the present example, the second pass XML schema 11 input to the post extraction update process 9 is assumed to be identical to the first pass XML schema 7, that is, it is assumed that no scripts are applied by the post extraction update process 9.

The third pass XML schema 14 is shown in outline in Figure 6. It can be seen that in addition to the elements included in the first pass XML schema 7, additional elements are now included. Newly added elements are emboldened in Figure 6. The newly added elements are now briefly described, before examples of the newly added elements are discussed with reference to the example database of Figure 4.

It can be seen that <record> tags now include an <identifyiπgBements> tag which is used to identify a record element to a user. By default, each record has an <identifyingElements> tag which indicates the unique key with the greatest number of columns of the record.

Various set elements are used to represent data which is used by the generated application 5.

A <set> tag is used to specify a set. Herein, a set is used to define a relationship from which an SQL query can be derived. Different types of sets are used for different purposes, each type of set having its own tag. Three types of set are provided: hierarchical sets defined by a <hierachicalSet> tag, singleton sets represented by a <singletonSet> tag and open sets represented by an <openSet> tag. Each <set> tag comprises exactly one <hierarchicalSet>, <openSet> or <singletonSet> tag.

A hierarchical set is used to represent a relationship in which ownership is defined. Hence hierarchical sets are used to derive lists of 'children' for a 'parent'. Hierarchical sets consist of one or more record elements, one of which is deemed to be a parent having relationships with child record elements. A <setJoin> tag is used to identify a defined join element (of the type described above) representing a relationship between two records. A <hierarchicalRecord> is used to identify child records in the relationship defined by the hierarchical set.

An open set is used to represent a set with no sense of ownership. An open set uses one or more record keys from which limiting criteria and a query order may be determined. An <openRecord> tag identifies a record upon which the set is based, while an <openKey> tag indicates a key which is to be used to define the set.

A singleton set is used to represent a relationship which defines detail associated with a particular entity (usually a row in a particular table). From a singleton set a singleton query can be derived where only the first row in a result set will be processed. It can be seen from Figure 6, that a definition of a singleton set may include a <setJoin> tag which serves the purpose described above in connection with hierarchical sets. A <singletonRecord> tag identifies a record on which the singleton set is based, and a <singletonKey> tag defines a key with which to order any result set which returns more than one row associated with the singleton set. Given that only a first row in any result set returning more than one row id processed, it will be appreciated that the key defined by the <singletonKey> tag determines which row is processed.

The derivation process 13 is arranged to generate a singleton set for each <record> tag in the schema, an open set for each <recordKey> tag in the schema, and a hierarchical set for each <join> tag in the schema.

It can be seen in Figure 6 that <detailFrame> and <searchFrame> tags are also included in the third pass schema generated by the derivation process 13. In general terms, a <detailFrame> tag specifies how data will displayed to a user in a user interface of the generated application 5. A <detailNavigation> defines how a user will navigate through data in the user interface, while a <detailSets> tag defines sets of data which are displayed. The <detailSets> tag can enclose <detailSingletonSet>, <detailTableSet> and <detailEmbeddedSet> tags relating to particular sets containing data which is to be displayed, <detailBanner>, <detailPanel> and <detailTable> tags comprise further data relating to how data is displayed to a user.

The <searchFrame> tag is used to define search functionality provided within the generated application 5.

Each of the newly added tags which is emboldened in Figure 6 is now described with reference to an example based upon the database of Figure 4.

Figure 6A shows the <ldentifyingElements> tag which is added to the <record> tag representing the animal table 46 which was described with reference to Figure 5C. It can be seen that the idenfyingElements item includes a source attribute indicating that the element was created by the derivation process 13 (rather than by, for example, a user defined script). The identifyingElements item includes an identifying Item element which comprises a recordltem attribute indicating that the id item of the record is to be used to identify the record. Figure 6B shows a hierarchical set included in the third pass schema 14. The hierarchical set represents the relationship between the address table 41 and the addressjine table 42 of the database of Figure 4. More particularly, the hierarchical set is used to associate records of the addressjine 42 with an appropriate record of the address table 41. The hierachical set is defined by a <set> tag having a className attribute indicating a class that will be used to represent the set. An id attribute is used to provide an identifier for the set. A source attribute indicates that the hierarchical set was created by the derivation process 13.

A <hierarchicalSet> tag is used to indicate that the set defined by the <set> tag is a hierarchical set. The <hierarchicalSet> tag comprises a parent attribute identifying a record within the schema which is the parent in the relationship represented by the hierarchical set. A source attribute is used to indicate how the hierarchical set element was created, in this case by the derivation process 13.

A <setJoin> tag is used to identify a join defined within the schema which is used to form the hierarchical set. In this case the identified join is that between the record representing the address table 41 and the record representing the addressjine table 42 shown in Figure 5E. The <setJoin> tag again includes a source attribute indicating how the <setJoin> tag was created.

A <hierarchicalRecord> tag is also included within the set element. The <hierarchicalRecord> tag is used to identify a record within the schema which is the child record in the relationship represented by the hierarchical set. Where the parent record is related to a plurality of child records, a plurality of <hierarchicalRecord> tags are included within a particular <hierarchicalSet> tag. A <hierarchicalRecordKey> tag is used to provide a key on the record identified by the <hierarchicalRecord> tag which is used to order results.

It can be seen that the <hierarchicalSet> tag further comprises navigable and pageable attributes. Each of these attributes takes a Boolean value. A hierarchical set is said to be navigable if it represents a one-to-many relationship between the parent record and a record indicated by a subject record attribute. In such a case it is possible to identify a parent record when a subject record is displayed. In the case of the example of Figure 6B, it can be seen that the navigable attribute has a value of true, indicating that for a given address line, a unique address can be returned, as can be seen to be the case from Figure 4.

A set is marked pageable if the concatenated keys of non-parent records are unique, meaning that instances of rows of non-parent records can be retrieved a number of rows at a time. It can be seen that in the example of Figure 6B the hierarchical set is shown to be pageable, this is because rows of the addressjine table 42 can be retrieved one by one.

When a hierarchical set is navigable, the pageable attribute also indicates whether navigation to adjacent subject records associated with that parent record is possible.

Sets denoting many-to-many relationships can be pageable but not navigable.

One to many sets, for which the child records cannot be uniquely identified, may be navigable but not pageable.

Figure 6C shows an example of an open set created based upon the record representing the address table 41. className, id and source attributes of the <set> tag operate as described above. An <openSet> tag within the <set> tag includes pageable and source attributes which, again, operate as was described with reference to hierarchical sets. An <openRecord> tag within the <openSet> tag identifies a record upon which the open set is based using a record attribute. It can be seen that in this case, the open set is based upon the Address record. A source attribute is again provided. An <openKey> tag within the <openRecord> tag identifies a key (using a key attribute) which is used to define the open set, by reference to a <recordKey> element within the identified record.

Figure 6D shows an example of a singleton set created to represent data represented by the address table 41. Again, a <set> tag provides className, id and source attributes which operate as described above. A <singletonSet> tag identifies a record which is to provide data for the singleton set using a subjectRecord attribute. That is, the primary key of the record identified by the subjectRecord attribute is used to provide data for the singleton set. A <singletonRecord> tag is used to identify any records which are to be returned within the resultSet of the query generated for a singletonSet; this would typically be the subjectRecord and any other records joined using a <setJoin> element..

Figure 6E shows a portion of an XML schema which defines a <detailFrame> tag corresponding to the "Zoo" <record> tag. Each <detailFrame> tag in the schema corresponds to a window displaying detailed information about a single row of data in the database in the user interface of the generated application 5. The <detailFrame> tag has a number of attributes, including subjectRecord, which is used to define a record defined in the third pass schema 14 the detailFrame represents. A <detailFrame> tag contains a <detailSets> tag, which contains tags that identify data to be displayed in the corresponding detail Frame. As shown in figure 6E, the Zoo <detailFrame> tag contains a <detailSets> tag, which in turn contains one <detailSingletonSet> tag and four <detailTableSet> tags.

A <detailSingletonSet> tag has a singletonSet attribute which identifies a <singletonSet> tag in the schema which is to supply data to the detail frame.

A <detailTableSet> tag has a hierarchicalSet attribute which identifies a <hierarchicalSet> tag in the schema to be used to populate a table represented by a corresponding <detailTable> in the detailFrame.

The Zoo <detailFrame> tag also contains a single <detailBanner> tag, which defines a banner section of the detailed information window generated for this <detailFrame> tag by the generated application 5. As shown in figure 5E, the <detailBanner> tag inside the Zoo <detailFrame> tag contains a defaultSet attribute which refers to the SsZoo singletonSet and a useDefaults attribute which states that the default viewing options apply for this banner. The <detailBanner> tag contains a <detailSelection> tag, which contains a displayed attribute indicating that the group of tags inside the <detailSelection> tag represent data which will not be displayed in the banner, in this case a single <detailSelectionltem> tag related to the "id" recordltem in the Address record.

The detailSelectionltem tag has an attribute "item" which contains the id of a <recordltem> tag inside the Address <record> tag. This <recordltem> id represents a column in the database, from which information is drawn to populate an area of the banner section.

The <detailFrame> tag contains a <detailNavigation> tag, which contains tags to represent each of the recordKeys and hierarchicalSets to be shown in the detailFrame that are navigable. In the Zoo <detailFrame> tag there are two <detailNavigationKey> tags and a <detailNavigationSet> tag.

The <detailNavigationKey> tags represent a <recordKey> displayed in the detail frame which will have navigation buttons, allowing a user to navigate through the rows of a table in the database one record at a time based upon the <recordKey>. The privilege set for these tags is that of "technical", which indicates that normal users will not be able to perform this kind of navigation. The <detailNavigationSet> tag contains an id attribute linking the tag to a <hierarchicalSet>.

Where there are a number of rows in a child record which relate to a single row in a parent record and where a row of the parent record is the subject of the detailFrame, a <detailNavigationSet> tag may be used to include this data in a navigable form.

As described above, the <detailFrame> tag shown in figure 6E contains a <detailPanel> tag and four <detailTable> tags. An attribute "useDefaults" is set to "true" to indicate that all of the default fields in the singletonSet should be displayed. As a default view is being used, a defaultSet attribute must be set so as to indicate which set is displayed in this panel. The <detailPanel> tag in this case is used to display the SsZoo singletonSet in a panel beneath the banner, and defaultSet attribute links the tag to the singletonSet.

The <detailTable> tags are used to display hierarchicalSets beneath the banner in the form of tables, and include id attributes linking them each to a <hierarchicalSet> tag in the schema.

Figure 6F shows an example of major components of a detail frame defined using the constructs described with reference to Figure 6E. More specifically, a detail banner area 61 provides various identifying information specified by the <detailBanner> tag. A detail navigation area 62 provides navigation functionality specified by the <detailNavigation> tag, while a detail panel area provides detail relating to displayed records. Where more than one <detailNavigation> tag is included within a <detailFrame> tag the detail panel area 63 includes information from each <detailFrame> tag in a separate tab. A screenshot of a detail frame is described below with reference to Figure 19.

A search frame is created for each search that can be carried out on the database. The derivation process 13 creates one search frame for each open set, each search frame being based upon the key of the respective open set. Figure 6G shows a search frame created based upon the open set representing the address table 41. First, it can be noted that className, id, and source attributes function as described above. An openSet attribute identifies the open set with which the searchFrame is associated. A targetRecord attribute indicates a record which should provide data in response to the search. A pageable attribute is provided so as to enable a pageable set to be treated as a non-pageable set; that is all the rows of the result set will be returned and no paging buttons will appear.

Referring back to Figure 3, the derivation process 13 has been described above. As indicated above, icons are assigned to various components of the generated schema both by a re-assign icons process 19 and an auto-assign icons process 22. Icons are attached to various components of the schema by adding an icon attribute to elements of the schema indicating a path name where the relevant icon files can be located.

It has been explained above that the schema can be modified by a post extraction update process 9 which applies user defined scripts 10, and a post derivation update process 16 which applies user defined scripts 17. Figure 7A shows an example of a script applied by the post extraction update process 9 to add additional keys to the first pass schema 7 generated by the schema extraction process 6.

The script of Figure 7A uses a bespoke script language which provides intuitive commands arranged to modify the schema.

A root command indicates that the script is to navigate to the root level of the schema. A select statement then identifies an element using its identifier (although other criteria can be used). In this case, the record representing the animal table 46 is identified. A new command indicates that a new record Key element (defined by a <recordKey> tag) should be added to the definition of the record representing the animal table 46. set commands provide values for id, className and unique attributes associated with the created recordKey element. Two new commands create new recordKeyltem elements (defined by a <recordKeyltem> tag) within the created recordKey element, the record Keyltem elements having item attributes respectively having values of "name" and "id".

The effect of applying the script described above to the first pass schema 7 is to create a <recordKey> tag within the second pass schema 11 , defining a key which is made up of the combination of id and name fields of the animal record. Part of the schema generated in response to application of the script of Figure 7A is shown in Figure 7B. The generated XML has the form described above. It can be noted, however, that here the source attribute of the <recordKey> tag is set to identify the script which caused the record key element to be generated.

Figure 8A shows another example script which is applied by the post extraction update process 9. Here, the script is arranged to created a new hierarchical set representing the address of a particular employee. It can be seen that the script creates a new set element and sets its className and id attributes appropriately. A new hierarchicalSet element (defined by a <hierarchicalSet> tag) is created within the created set element, and has its parent attribute set to indicate the Employee record. Two joins are then identified using setJoin elements which are created within the hierarchical set element. These joins identify a join between a record representing the addressjine table 42, and a record representing the address table 41 , and a join between a record representing the employee table 43 and a record representing the address table 41. As such, rows of the addressjine table 42 associated with (or belonging to) a record of the employee table 43 can be identified. A hierarchical record element is created to indicate records which are to be included in the hierarchical set.

Figure 8B shows the XML created in response to the script of Figure 8A. Again, the XML created has the form described above with reference to Figure 8A, and is therefore not described further here. It should be noted, however, that the XML shown in Figure 8B includes a <hierarchicalRecordKey> tag. Such a tag is automatically created for any hierarchicalRecord not possessing a key this acts as the primary key of the record during subsequent processing.

The description with reference to Figures 7 and 8 has explained how additional elements can be added to a schema using scripts. It is to be noted that scripts can also be used to modify parts of a schema created by the schema extraction process 6. For example, a script may locate a key created by the schema extraction process 6 and add items to that key, rather than creating a new key as has been described above.

It can be seen from the preceding description, that scripts which are applied to the generated schema identify elements within the schema. This requires the creator of the scripts to have knowledge of identifiers of particular elements in the schema. For example, the script of Figure 7A required a developer to have knowledge of the identifier of the record representing the animal table 46 within the generated schema.

In order to do this, a developer can examine the first pass schema 7 by examining the first set of HTML files 8 created from the first pass schema 7. Figure 9 shows an example of a set of HTML files as displayed to a user. The set of HTML files is displayed in three frames. A first frame 60 provides an overview indicating the XML file from which the set of HTML files was created, and the elements within the XML schema. For each element a number of instances of that element is shown. For example, it can be seen that the schema used to generate the set of HTML files included 11 record elements. A second frame 61 is provided to allow navigation of the schema. The schema itself is represented in a third frame 63. An element of the schema can be selected from the third frame 63 to cause that element to be displayed in further detail in the third frame 63. Selection of the record element 64 representing the animal table 46 causes the third frame 63 to display data shown in Figures 1OA to 1OC. Although Figures 1OA to 10C show the displayed data in three parts, the displayed data is in fact all located with the frame 63 and a user can scroll through the displayed information. Information shown in Figure 1OA shows the XML used to define the record representing the animal table 46. From this information a developer can determine that the record representing the animal table has an id attribute having a value of "Animal".

Information shown in Figure 1OB is particularly intended to aid a developer in writing a script which modifies the record element representing the animal table 46. More particularly a first area 65 includes a command which should be included in a script to locate the record representing the animal table 46. A second area 66 includes data indicating mandatory attributes of the record element, together with the values which have been assigned in the schema. A third area 67 includes data indicating optional attributes of the record element. Where values are associated with these optional attributes, these are shown in the third area 67.

It will be appreciated that the information shown in the areas 65, 66, 67 is of considerable assistance to a developer. Specifically, text for inclusion in a script can be created using a "cut and paste" operation, thereby providing a convenient mechanism for allowing a developer to specify within a script elements and attributes of the schema which are to be modified by the script.

Figure 10B also shows that attributes and their values are presented in a tabular form in an area 68. This tabular presentation allows a hyperlink associated with a value to be selected by a developer to cause display of the relevant part of the schema. For example, if the "PK_animal" value 69 associated with the primaryKey attribute is selected, information relating the definition of the key having identifier "PK_animal" is presented in the third frame 63.

Figure 10C shows information indicating references to the record element representing the animal table 46 from other parts of the schema in an area 70. Here, it can be seen that a plurality of join elements reference the record element representing the animal table 46. An area 71 identifies elements of the schema which are referenced by the record element representing the animal table. An areas 72 identifies parent elements of the element to which the displayed information relates, in this case the top level schema element.

The preceding description has explained how scripts can be applied by the post extraction update process 9, and has also explained how information useful in the creation of those scripts can be obtained. It will be recalled that scripts are also applied by a post derivation update process 16. Information allowing parts of the third pass schema 14 to be identified in scripts 17 to be applied by the post derivation update process 16 can be obtained from a set of HTML files 15 created from the third pass XML schema 14, which takes a similar form to the set of

HTML files described above with reference to Figures 9 and 10.

Examples of scripts 17 applied by the post derivation update process 16 are now described. Referring first to Figure 11 , a script is shown which is arranged to modify attributes associated with the sole application element within the schema. Two attributes are set. An icon attribute is set to provide an icon file for the application. The icon file provides an icon which is displayed to represent the application on a user's desktop or in a file system. A wallpaper attribute specifies a graphics file which is used to provide a background within the generated application 5. The script of Figure 11 also shows that the scripts 17 can set an icon attribute associated with a particular record. In this case, a record having the identifier "Animal Partner" is selected, and its icon attribute is set to provide an icon which will be used to represent the record within the generated application 5.

Figure 12 shows a script which is arranged to delete parts of the schema created by the derivation process 13. More specifically, it can be seen that the script is arranged to select two search frames created by the derivation process 13 (identified by their id attributes) and set their delete attributes to "true". This has the effect of deleting those search frames from the created schema. This can be useful where the derivation process has created search frames based upon data in the database which are unlikely to be of use in the generated application 5. Here, for example, search frames based upon the primary key of the Animal record and the primary key of the AddressLine record are deleted. In each of these cases the primary key is a system generated identifier which will have little meaning to a user. As such, a search based upon the primary key will be of little usefulness and it is therefore preferred that such search frames are deleted.

Figure 13 shows another script which is arranged to modify parts of the generated schema. More particularly, the use of identifying elements associated with a record has been described above. Here, additional identifyingltems are added to already created identifyingElements so as to provide more meaningful data to a user of the generated application 5. More specifically, a first part of the script selects the Animal record, and the sole identifyingElements element within the record. Within that identifyingElements element a new identifyingltem element is created which refers to the name item of the Animal record. This allows an Animal record to be identified not only by its primary key (the value of which is likely to have little meaning to a user) but also by its name attribute which is likely to be more meaningful.

A second part of the script of Figure 13 modifies the identifyingElements element of the Employee record. Here, two new identifyingltem elements are created, one referring to the forename item, and one referring to the surname item. Again, this allows an Employee record to be more meaningfully identified in the generated application 5, given that an employee can be identified by their name, rather than by some system generated identifier.

Figure 14A shows a further one of scripts 17 which is applied by the post derivation update process 16. The script of Figure 14A is arranged to create a representation element at the top level of the generated schema. A representation element allows relationships to be defined between a plurality of values and representations of those values. In this case, the created representation element defines relationships between integer values and textual data items. Figure 14B shows the representation element created by the script of Figure 14A.

Figure 14A creates a new representation element and appropriately sets its id and className attributes. A representation element comprises one or more code elements, each code element defining a relationship between a code (specified by a code attribute) and a display value (specified by a value attribute). It can be seen from Figure 14A that the script creates four code elements, each code element defining a relationship between an integer value an a season.

Referring to Figure 14B, it can be seen that a <representation> tag defines the representation element. className and id attributes are set as indicated by the script of Figure 14A. A source attribute identifies that the representation element was created by the script of Figure 14A. Each of the four code elements in the XML of Figure 14B is defined by a <code> tag having code and value attributes having values indicated by the script of Figure 14A. Again, each code element has a source attribute indicating that its creation was caused by the script of Figure 14A.

Representation elements can be useful in the generated application 5, as they allow data stored in one form (in this case as integer values) and representing particular values to be displayed to a user in a more meaningful form as those particular values (in this case seasons of the year).

From the example of Figures 14A and 14B it can be seen that scripts can be used to add functionality to a generated schema. A further example of the addition of functionality is now described with reference to Figures 15A to 15F. In general terms, the scripts of Figures 15A, 15C and 15E are arranged to cause additional items to be added to a particular record and to appropriately set the values of those additional items. More specifically, referring back to Figure 4, it can be seen that the Zoo table 40 stores ticket price data in four fields (ticket_price_1 , ticket_price__2, ticket_price_3 and ticket_price_4). Storing four ticket prices can be useful if, for example, ticket prices vary at different times of a year. It is useful however to allow the generated application 5 to display not only the four stored ticket prices, but to additionally provide further ticket prices based upon the stored ticket prices. In particular, it may be useful to provide a four further ticket prices, each further ticket price being based upon one of the stored ticket prices, but discounted to indicate a discount offered to old age pensioners (referred to as OAPs).

Referring to Figure 15A, a script is shown which is arranged to create a variable element at the top level of the schema. Variables can be used within the schema in the modification of stored data values. The script of Figure 15A sets an identifier of the variable, and provides a textual description. A type variable indicates how a value for the variable is set. Specifically, a type of "systemAssignable" indicates that a variable's value is set by a system administrator (using the generated application 5) and applies throughout the generated application 5. A type of "systemFixed" indicates that a variable's value is defined within the schema. A type of "userAssignable" indicates that a variable's value is again set by a system administrator using the generated application 5, although in this case the variable can have different values for different users of the system.

It can be seen that in this case the variable has a type of systemAssignable indicating that it is set by a system administrator and that the value applies globally within the generated application 5. As is indicated by the textual description, the variable represents a scaling factor used to calculate OAP ticket prices.

Figure 15B shows part of the schema generated by the script of Figure 15A. It can be seen that the variable is defined using a <variable> tag having attributes indicated by the script of Figure 15A. A source attribute indicates that the variable element was created by the script of Figure 15A.

Figure 15C shows a script which modifies the Zoo record (representing the Zoo table 40) to include additional recordltem elements. More particularly, four new recordltem elements are created. Each created recordltem element has an identifier and a local name, and indicates that it is based upon the TicketPrice item element. Figure 15D shows record item elements created within the Zoo record element in the schema by the script of Figure 15C. It can be seen that the script of Figure 15C effectively adds "columns" of data to the Zoo record.

Figure 15E shows a script which is, in general terms, arranged to provide values for the recordltem elements created by the script of Figure 15C. More particularly, each of the created recordltem elements has a value which is determined by multiplying one of the ticket prices stored in the Zoo table 40 (represented by the Zoo record) by the defined variable. In further detail, the script of Figure 15E is arranged to select the singleton set which is generated based upon the Zoo record. Within the definition of the singleton set, a new singleton function is defined which is, generally, arranged to perform the necessary calculation. In more detail, within the singleton function definition a singletonFuntionltem element is created to indicate an item of a record which is to receive the result of the function. In this case, it can be seen that the result of the function is to be provided to the ticket _price_1_oap item (created by the script of Figure 15C) within the Zoo record. A singletonFunctionParam element is also created, to identify a parameter which is to be provided to the function. Here, it can be seen that the parameter is the ticket_price_1 item of the Zoo record, which is referred to as "ticketPriceBase". A singletonFunctionSQL element defines SQL which is arranged to implement the function. Here, it can be seen that the SQL takes the parameter ticketPriceBase and multiplies its value by the variable defined within the schema as shown in Figure 15B. The result it stored in the ticket_price_oap_1 item of the Zoo record.

Other parts of the script of Figure 15E are arranged to perform similar operations in relation to others of the ticket prices stored within the Zoo record, and to store the results in others of the items created by the script of Figure 15C.

Figure 15F shows part of the schema representing the singleton set based upon the Zoo table 40 after modification by the script of Figure 15E. Part of the script of Figure 15E described above is denoted A in Figure 15E, and the corresponding part of the schema is denoted A' in Figure 15F.

It will be appreciated that the methods described above provide considerable flexibility in the generation of the application 5. More particularly, while an application is created based upon the database 2 by the schema extraction process 6 and the derivation process 5, a developer is able to modify the generated application using scripts 10 applied by the post extraction update process 9 and scripts 17 applied by the post derivation update process 16. At all times in the described process, the application is defined by a single XML file, which is input to a particular process, appropriately updated, and then output. As such, at all times a single file exists which defines the generated application 5.

A user interface provided by the generated application 5 based upon the Zoo database of Figure 4 is now described. Figure 16 shows an initial user interface page displayed to a user. It can be seen that a background 75 of the window shown in Figure 16 has a "paw print" design. The background was specified by the wallpaper attribute of the application element as has been described above with reference to Figure 11. To use the generated application 5 to obtain access to the database 2, a user selects a start button 76, which causes display of a start window 77 shown in Figure 17. A searches tab 78 provides a list of all search frames defined within the schema which can be used to carry out searches on the database 2. A search frame can be selected from the searches tab 78 and a tick button 79 can be used to cause display of that search frame. Selection of a "Employee by Ni No, Forename & Surname" search frame 80 causes display of a search frame shown in Figure 18.

Referring to Figure 18, an area 81 allows a user to specify values for parameters on which the search is to be based. More specifically, a text box 82 is used to enter a value for an "Ni No" field. A drop down list 83 allows a user to specify a relationship which is to be satisfied between the value of the "Ni No" field and the value entered in the text box 82. Similarly, a text box 84 is used to input a value for the "Forename" field, and a drop down list 85 allows specification of a relationship between stored values and the value entered in the text box 84. A text box 86 is used to enter a value which is to be used as a basis for a surname search, while a drop down list 87 again allows specification of the relationship which is to be satisfied.

When appropriate values have been entered in the text boxes 82, 84, 86, and appropriate relationships have been indicated by the drop down lists 83, 85, 87, a search button 88 is selected to cause a search to be executed, with search results being displayed in an area 89. It can be seen that a pair of radio buttons 90 allows a user to select between "Filter" and "Position" options. Given that the "Filter" option is selected, the search results returned in the area 89 are records which satisfy all criteria specified in the area 81.

When the "Position" option is selected the relationship in each of the drop down lists 83, 85 & 97 is set to either ">=" or "<=" depending on which of "Forward" and "Backward" radio buttons 91 is selected. The relationship in the drop down lists 83, 85, 97 cannot be amended whilst the "Position" option is selected. The values entered in the text boxes 82, 84, 86 are used to provide a starting position for the search results returned on selecting the search button 88. In effect the search criteria are only applied to the first row to be returned and all subsequent rows are returned either on selection of the search button 88 or by subsequent selection of paging buttons 93 (described below). When the "Position" option is selected, should any text boxes be left without a value then all subsequent text boxes will have no effect.

The search results displayed in the area 89 are ordered based upon a key associated with the search frame. The nature of the ordering (i.e. ascending or descending) can be controlled using a pair of radio buttons 91. The number of search results displayed in the area 89 is controlled by a value entered in a text box 92. Paging buttons 93 can be used to move forwards and backwards through pages of search results. A clear button 94 allows all data entered in the area 81 to be deleted, while a reset button 95 allows search parameters to be reset to those which were applied to the last search which was executed.

Figure 19 shows a detail frame which is used to display data relating to one of the search results displayed in the area 89. The detail frame comprises three parts: a banner panel 96 displaying information which identifies the data being displayed, a plurality of tabs 97, each tab being represented by a detail panel, and a button area 98 providing navigation functionality.

Various administration features provided by the generated application 5 are now described. It can be seen in Figure 16 that the user interface provides a menu bar comprising a plurality of menus. A security menu is shown in Figure 20.

It has been described above that different users of the generated application 5 may have different privileges, and that these privileges determine the way in which particular users can use the generated application 5. Administrator functionality to manage the allocation of privileges is provided by the security menu of Figure 20 as is now described. Selecting a "Privileges" item from the Security menu shown in Figure 20 causes display of a privileges dialog shown in Figure 21. A privileges tab 104 provides details of all privileges defined within the schema used to generated the application.

Privileges are allocated to privilege roles, and particular users are associated with one or more privilege roles. A user's access to the generated application 5 is determined by the privilege roles with which it is associated, and more particularly the privileges which are allocated to those privilege roles.

Details of currently defined privilege roles can be viewed in a privilege roles tab 105 which is shown in Figure 22. In order to amend privileges allocated to a particular privilege role, a privilege role is selected and an edit button 106 is selected, causing display of an Assign Privileges dialog shown in Figure 23. The Assign Privileges dialog comprises a list 107 showing all defined privileges, and a list 108 showing all privileges associated with the selected privilege role. Privileges can be added to or removed from a privilege role using a pair of buttons 109. If a user wishes to confirm an assignment of privileges, a confirm button 110 is selected. A reset button 111 and a cancel button 112 are also provided.

The user interface of the generated application 5 also provides functionality allowing particular privilege roles to be associated with a particular user. The use of variables within a schema has been described above. Functionality allowing values to be assigned to variables is now described. It can be seen that the Security menu of Figure 20 includes a Variables option. Selection of the Variables option causes display of a Variables dialog shown in Figure 24 which lists all variables defined within the schema.

One of the defined variables can be selected, and an edit button 112 can be used to display a dialog shown in Figure 25 which allows a value for the attribute to be specified. The specified value is confirmed using a confirm button 113. A reset button 114 and a cancel button 115 are also provided.

Referring back to Figure 24, it will be recalled above that it was described that variables can either be system wide or vary for different users. The variables shown in Figure 24 are within a system variables tab, and are therefore system wide variables. Variables which are defined differently for different users are defined within a user variables tab 117. Users are assigned to user variable roles, and user variables have values which differ between user variable roles.

The preceding description has explained how the described methods can be used to generate an application allowing access to a database. It will be appreciated that the described schema can include various functionality allowing the generated application to be suitably defined, and in different embodiments of the invention different functionality is provided.

Figures 26A to 26D show all elements which can be provided within a schema of the type used in the examples set out above. Each element is defined by a respective tag and comprises a plurality of attributes. The attributes associated with a particular elements are shown in Annex 1. Attributes associated with particular elements are indicated to be optional or mandatory, depending upon whether they must be specified within the definition of a particular element. It can also be noted that some attributes are indicated to be transient. Such attributes are not written to the schema file itself, but rather affect how the schema is generated. Attributes which are indicated to be translatable are textual attributes whose can be translated from one natural language to another.

It has been explained above that various elements of the schema include className attributes indicating classes which should be used to represent those elements in the generated application 5. The processing of the schema to generate the application 5 is now described with reference to Figure 27.

The seventh pass schema 25 is input to the generate Java source process 27 together with a number of template files 118. In one embodiment the generate Java source process uses JXP software and in such a case the template files 118 are written in compliance with the JXP software. It will however be appreciated that the generate Java source process 27 and the template files used by the Java source process 27 can take any suitable form.

The template files 118 are processed to extract information from the schema and merge this with embedded java code within the template files so as to generate the Java source code of the classes that, along with library classes and other third party classes, comprise the source code of the generated application. Typically , each Java class 120 which is generated is a subclass of a class in a set of standard classes 119. Each template Java class definition provides functionality to implement particular elements of the schema in the generated application. For example, a particular template class definition will be provided to provide the functionality of a record element (and one or more of its sub elements) and so on.

In some embodiments of the invention, the schema may specify a user created class which a class created using the processing described above should extend (that is a user created class of which the case class created using the processing described above should be a subclass). This can be achieved by using suitable attributes with the schema. An example user created class 121 is shown in Figure 27. It can be seen that the user created class 121 is itself a subclass of one of the standard classes 119, and one of the created classes 120 is, in turn, a sub class of the user created class 121.

In some embodiments of the invention, the schema may specify a user created class 123 which extends one of the classes 120 created using the processing described above and is used in preference to the extended class at run-time. This can be achieved by using suitable attributes with the schema.

It has been described above, particularly with reference to Figure 3, that the described processing takes as input a relational database 2. In order to allow the processing of Figure 3 to properly function, without recourse to defining any relationships within the database using script files (10 and 18), the relational database 2 should be properly defined: for example each table within the database 2 should have a primary key. All foreign keys should have a properly identifiable target and so on. In order to ensure that the database 2 is indeed properly defined, a data structure tool can be used to interrogate the database 2 and obtain information as to its structure and integrity.

For example, the data structure tool can provide to a user details of tables having no primary key, identifying columns or combinations of columns which could provide a primary key, and provide to a user, through a user interface, a mechanism for setting that primary key on the database. Similarly, where the target of a foreign key cannot be located, the data structure tool can be used to locate the target, and data indicating the identified target can then be written to the database. In this way, the data structure tool provides a mechanism whereby problems with the database 2 can be identified, and resolved, thereby allowing the processing of Figure 3 to operate correctly.

An example implementation of an embodiment of the invention is shown in figure 28. Here the application 5 operates over a network 130. The generated application 5 comprises client components 131 , which run on a client computer 132, and server components 133, which run on a server computer 134. The server components 133 interact with the database 2, for which the application 5 has been generated as described above, and with an administration database

135. The administration database 135 contains administration data which is used by the server components 133 in operation. The administration database 135 is held on the same data server which holds the application database 2, though it will be appreciated that the administration database 135 may readily be implemented on any appropriate data server provided that it is accessible by the server components 133.

The server components 133 are made available to the network 130 by a web server application

136, such as an Apache Tomcat web server; the web server 136 running on the server computer 134 so as to provide the server components 133 with a network-visible uniform resource locator (URL). The client components 131 are initially stored on the server computer 134 and are downloaded to the client computer 132 before being run on the client computer 132. The client components 131 then communicate with the server components via the URL associated with the server components. The client components 131 present a user interface to a user of the client computer 132 so as to allow the user to view and manipulate data from the application database 2, which has been provided to the client components 131 by the server components 133.

It will be appreciated that, when deploying the application 5, the application database 2 and the administration database 135 should already exist, the web server 136 should be installed and it should include the appropriate JDBC drivers for access to both the administration database 135 and the application database 2.

The process for deploying the application 5 is now described with reference to Figure 29. In general terms, configuration files are created in an application directory (step S10) which are used by an automated build program to create source directories (including a build directory) within the application directory (step S11 ), generate Java byte code for application 5 in the build directory (step S12), create the administration database 135 (step S13), generate standard users for the application 5 within the administration database 135 (step S14), generate a package containing all of the files in the build directory to be deployed on the server computer 134 (step S15) and supply the package to the web server for deployment (step S16).

The web server 136 is capable of deploying the application 5 in the form of a web archive (WAR) file, which contains configuration files and Java code in the form of Java Archive (JAR) files. Thus, the deployment of the application 5 generally involves creating the WAR file and making it available to the web server 136. Such a process is generally performed using a build program such as "make" or, in the case of Java, Apache ant.

In particular, at step S10, configuration files are created for the build program. Build programs such as "make" or "Apache ant" comprise a standard program which is configured to build an individual application using configuration files which are created and edited by a user of the system to provide information to the build program about, for example, the structure of the application and any application dependencies. In the remainder of the description Apache ant is used as an example build program, though it will be appreciated that any appropriate build program may be used.

In order to configure Apache ant to build the application 5 configuration files are required, including a 'build. xml' file and a number of .properties files. The build. xml file defines a number of 'target's for building the application. Each target comprises a number of tasks which are performed when the target is run. Example tasks include copying files, creating database entries, editing config files, running other targets. The property files are all in the format of text files containing multiple lines of the simple format 'key = value'.

A sample list of files, which are created within the application directory of the application 5 during the deployment process, is as follows: config/coπfifg.compufer/build. properties

config/con/yg.d/j/build. properties

config/conf/g.ctef/build. properties

source/config/schema.selectTables

build. dependencies

build. properties

build. xml where config.computer is a name selected for the computer upon which the application 5 is generated; config.db is a name for the application database 2; and config.dst is a name for the data structure tool (in the event that such a tool is being used).

The "config.computer/buM. properties" file is used to identify where the framework and third party software is located and where the web server installation is located. The "config.dbfbu\ Id. properties" file includes details of the address of both the application database 2 and the administration database 135 as follows: database, location. administration=

database, location. application=

The "con/irgf.db/build. properties" file also provides usernames and passwords to be used to access the databases 2, 135. For example, the following properties give a database username (together with its password) that will own the administration tables to be created in the administration database: database. user.administration.owner=

database. password.administration.owner=

The "COnZUSf-O ¹ SfZbUiId. properties" file includes properties relating to the data structure tool, such as where the metadata database for the data structure tool is located and the username and password for accessing the database.

The schema. selectTables property file contains a list of tables in the application database 2 which should not be considered when building the application 5. That is, the tables listed in the file should be excluded from consideration when generating the schema, as described above. This is useful in the event that selected tables within the application database no longer contain valid or useful information and are not therefore suitable for inclusion in the application 5.

The build. dependencies file includes references to the location of software upon which the build depends but which are not within the scope of the build, for example, it includes references to the location of appropriate JDBC drivers for the databases 2,135.

The build. properties file (in the root of the application directory) gives general information about the application 5 to be used when generating the application 5. The build. xml file also uses specific variable names whose values are specified externally; these can be specified within a file called datanovata. properties in the designated home directory of the user or within a file called overrides. properties within the same directory as the build.xml file. These variables contain the specific names of the directories "config. computer", "config.db" and "config. dsf that are used to set necessary configuration property values. Thus, the build.xml file ties together the above property files into a single configuration structure from which the application can be generated and deployed.

Once the configuration files have been configured, ant targets defined within the build.xml file are executed so as to generate and deploy the application 5. At step S11 , a target 'init.create_source_directories' is run to create the following directory structure within the application directory: source\java\dbExtract\src

source\schema\350-postDerivationUpdate

source\schema\150-postExtractionllpdate

source\schema\i 18n

source\schema\config

source\java\src

source\java\res

source\sql

Further directories within the directory structure used are: build

build/class

build/web

config

docs

generated

generated/doc

generated/java

generated/java/factory

generated/java/res

generated/src

generated/schema

generated/sql

generated/wizard Once the application 5 has been built, the build directory will contain all files required for the deployment of the application. The config directory contains initial files required to start building the application 5. The docs directory contains any bespoke documents for the application 5. The generated directory contains intermediate files created by the application generation processes. The source directory contains all bespoke source files for the application 5. This includes the schema update scripts and resource files, including multi-language translation files.

At step S13, 'init.create_administration_database' creates the administration database tables by connecting to the database as 'database. user.administration. owner'. Exemplary administration tables created as standard include:

AuditTrail - historical login details;

Bookmark - details to enable direct navigation to a specific element of the database;

DataSource - the list of available tomcat data sources that can be assigned to a user;

DsComparisons - data security comparison information;

DsDataRoles - data security role;

DsRecordPaths - data security hierarchical record paths;

DsRecordRules - data security rules for each record;

DsRules - data security rules for each item;

DsUserDataRoles - links a user to a data security role;

Role - privilege roles as described above with reference to the schema;

RolePrivilege - relationship between roles and privileges;

SecurityUser - users' login details;

System Parameters - the name-value pairs of system parameters;

SystemStatus - the state of the service (open, suspended, closed etc).

UserPreference - preferences for each user;

UserVariableRole - links each user to variable roles;

VariableRole - the id and description of each variable role;

VariableRoleVariable - the variables assigned to each variable role;

VariableSystemValue - the value of each system variable; and

VariableValue - the value of variables assigned to each variable role.

At step S14, 'init.create_administration_database_users'. creates the required users for the administration database. This will generate an SQL script to create the necessary users and assign to them the minimum privileges required for working with the administration database. The script will also generate an SQL script necessary to create an application user that has sufficient read-only privileges in the application database. The above steps (S10 to S13) relate to the web configuration generation process 33 (Figure 3). Once this is completed, the application 5 is generated (step S12) as described above by generating a (seventh pass) schema 25 representing the application and generating Java source files from the schema 25. The Java source files are compiled into JAR files of Java byte code in the build directory. The build directory including all of the JAR files and configuration files which are dependent on the web-server to be used to deploy the application, is then packaged up into a web archive (WAR) file (step S15). This WAR file is then supplied to the web server 136. In the case of a Tomcat server, it is sufficient to place the WAR file into the "webapps" directory of the server. The Tomcat server then "deploys" the WAR file by generating the structures necessary to allow a client computer connected to the Tomcat server to access the application. This is commonly achieved by assigning the application a port number on the Tomcat server, giving the application 5 a URL by which it can be remotely accessed by a client.

In this exemplary embodiment, a user accesses the deployed application using Java WebStart. Thus, the client components 131 of the deployed application (including JAR files used to display the client user interface) are packaged into a JNLP (standard Jave Web Start application) package by the web server 136 on the server computer 134 ready for download by the client computer 132. When a user of the client computer 132 wishes to use the application 5, the "javaws" program is executed on the client computer 132, taking the URL of the application 5 as a parameter. The javaws program checks the version of the client components 131 available on the server computer 134 against any version of the client components 131 which is already available at the client computer 132. If a newer version of the client components 131 are available on the server computer 134 (or if no version at all exists on the client computer 132) then the javaws program will download the most recent version of the client components 131 to the client computer 132. The client components 131 are then started by the javaws program. It will be appreciated that Java WebStart is merely one of a plurality of possible means by which the client components 131 may be distributed to the client computer 132.

In an alternative embodiment, as described in detail below, more than one application, generated in accordance with the method described above, is implemented on the same network in order to allow client computers to access more than one database. Each generated application has associated administration data and at least some of the administration data is managed centrally by a gateway application. As shown in Figure 30, a first application 137 and a second application 138 are generated using the processing described above. The first and second applications 137, 138 operate with reference respectively to first and second administration data 139, 140. Each of the first and second administration data 139, 140 performs the functions described above with reference to the administration data held in the administration database 135 (Figure 28). The first and second administration data 139, 140 are preferably stored in databases (not shown) associated respectively with the first and second applications 137, 138.

The first and second applications 137, 138 operate in the manner described above in relation to the generated application 5, differing only in that the first and second applications 137, 138 are configured to operate with reference to additional common administration data 141 which the applications 137, 138 access via a gateway application 142. The gateway application 142 additionally provides administration functionality for the common administration data 141.

The common administration data 141 , managed by the gateway application 142, includes user names, links (such as URLs) for applications associated with each user name, common roles (i.e. roles such as "developer" which may apply across more than one application) password length, password pattern, password expiry, password reuse and expiry dates, inactive period before expiry, number of password retries etc. The use of common administration data 141 provides an advantage in that there is a reduced need to store duplicate data as part of the first and second administration data 139, 140. Indeed, storage of administration data which is common to a plurality of applications as part of the common administration data 141 eases maintainability of the administration data.

Username and password combinations are stored as part of the first or second administration data 139, 140. Thus, a user may access the first and second applications 137, 138 in the same way as the generated application 5.

A user of the client computer 132 may access the gateway application 142 via the network 130 and launch the first and second applications 137, 138 through the gateway application 142. In this case, the user provides a username to the gateway application 142 and in response the gateway application user interface displays links to each of the applications 137, 138 the user has permissions to access. By selecting one of these links, the user launches the corresponding application 137, 138, at which time they log into the application 137, 138 by providing their password for authentication. This method of accessing the applications 137, 138 is advantageous in that the gateway provides a central user interface through which to access multiple applications 137, 138 and gives the user an indication of the applications to which they have access. A user who has privileges to perform administration tasks at the gateway application 142 may provide a usemame and password to the gateway application 142 itself. When such a user has been authenticated by the gateway application 142 and has been provided with a user interface by the gateway application 142, they may alter the common administration data 141 through the user interface. Some administration users may have permissions which allow them only to alter only particular administration data, whilst other users have sufficient permissions to allow them to alter more of the administration data. For example, some system administrators may use the gateway application 142 to create new user accounts and to allocate particular roles to particular user accounts.

In order for the gateway application 142 to interact with the first and second applications 137, 138 efficiently to administer roles associated with particular applications 137, 138, the first and second applications 137, 138, collate sets of roles, such as the variable roles, data roles or privilege roles described above, into one or more "application roles". That is, each application 137, 138 defines at least one application role and each application role is indicative of a set of one or more particular roles within the application 137, 138. When an administration user wishes to change the application roles associated with a user, the gateway application 142 interrogates the first and second applications 137, 138 and obtains a list of application roles available in each application 137, 138. The gateway application 142 may then be used to associate particular application roles with a particular user, the list of application roles associated with the user being stored in the common administration database 141. This method of administering roles through the gateway application 142 is advantageous in that the particular role set in an application role may be altered within an application 137, 138 without informing the gateway application 142 of the change. This allows the gateway application 142 to administer the allocation of roles to users of the applications 137, 138 without the need for the gateway application 142 to change as a consequence of a change in the roles within an application 137, 138. Moreover, a common application role, such as "developer" can be instantiated as different sets of roles for each application 137, 138 while presenting a uniform name, i.e. "developer", across all applications 137, 138.

It will be appreciated that the use of the gateway application 142, and the storage of data, such as the application role data described above, which is common to a plurality of applications as part of the common administration data 141 eases system maintainability.

The application generation processes described above may provide a generated application comprising all of the functionality of the application 5 described above, and further comprising functionality to allow a user of the application to add additional information, such as textual descriptions or notes, to rows in the database 2. This is advantageous in that, amongst other things, additional information which is relevant to a user of the database 2 may be added to any table of the database 2 for which notes are configured in a standard format, without the need to restructure any of the existing tables or conform to any of the existing table formats.

In general terms, notes take the form of a "subject" containing a short description of the subject of the note, and a "body" containing the main text of the note. The notes are preferably stored in an additional notes table within the database 2.

Each row in the notes table represents a note, and comprises a primary key attribute, which uniquely identifies the row from all other rows in the notes table, a "subject" text attribute and a "body" text attribute. A corresponding link table is provided for each table in the database 2 for which notes functionality is available, in order to link rows of a particular table to one or more rows in the notes table. Thus, for a given database table A with notes functionality, a link table A' is created. Each row in link table A' represents a link between a row in table A and a row, representing a note, in the notes table. As such, a given row of the link table comprises an attribute corresponding to the primary key attribute of a row in table A and an attribute corresponding to the primary key attribute of a note in the notes table, the note represented by the row in the notes table being attached to the row in table A. Accordingly, for each row in table A it is possible to use link table A' to find all notes attached to that row by performing a join between table A, link table A' and the notes table. Furthermore, for a given row in the notes table, it is possible to find all of the rows in the database 2 to which that note is attached by searching all of the link tables in the database 2 in turn.

The generated application provides functionality to add, delete, amend and search notes. A user of the application is able to search for rows in a particular table (the functionality for which is already available according to the method described above) using the contents of notes attached to the rows of the table as part of the search criteria. Additionally, the user may search the notes which are attached to the system irrespective of the row or table to which the notes are attached. Functionality is provided which allows the user to find any rows to which a note is attached from the note itself.

In order to support the addition of notes to a generated application, the application generation process is arranged to allow a developer to specify which tables are to have notes associated with them at runtime. Additionally where a table is to support the use of notes, the generation process may limit user permissions in terms of which users can add notes, and the nature of the notes that can be added. The notes functionality described above can be added to the generated application for an application table in the database 2 by adding an attribute to the record element indicating that notes functionality should be activated, and by adding one or more attributes indicating the role or roles which may add, remove or view the notes. An additional process runs which, for each record element having the notes attribute, adds data required to allow searching of the notes, including the addition of openSet elements and searchFrame elements as described above. Each of the added schema elements is configured to implement the same role-based access restriction described above in relation to the generated application 5, based upon the information in the notes role attributes added to the record elements.

The additional process is also arranged to generate SQL which, when executed on the database 2, creates the notes table and each of the link tables.

It will be appreciated that the visibility and/or editability of notes to various users can be controlled using user privilege roles as described above.

It will be appreciated that, once generated, the application of the present embodiment functions substantially in the same manner as the generated application 5, with the addition of functionality which allows a user to attach a note to a row of data in the database, and subsequently search for and view that row, and the attached note, based upon search criteria relating to the row or the note.

Although various embodiments have been described above, it will be appreciated that various modifications can be made to the described embodiments without departing from the spirit and scope of the invention. In particular, it will be appreciated that references to particular implementing technologies (e.g. Java) are merely exemplary, and that other implementing technologies can be used in other embodiments. Similarly, while access to the database 2 using JDBC has been described above, it will be appreciated that the database 2 can be accessed in any suitable way. It will further be appreciated that although the embodiments have been described in the context of relational databases, the methods described herein can be applied to other data stores, particularly those which can be converted into a relational form for the purposes of the processing described above.

CS

O O

O CS

w

O H U

Sh

CN

CS

O

O CS

O

CS

O O

O CS

w

O H U

Sh

CS

O

O CS

O

CS

O

O

O CS

w

O H U

Sh

O

O

CS

O O

O CS

w

O H U

Sh

O <hie rarchicalFunction>

CS

O O

O CS

w O H U

Sh

IO

⁽ D

CS

O

O CS

O

parent

CS

O O

O CS

w

O H U

Sh

£

O

source | Optional | Information attribute used to indicate where the tag was generated

<detallPos!tioπEmbeddedSet>

Parents I <detaιlSelectιon>

The embedded set to which before and 'after ¹ values of the position attribute of detailSelection refers delete Transient If this is set to true this tag and all its children will be deleted from the schema

Must be a recognisable boolean value

deleteReason Transient The reason this element is flagged for deletion

<cdetallPosKlonKemMatrix>

Parents | <detaιlSelectιon>

An itemMat™ within a record within a set to which 'before' and 'alter' values of the position attnbute of

the lag was generated I

O