WO2004046962A2

WO2004046962A2 - Database management

Info

Publication number: WO2004046962A2
Application number: PCT/GB2003/004999
Authority: WO
Inventors: John Cooper; Simon Purdy; Benjamin King
Original assignee: Active Limited
Priority date: 2002-11-18
Filing date: 2003-11-18
Publication date: 2004-06-03
Also published as: AU2003302055A1; WO2004046962A3; GB0226919D0

Abstract

Apparatus for managing a database which can be configured by a server requiring input of one or more programming commands, the apparatus comprising means for receiving one or more user commands and means for converting said one or more user commands into corresponding programming commands for input into said server for configuration of said database.

Description

Database Management

This invention relates to database management and, more particularly, to the management of a database which requires input of programming code script (i.e. one or more programming commands) for configuration.

In recent years, it has become more and more common for companies to use a database structure to manage their key items, such as contacts and customers. For example, one of the most popular and widely-used databases in current use is the Microsoft ( TM) SQL or "Sequel" server database, which provides powerful enterprise management functions, which enable the database to be searched in relation to various criteria and enable reports to be generated accordingly. Other, similarly useful database management packages also exist, such as "Oracle" and "Access".

However, in order to configure the database server to perform these functions, for example, in the case of the SQL server database referred to above, it is necessary to create an SQL script comprising a number of commands in SQL programming code and input this script into the server. Obviously, this requires the user to be proficient in SQL programming, whereas the expert in enterprise management may not necessarily be familiar with SQL programming. Because of the complexity of the configuration process, it can take a lot of time and effort to configure the database, as required, and once it is done, it is equally complex and time-consuming to change the configuration.

We have now devised an arrangement which overcomes these problems.

In accordance with the present invention, there is provided apparatus for managing a database which can be configured by a server requiring input of one or more programming commands, the apparatus comprising means for receiving one or more user commands and means for converting said one or more user commands into corresponding programming commands for input into said server for configuration of said database. Thus, the present invention provides a user-friendly interface between a user and, for example, a Sequel server database, which converts simple user commands into SQL commands for configuring the database as required. As a result, the complexity of the configuration process is significantly reduced, as is the length of time it takes to perform.

In one preferred embodiment of the invention, the apparatus includes means for enabling a user to create one or more searches in respect of the data stored in the database according to one or more criteria, which criteria are presented to the user in a simple, user-friendly format. Once the search has been created, the apparatus converts it into SQL script for input to the server. The apparatus preferably also includes means for enabling a user to generate one or more reports of the search(es), in any required format, again being arranged to present the various options to the user in a simple, user-friendly format and for converting the selected combination of options or commands into SQL script for input to the server.

In a preferred embodiment, the apparatus comprises a core module for controlling configuration and management of said database. The core module preferably comprises a plurality of operation layers, more preferably at least three operation layers. The three layers preferably comprise an upper or presentation layer, a middle or system management layer, and a bottom or data encapsulating layer. The presentation layer is beneficially arranged to receive the user commands for defining the presentation format of information displayed by the system. In a preferred embodiment, all communication between the layers of the core module is in the form of packaged objects (as defined in terms of object orientated programming techniques). Thus, preferably, the presentation layer is arranged also to package the user commands into packages for propagation to the database, via the middle layer.

The middle layer is preferably arranged to receive user commands for creating and formatting database tables and fields and or creating searches and reports based on data stored in the database. The middle layer may also be arranged to receive user commands defining business rules, i.e. defining rules relating data management of the system, without any requirement of the programming language of the database server or other programming language. Using these user configured pre-defined business rules, this middle layer preferably also manages data objects passing in both , directions through the system.

The bottom or database encapsulation layer beneficially defines a wrapper around an underlying relational database management system (RDBMS), which layer is preferably arranged to configure the programming code requirements necessary to interact with the underlying server database.

In the case of the system architecture described above, the system can be configured to configure and manage any type of underlying server database simply by reconfiguring the database encapsulation layer surrounding it - the structure of the presentation and middle layers is effectively universal.

These and other aspects of the present invention will be apparent from, and elucidated with reference to the embodiments described herein.

Embodiments of the present invention will now be described by way of examples only and with reference to the accompanying drawings:

Figure 1 is a schematic block diagram of apparatus according to an exemplary embodiment of the invention;

Figure 2 is a schematic illustration of a pair of entities and their properties;

In an exemplary embodiment of the invention, referring to Figure 1 of the drawings, there is provided an Activity Manager Configuration (hereinafter referred to as "AMC") module which is the core module for controlling system configuration and data management within all system applications and the AMC file becomes the starting point of any project development within the structure of the AMC as follows.

The definition of the prompts and fields within the AMC module can be stored either as:

• ".screen" files • A table within an SQL database

• A mixture of the two so that tailored methods of form display are provided for certain customers.

The AMC module works at three levels within the relevant application as illustrated in Figure 1.

• The Upper or Presentation Layer which allows a user to create, define and modify all browser accessed screens within the application. All screens and forms visible to the user throughout the application are defined as '.screen' files. This layer also packages all data requests into Objects' for propagation to the database and unpackages the responses.

• The Middle or System Management Layer is where database tables and fields can be created and formatted, searches and reports created, and business rules defined by the user without any requirement for SQL or other programming knowledge. Using these user configured pre-defined business rules this layer manages the objects passing in both directions.

• AMC Bottom Layer - The Database Encapsulation Layer (DEL). The DEL is the wrapper around the underlying Relational Database Management System (RDBMS) which configures the code requirements necessary to interact with the underlying database. In the schematic illustration of Figure 1, the RDBMS is illustrated as the Microsoft SQL server. However, it will be appreciated that the DEL is capable of reconfiguration to work with any other relational database, SQL or otherwise.

The upper or presentation layer allows a user to create, define and modify all browser accessed screens within the application. All screens and forms visible to the user throughout the application are defined as '.screen' files. This layer also packages all data requests into Objects for propagation to the database and unpackages the responses. In the production of forms, almost without exception, application developers define data entry in the following way, where the HTML table is used to define the basic form layout as:

The production of views (cross sections of data) are shown in a similar way:

In the following the production of forms and views using a core include script file to be used within ASP pages will be described in more detail.

Screen' File Definition and Specification

Description

The screen definition file contains instructions relating to how an individual screen appears on the user's system. Screen definition files in this exemplary embodiment are XML files located on the server as part of the instance configuration settings (individual to an occurrence). There are several different types of screen definition files, each dedicated to a specific part of the screen definition. • "screen"fϊles

Specifies what appears on the screen • "menu"files

Specifies menu contents for drop down menus etc. Useful for occasions when a single menu appears as part of multiple screens.

• "fieldgroup'Tiles:

Allows sets of fields to be specified outside of a specific screen for use in multiple screens where information displayed needs to be constant.

Further types may be required for certain applications, but for the rest of this description, the "screen" file will be primarily referred to.

Structure

The screen definition files are divided into 3 discrete sections.

Fieldgroups

This section is split into multiple fieldgroup sections which contain information relating to what fields are displayed.

Each fieldgroup section lists all of the fields which are part of the fieldgroup along with all the parameters required. Most of the properties for the fields will be derived from the database (such as the options in a list box, validation rules for numbers, dates, strings and other data type along with the standard prompt). It is likely that there will be a degree of inheritance between these properties where some of the properties from the database can be overwritten (on a screen by screen basis) by the properties in the .screen file.

Eventscreen

This section defines how the screen is displayed by the parser in this exemplary embodiment. The language for this eventscreen is a markup language based on HTML, but abstracted away to allow for ease in porting the parser to new platforms. Functions for some of the existing simple HTML layout functions like the <table> tag will exist in this markup language, however the intention is that complex user interface components such as a tabbed interface can be defined via a simple set of tags without the need to know or understand the complex HTML and JavaScript required to code this for the browser. For example:

<tabs>

<tab>contents</tab> </tabs>

Development of this language can be fairly evolutionary in the sense that new features and tags can be added during development when existing user interface components do not meet requirements.

Eventcomplete

The eventcomplete node is used to define what should occur if a particular screen is sent back to the server (in case of saving to the database). This section, when not contained in the file informs the parser that a method of submitting content back to the server is not required (so for the straight HTML client, the submit button is not generated. There are several options for handling the eventcomplete section:

• redirecting from the page to another

• closing the window created for the screen

• refreshing the base window (the window which created the screen - window.opener) and closing the window

• displaying a full screen as in eventscreen.

Where the full tree is used in eventcomplete, the format is exactly the same as the eventscreen section, however it is envisaged that the eventcomplete section will be used solely for displaying a simple confirmation message for the user, along with a next action link (closing window or moving onto a different screen).

An eventfailed section will be used for displaying messages that occur when a database update request does not succeed. Reports

Reports can be maintained by users who have some familiarity with report generation applications. The basis for this must be a prepared search. Searches available will be determined by:

• The user, or

• The group to which the user belongs

The user is able to choose (from the selected search) which columns to include in the report. Aggregation can be specified for any column (including totalling for numeric columns) The program is then be able to determine the remaining columns required for the GROUP BY clause, from which the user may specify the sequence (ORDER BY clause). When the complete SQL statement is assembled, it can be 'dry run' to be confirmed by the user.

Middle or System Management Layer

The Middle or System Management Layer is responsible for handling all data in its entity from, and, is where database tables and fields can be created and formatted, searches and reports created, and business rules defined by the user without any requirement for SQL or other programming knowledge. Using these user configured pre-defined business rules, this layer manages the objects passing in both directions.

• Search o Sub-Graph traversal

Algorithms to deal with traversal of sub-graphs, along with loop protection. Allows navigation of system by UDF relations o Linear-Property match

Direct property table searching, through DEL, for more rapid simple searches.

^■ Searching across multiple fields (name, address etc)

• Reports

• Data Caching Keeping a store of entities to reduce DEL load, and improve system performance. o Keeping track of the recently loaded entities to reduce DEL calls o Management

• User access management o Interaction with DEL o VADER controls

• General System configuration o Paths o ODBC link(s)

• Licensing

Provides control over the number of users the system can have, either per- seat or concurrent. o System Level licence control o Connection Count licence control

• Business Rules

Allows system to adapt to different uses, such as file storage, or bespoke projects. o Property requirements for entities

Which properties of an entity are requirements, and what to do if they are unfulfilled, o Inter-Entity Relationship Rules

Control over data parentage, such as contact/company. Allows sections such as project management to enforce hierarchy in the graph EAN environment, o Identifying the important entities

Which entities can we report on, when to propagate deletions.

• Expansion o User API

^■ Allows controlled access to underlying Entity Object Model

User expandability in the system, o Active API

■ Everything in User API ^■ Allow direct interaction to DEL

^■ Permits modular design add-ons

• Project

• Helpdesk

• State Management o Tracking the users' position in the system

■ Pre-emptive caching (eventually) o Working Set(s)

• Inter-User Messaging o Note exchange

• Data import and export o Allows legacy records to be imported into the system.

In more detail:

Searches can be maintained by users to create effective results. A dedicated module should be provided for these users to define and test their output. Selections are allowed from any data dictionary item to assemble:

• the select clause

• the joins

• the where clauses

The AMC is capable of keeping track of the columns required for the select statement, from which the primary table can be used for the FROM clause. Data dictionary token names are used to uniquely identify table and column names for statement assembly. The program must identify appropriate column names from this table list to make decisions about JOIN clauses if more than one table is specified. Optional token filters against a specific value (or range of values) will be used to generate the WHERE clause. When the complete SQL statement is assembled, it can be "dry run" to be confirmed by the user.

Search parameters should be saved for:

A specified user, and/or

A specified group of users, and/or A specified application module.

Searching is one of the important tasks of the middle layer. There are two types of searching in the system according to this exemplary embodiment of the invention. The first is a simple parameter value search which will match entities with certain parameters from anywhere in the database (with restrictions on entity ownership). The other more sophisticated search strategy involves traversal of sub-graphs of the database. A sub-graph is a collection of entities which are linked by one or more types of relation. For example, companies which have worked together in the past would form a sub-graph, as they would all have been connected by the "worked with" relation. One of the downsides is that searching through sub-graphs requires a number of checks to avoid problems like endless looping. But the flexibility of this search method outweighs its downsides. "Tricks" can also be used to improve the search times for entity traversal, such as checking to make sure that nodes are connected before attempting to link to them in the search. Also connected directly to searches are system reports. These will be integrated with a search and the results will be formatted according to user rules at the presentation layer.

The middle layer is also responsible for caching of entities to improve system performance. The caching process will involve keeping recently accessed entities and their properties in memory for a period after they've been accessed. This improves upon a simple generic cache because a certain amount of pre-empting can be done. For example, if we load one entity, say a company, we can also load the contacts and other entities directly related to that company entity. This means that user traversal of the graph will be faster, as we require fewer calls to the DEL.

The system API is also located in the middle layer. This has two levels: one for the user and third parties to write expansion modules to connect to the system, and the other for core components to connect to the system, written by the development team. Things that will be included here will be extensions to the system for bespoke applications. There will also be a core extension to handle data import and export from the system: this will allow the system to interact with other legacy systems. It also allow for a modular design for the primary implementation, so that extra functions can be added to the system in modules. Any application module would benefit from the results of saved searches, so generic routines will need to retrieve data for use within the current module. All the modules to which searching features will apply are to identified. The features will be enabled when:

The user, or

The user's group, or

The module being used owns at least one saved search.

The purposes to which the results could be put will depend upon the context of the module. This will be covered in more detail in each function's specifications, but examples are global editing of customer information based on a search list, an email shot from an extracted search, or maybe just a simple phone directory listing. All that is required is a single dropdown selection of allowed searches at the appropriate opportunity.

Tables will ultimately be maintained through the following features:

Users will be able to add or delete a table or a field. Standard database routines will be responsible for placing the field in the correct context (i.e. a Company- or Contact- related item) as required by the user.

DBA-level users will be responsible for ensuring that the data dictionary includes the UDF. This will be necessary because the additional parameters held in the dictionary control the ultimate output of SQL code for searches.

Deletion of a table or field will require maintenance of database integrity, i.e. related references must also be. removed at this point. This process will be incorporated in the program as an automated routine.

AMC Bottom Layer - The Database Encapsulation Layer (DEL).

The database encapsulation layer (DEL) is the wrapper around the underlying RDBMS system; it is used to translate from the hierarchical database structure to the RDBMS so that the rest of the system can operate independently of the underlying database. It handles the way in which the information required to construct the entities and property objects is stored, along with information on the relationship between entities. It also has the responsibility for marshalling and de-marshalling the sub-graphs of objects representing sections of the hierarchical database, and grouping these using "entity set objects" to pass information to the other layers.

The new database structure will support the creation of an unlimited quantity of "tables" and "fields" within this fixed structure. All properties of these "tables" and "fields" including the relationships between "tables" is completely user configurable through a simple web based user interface.

The structure of the user viewable database structure is stored in a traditional RDBMS (Relational Database Management System) such as Microsoft's SQL Server, Access and MSDE (Microsoft Database Engine).

A software wrapper, the Data Encapsulation Layer (DEL) round the RDBMS provides an object model which allows powerful querying, and interaction between the database and the Activity Manger Configurator (AMC), without the need for any SQL programming language knowledge.

The Database Encapsulation Layer allows the new system to be based on an abstracted view of the underlying database; the tiers above the DEL will not be able to interact will the underlying relational database directly. This means that the systems with require minimum alteration to allow it to work across multiple databases. The two main areas of responsibility for the database encapsulation layer are marshalling and de-marshalling of entities and their properties, and handling optimisations for searches.

Entities

An entity, in our Entity-Attribute-Nalue architecture (EAVA), represents a collection of related information; for example, in all applications of this exemplary embodiment of the invention this may be a company, contact or individual, but the entity can represent any collection of information. It also stores meta-data about itself. Properties (attributes)

Whereas the entities describe collections of information, the properties contain the actual information along with the name of the property (e.g. "Main Phone"), the data type (e.g. fraction, integer, string etc) and any rules on validating the data (e.g. email address checker for example).

Relationships

A relationship is any connection between two entities, it contains information on the direction of the relationship; for parent/child relationships such as:

• Ownership

• information on the name of the relationship: "married to", "works with"

• Information about the relationship between entities must also be stored. These relationships can be one-way, such as "ownership", or two-way, such as "worked with".

• Meta-data about the relationship itself must also be stored, such as its name and type.

All relevant relationship information will be passed along with the entities in the entity set object.

Entity Sets

Entity sets are collections of entities along with additional information about how they are related. This includes holding the details of the relations between the entities, the number of entities it contains, along with any details on order within that set. It will also give an indication of the origin of the set, such as a search result or a specific entity request.

Referring to Figure 2 of the drawings, there is illustrated schematically a pair of entities and their properties. Marshalling Entities and their Properties

Marshalling entities describes the process of converting data from the underlying relation database, and constructing the objects representing the entities and their properties.

The process of marshalling first requires the database encapsulation layer to receive information on what entity is required. It then looks at the tables in the underlying relational database and collects all the information related to the entity requested. This includes all the values for the properties, along with their meta-data, information about all the relations the entity is part of, and optionally, other entities that link to the requested entity. It then creates an entity object, with the name defined by the record; it then proceeds to create property objects for every property listed in the tables, updating the list of properties in the entity as it adds each one. Upon completion of this process the entity should have a list of all its properties. The entity object, along with its property objects, is then passed to the middle tier.

De-marshalling Entities and their properties

De-marshalling entities is as important as creating them in the first place: it is at this point that any changes in the system are written back to the database for storage. De- marshalling starts by the DEL working its way through the list of the entity properties, checking if they've been changed. If they have, it then proceeds to write the information back to the database. At this point the DEL checks if the "auditing" system flag is set. If it is, rather than overwrite the existing data, it will mark the existing record as old, and create a new record with an incremented version number. This prevents any data being lost from the system, and allows version histories of properties to be created. If the "auditing" flag is not set, then the DEL proceeds to overwrite the existing property record. In the case of new properties, records are created to represent the new entities. Searches

There may be two types of searches in the system according to this exemplary embodiment of the invention; straight forward criteria matching, such as looking for records which belong to someone, and graph traversal searching, which can search across many types of relationships. This is largely handled by the middle tier, but the DEL will allow for several optimisations to speed the process up, such as testing whether an entity has a relation of a particular type.

Glossary

EAV Database Table-Field Specification Technical

As the database structure is completely fixed, there is no requirement to create and alter tables to add fields and change properties, all of these details need to be stored within the predefined tables.

Entity_Definition Table

Stores all of the properties relating to the "table" (from the user perspective) such as the name of the "table" and details relating to the security credentials.

Property Definition Table

Stores details of all of the properties relating to the "fields" of the "tables".

Example Entity_Definition Property_Definition

The above example details a situation where there are 3 individual "tables" in the database with 8 properties associated with them. The "Company" "table" contains a single "field" called "Name", the "People" "table" contains "Name", "Date Of Birth" and "Spouse Name" "fields" and "Appointments" contains "Start", "End", "Note" and "Location" fields.

Unique Benefits of the AP, AMC and EAV Database

This fixed database structure will only require between ten and twenty predefined tables in order to manage large complex RDBMS, whereas traditional database structures may require dozens or possibly hundreds of tables.

This complete simplification of the database structure will provide not only for faster access times for any given query but, will also make database design much easier and on-going maintenance simpler.

Using the proposed new database structure, an application configurator does not need to have the high levels of programming skills currently associated with building relational databases. Those with a basic knowledge of database design can with little or SQL programming knowledge, create complex databases. This ability to build databases from the users' requirement down means that applications can be developed using 'business rules'.

Additionally, because of its totally flexible structure, the AP EVA database can be configured to manage virtually any known database structure.

It will be appreciated that in this example, the RDBMS is Microsoft SQL server, however the database encapsulation layer and the data value attribute database can relatively easily be modified for different database engines.

Time Manager

Just as time is one of the key essentials of all business activities, the Time Manager module within the AMC of this exemplary embodiment of the invention is central to the application, managing all time-derived activity, either for audit trail purposes or as a user defined activity. More than just an appointment manager, Time Manager can also be used to allocate and view activities such as group sales meetings, holiday planning, project and contract workflow management or as a marketing campaign scheduler.

The Time Manager manages database functions such as recording record creation dates, field amendment times, time zone management and regional time and date formats for local setting views in the presentation layer.

Local Settings

Time Zone management is essential for users working across continents , especially when contractual or other processes are time critical. Users can select their current time zone and all notes and other time related activities will be written to that time, not, as would otherwise be the case, the server clock time, which may be running hours behind or ahead of that user.

Data Formatting overcomes one of the most confusing and irritating problems associated with working across national boundaries. If the date display shows 07/06/03, what is the actual date? Setting the date format to match the locally used format means that all dates are displayed in that format, eliminating potentially costly or even dangerous confusion.

Calendar views

Time manager data relating to users, projects tasks, contracts or other planning activity is viewed within the AMC presentation layer as a series of calendar views, i.e. today, working week, month or year. The Time Manager module can store activity data covering an infinite time and the display of this date onscreen is only limited by the processing power of the server. A calendar spanning four hundred years viewed on a day-by-day basis is considered to be the maximum currently practical.

Time Manager Database Structure

With the way that the information is being stored in the database, it is possible to carry out searches and calculations on an individual data type with a single pass. One of the planned data types is a block of time. The current thinking is that one of the configurable properties of the "time blocks" is to check for, and prevent, clashes between the blocks.

When a new entity is added which contains a "time block" property (which has the flag to prevent clashes), a search is carried out on the entire database for all "time block" properties with the check clash flag set, testing to see if any of the appointments returned clashes. When this occurs, messages can be returned to the user notifying them about the clash and allowing the user to force the save if required.

When it comes to displaying these entities with "time block" properties (for example as part of the calendar), the search for the items to be displayed can be carried out in a single query and further filtered down by the entity type if required.

Supporting Functions Included

Function concat (si as string, comma a string, s2 as string) as string-adds a comma to the middle of the two strings if necessary (ie only if si and s2 and not blank).

Function cif (conditional as bool, truestr as string, falsestr as string) as string - conditional assignment, so that we can do the equivalent of the Java and c ^ functions so: x = date > threshold? "overdue": "pending" would be implemented as: x = cif (date > threshold, "overdue", "pending") Supporting Functions.

function valid (s as string, typestr as string) as string - this function returns a valid string format for the type of variable being entered in reference to an SQL

INSERT or UPDATE function ie

A string s it returns "s".

A date "dd/mm/yyyy" returns "yyy-mm-dd" or NULL

A number n it returns as n or NULL. NB: Both the client and server side date formats are defined in connect, inc. The variables used are "serverDataFormat" and clientDateFormat". At present it is assumed that all dates pushed into the server should be presented in ISO format (yyy/mm/dd) as defined by serverDateFormat. Date values extracted from the server will be presented in the form of clientDateFormat (currently set to "dd/mm/yyyy"). Some date fields may be stored in the back end as strings but this presents no difficulties for sorting in ISO format and displaying is taken care of by the amc file which, should defined the field type as DATE.

Function mapper (si as string, s2 as string) as string - this function produces a regular expression replacement string which is used to map one date format into another date format.

Field Validation & Verification

The entry of incorrect data into the form is controlled at field level and the entry of mandatory fields is controlled at form level just prior to the form submission.

(i) Date fields

The Table HTML function automatically produces date pickers and a javascript

"onblur" event to check that users have correctly entered a date string. A (recognised) default value of "dd/mm/yyyy" is wiped out if the user tabs into this field.

When submitting the form, this value is not permitted if the field is mandatory. Otherwise, the value is assumed to be blank.

Field validation is carried out by Javascript using the function:

Function validate (f as field, lower as string, upper as string)

Where: f is the field to be validated lower is an optional value for the starting date upper is an optional value for the ending date

Entering a single digit will give a date that is assumed to be current month, current year. Entering two digits will give a date that is assumed to be in this year. (ii) Numeric fields

The validation function for numeric field entry is also triggered for the "onblur" event. Field validation is carried out by the following javascript function:

function validNumber (f as field, dp as integer, lower as real, upper as real)

Where: f is the field to be validated dp is the number of decimal places to round the number to lower is an optional value for the starting date upper is an optional value for the ending date

Other than f, all parameters are optional and therefore a limitless integer number is accepted as a correct entry.

It appears to be more efficient to store a physical.screen file instead of pulling data from an SQL table.

It will be appreciated in respect of all of the above applications, the system may be a web-browser based, and as such all of the functions may be accessed and/or managed via the inernet, intranet or extranet as required.

It should be noted that the above-mentioned embodiment illustrates rather than limits the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. Apparatus for managing a database which can be configured by a server requiring input of one or more programming commands, the apparatus comprising means for receiving one or more user commands and means for converting said one or more user commands into corresponding programming commands for input into said server for configuration of said database.

2. Apparatus according to claim 1, further including means for enabling a user to create one or more searches in respect of the data stored in the database according to one or more criteria.

3. Apparatus according to claim 2, further including means for enabling a user to generate one or more reports of the search(s), in any required format.

4. Apparatus according to any one of claims 1 to 3, comprising a core module for controlling configuration and management of said database.

5. Apparatus according to claim 4, wherein the core module comprises a plurality of operation layers.

6. Apparatus according to claim 5, wherein the core module comprises three operation layers.

7. Apparatus according to claim 6, wherein the three layers comprise an upper or presentation layer, a middle or system management layer, and a bottom or data encapsulating layer.

8. Apparatus according to claim 7, wherein the presentation layer is arranged to receive the user commands for defining a presentation format of information displayed by the apparatus.

9. Apparatus according to claim 7 or claim 8, wherein all communication between the layers of the core module is in the form of packaged objects.

10. Apparatus according to claim 9, wherein the presentation layer is arranged to package the user commands into packages for propagation to the database, via the middle layer.

11. Apparatus according to any one of claims 7 to 10, wherein the middle layer is arranged to receive user commands for creating and formatting database tables and fields and/or creating searches and reports based on data stored in the database.

12. Apparatus according to any one of claims 7 to 11, wherein the commands defining business rules, i.e. defining rules relating data management of the system.

13. Apparatus according to claim 12, wherein said middle layer manages data objects passing in both directions through the apparatus using said predefined business rules.

14. Apparatus according to any one of claims 7 to 13, wherein the bottom or database encapsulation layer defines a wrapper around an underlying relational database management system (RDBMS).

15. Apparatus according to claim 14, wherein said bottom layer is arranged to configure programming code requirements necessary to interact with the underlying server database.