The present invention relates to database systems. More particularly, the present invention relates to a global database system and method which allows multiple users to access data in relation to each other regardless of their geographical location, the storage mechanism that stores the data or the type of data which is required.

A database is a shared collection of logically related data designed to allow access to multiple users. A database system may exist in an organisation where a centralised database server within the organisation is to be accessed by multiple users of the organisation. The central server is managed by a database management system which is typically a software package allowing database processing and shared access function.

The architecture used to implement such a system is typically known as a client/server database architecture. An example is shown in Fig 1.

A local database system 10 for a first organisation includes a database server 1 which comprises of a database Ia and a database management system Ib.

The clients of the database system are a plurality of end user terminals 2 which are capable of accessing the database server 1. The terminals 2 are usually provided with an application program (not shown) to interface with the server 1.

The application program usually displays a user interface when it is executed by a user. With a user interface, a user can interact with their respective terminal 2 and cause the terminal 2 to communicate with the database server 1 and access data with relatively little difficulty. EP-A-575358 and EP-A-466878 relate to user interfaces for the creation of queries by means of which a user interrogates a database to obtain reports. Both

documents are directed at the provision of graphical representations which appear on the screen of a computer to assist the user to create a query.

Many organisations utilise a database system with a client/server architecture and an example of two database systems for two separate organisations is shown in Fig 2.

The database server 1 of the first database system 10 usually stores information only relevant to that particular organisation and the clients of the database server 1 are provided with an application program which allows compatibility with the database server 1 of that particular organisation. Moreover, the database management system Ib which manages the database Ia will be configured to be compatible with the application programs installed on the terminals 2 and to accept requests or queries from only these terminals 2.

A local database system 20 of a second organisation may adopt a similar client/server architecture to the first organisation. That is, the system will comprise a database server 3 and clients which are a plurality of user terminals 4.

If a user terminal 2 from one database system 10 requires access to data from the database server 3 of the second organisation, then various compatibility issues usually arise. In particular, the database server 1 may utilise a different data management system Ib to the database server 3 of the second database system 20. Further, the first database server 1 may be configured to contain one type of information such as human resources information whereas the second database system 3 my be configured to contain another type of information such as financial information leading to further incompatibility issues.

In accordance with the above problems, it is desirable to implement a database system allowing users from one or more organisations, which may utilise different database software or platforms, to access data from each other. Further,

it is desirable for the data to be analysed and for relationships between data from the organisations to be created.

In the light of the above, from a first aspect the present invention provides a apparatus which incorporates a central repository to be positioned at a hierarchal level above the client/server architecture and allow data access between various database systems regardless of the geographical location of the systems or the storage mechanisms adopted by the various database systems.

Further, the present invention provides an interface program which allows data to be accessed between various database systems regardless of the software managing and storing the data in the various database systems.

The interface program is loaded on a user terminal of a client/server system and investigates databases that are connected to the local system by requesting data from a particular database or geographical location through the central repository. The advantage of a system according to a preferred embodiment is the creation of a central repository which contains data structures from various underlying databases on various underlying database and file system platforms.

The presence of the central repository within the overall system allows for new relationships between disparate separate database systems to be created. Further, the interface program is adapted to analyse the relationship data created by the central repository and locate the correct data from one or more underlying database systems.

In another embodiment, the interface program is capable of receiving a first input indicative of a query for data from the central repository, and a second input indicative of an update of the data contained in the central repository. In particular, the second input may be provided in any natural language such as English or Hindi and the interface program can convert this into a common communication

language which can then be converted back into the language of the data contained in the central repository if this is not the same as the communication language.

From another aspect the present invention provides a database system comprising: a first database including a first type of raw data stored using a first computer language; a second database including a second type of raw data stored using a second computer language; a central repository comprising a metadata model compiled in a third computer language for modelling the operational aspects of an organisation; and means for communicating between the central repository and the first and second database, wherein the communicating means is adapted to communicate in a common language.

In order that the present invention be more readily understood embodiments thereof will be described by way of example with reference to the accompanying drawings in which:

Fig 1 shows an example of a client/server architecture utilised by a first organisation;

Fig 2 shows an example of two separate database systems of two organisations;

Fig 3 shows a database system according to a preferred embodiment of the present invention;

Fig. 4 shows an graphical user interface of an application program utilised in the system of Fig 3; Fig. 5 shows a further display of a graphical user interface of Fig. 4;

Fig. 6 shows a further aspect of the graphical user interface of Fig. 4;

Fig. 7 shows a display generated when an item is selected in the graphical user interface of Fig. 6.

Fig. 8 shows a display generated when an item is selected in the graphical user interface of Fig. 7. Fig 9a shows a graphical user interface of a second tab utilised in a further application program;

Fig 9b shows the graphical user interface of the second tab scrolled further down the display of Fig 2a;

Fig 10 shows the graphical user interface of a first tab utilised in the further application program;

Fig 11 shows a further feature of the further application program.

Fig 12 shows the conversion capability into English of the further application program;

Fig 13 shows the conversion capability into Hindi of the further application program;

Fig 14 shows the geographical user interface of the input code in a first language and the generated code in a second language; and

Fig 15 shows a schematic diagram of the further application program.

A preferred embodiment of the present invention will now be described with reference to Fig 3.

A system comprises a centralised database system 30 which is hereinafter referred to as a central repository 30. The central repository 30 is arranged to communicate with a plurality of database systems 10,20, each adopting the client/server architecture as described hereinbefore. However, the database systems 10,20 differ from conventional systems in that they are provided with an application program to allow communication with the central repository 30. In addition, the database system 10,20 is registered with the central repository 30. In

this regard, the repository 30 may store usernames and passwords of individual users if they are required to access certain data from certain databases.

When a user 2 from the first database system 10 wishes to access data from a database system 20 of another organisation, the user 2 uses the application program stored on the users terminal to locate the type of data that is required. The request is sent to the central repository 30 which stores data in relation to the plurality of database systems registered with it. The central repository 30 does not need to store all the contents from the various database systems but instead stores a location of a particular database and details of the contents of the database and thus when information from a particular database is requested the central repository 30 exports the data about the data (known as "metadata") and then allows multiple accesses to be made to the several underlying databases as if they were one database to the end user thus removing the need for an end user to separately navigate through each database. The central repository carries out the exportation process of the data. This provides a convenient method for one database system 10 to access the data from the second database system 20 without the second database system having to perform any authorisation or data acknowledgement steps.

The manner in which this is achieved is through the generation of a metadata model in the central repository. The model is a blueprint of the various levels in an organisation, and outlines the various resources. For example such resources could be services provided, human resources, capital equipment, event logs for risk management purposes, organisational hierarchy, and product characteristics such as types. All these resources relate to operational aspects of the organisation and are preferably non-financial aspects of the system. It will be appreciated however that the metadata model can be provided with financial data if required.

The system has the capability for data to be exported from the second system 20 regardless of the particular database management systems utilised by the respective database systems. The application program used to communicate with the central repository 30 ignores the respective applications stored on the database system 10,20 and instead links the two systems at the database layer thereby mapping one database to another and extracting the required contents of the database regardless of the type of database platform utilised by different organisations.

In particular, with reference to Fig. 3, the first database system 10 may be operating under SAP software platform and the second database system 20 may be operating under Peoplesoft software platform. The application program used to communicate with the central repository 30 has the capability of interrogating the various databases la,3a of each system 10,20 and creating a data map of the various contents of the database. In this regard, the central repository 30 can query the data stored on the database and effectively scans the schemas of each database which provide a description of the database contents. Moreover, the central repository creates a separate schema as a result of the interrogation of the various databases and this allows the central repository to provide information on each database structure without having to interrogate each database every time a request for information is made by a user. As stated hereinbefore, the actual contents of each database are not required to be stored in the central repository and when actual data is required the central system connects to the underlying databases and then provides this.

Although SAP and Peoplesoft are described, the type of platform which can compatible with the present invention is not limited to this.

It will be appreciated that such a database model may be incorporated into a single organisation. For example, the first database system 10 is configured in

SAP and stores data relating to human resources for the organisation. The second database system 20 is configured in Peoplesoft and stores data relating to finances for the organisation. With a system according to the present invention it is possible for the application program used by the present invention to interrogate each of the databases and construct a separate schema of the data contained therein. Moreover, data relationships are created in the central repository as a result of the separate schema being constructed by the application program.

The application program executed on the user terminal 2 will now be described in more detail with reference to Fig. 4. A graphical user interface 40 is displayed on the users terminal when a user activates the application program. The interface 21 comprises three main components: a navigation component 41; a browser component 42; and a context component 42.

The navigation component 41 is preferably a tabbed area capable of displaying a number of different visual indications when a tab is activated. In the present embodiment, the navigation component 41 comprises three tab menus 41a, 41b, 41c. When the first tab menu 41a is activated, a map area is shown. It will be appreciated that instead of a map, an intranet site or other visual indication used to identify an organisation may be displayed. The browser component 42 displays a series of folders 42a each representing a particular main group. In this embodiment there are 5 main groups but it will be appreciated that the browser component is not limited to this number. Each of the main groups are capable of being expanded to display further groups within a particular group. The folders 42a are split into two columns. The first column 42b represents a title for the folder 42a and the second column 42c provides one of two tags. A first tag specifies that information is not known in respect of the particular folder

and a second tag specifies that information is known. The output of the second column 42c is dependent on the status of the central repository 30 and on whether a particular database system 10, 20 has identified to the central repository 30 that it contains a certain type of data. If the certain type of data is made known to the central repository 30 then the central repository will store an indicator known as a universal resource indicator to provide a pointer as to which database a particular type of data can be found. This removes the need for one database system 10 to individually request a certain type of data from a plurality of remote database systems and instead allows a central repository 30 to perform the task of directing the database system 10 to another database 20 which stores the required information.

Now turning to the type of data, the third component on the user interface 40 is the context component 43. In this embodiment, there are three icons 43 a, 43b, 43 c within the context component 43. It will be appreciated that there may be more or less icons in the context component 43. Each of these icons indicates a type of data is known in respect of the contents of the folders 42a.

An example will be provided with reference to Fig 5. In this example, the first folder "Buildings" has been opened to provide a further three folders, "Registered Offices", "Call Centre" and "Power Station". Further expansion of each of these folders is possible and this is continued.

As described hereinbefore each of the folders is assigned a title 42b and each folder is provided with one of two tags. As shown in Fig. 5 most of the folders display the first tag i.e. indicating that data is not known in respect of a particular folder. However, the second tag is shown in respect of at least two folders "Cockenzie" and "Longannet". This implies that data is known and the type of data known is displayed in the context component 43 when one of these folders is selected. When "Cockenzie" is selected, this causes the database server

10 to consult with the central repository 30 to determine where the data is stored by referring to the universal resource indicator and the type of data known in relation to "Cockenzie". Consequently, the context component is updated and one or more icons 43 a, 43b, 43 c is highlighted. In this particular example, the data known causes icon 43 c to be highlighted which represents map data. It will be appreciated that many types of data may be shown on the context component as long as the type of data has been registered with the central repository. For example, in Fig. 5, further types of data icons such as service diagrams 43 a and/or organisational charts 43b are available if the required location of the data is known to the central repository.

When one of the icons which are highlighted in the context component is selected, the navigation component 41 will be updated to output the relevant data. For example, a map is output in the navigation component when the map icon is selected. Turning to another aspect of the application program and with reference to

Fig. 4 and Fig. 6.

Fig. 6 shows the user interface displayed when a section of the map on the navigation component 41 of Fig. 4 is selected. In this example, the Europe section of the map in Fig. 4 has been selected. The selection results in a zoomed-in map 41 d of Europe to be reproduced in the navigation component 41. At the same time, the central repository 30 is consulted and the data known about the selected area is provided in the browser component 42. In this example, the information on "publishers" is displayed in a menu 42d with respect to the separate countries of Europe for which data is known, in this case France and Germany. In addition, the relationships between the data in the databases la,3a, is established by consulting the schema contained within the central repository. If relationships with other databases exist then an indication is provided in the browser component 42 to

specify the type of relationship that is known. In this example, two possible relationships are established and displayed on the bottom of the browser component. The first indication 42e is "publisher publishes books" and the second indication 42f is "publisher employs employees". If more information is required in respect of either of these countries, the country can be selected on the map 41 d or can be selected from the menu 42d. When "France" is selected, the information relating to "Germany" on the menu 42d is removed from the browser component 42.

Once information relating to "France" is only displayed on the screen, it is possible for one of the indications 42e, 42f, to be activated. When the second indication 42f is activated, the application program queries the database which contains the employee information by consulting the central repository to establish the location of the database containing the employee information. The display of employee information is shown in Fig. 7. The employee information is shown in a table 42g in the browser component 42. Further, the component 42 shows a further indication 42h which relates to "employee works for a publisher". By clicking on this indication, a display is generated to show information on the publisher for which the selected employee works. This display is shown in Fig 8. The generated display provides a view to show a series of fields 42i relating to information specific to the particular publisher who employs the selected employee. Again all this information is stored in a database whose location is registered with the central repository. The display is similar to that of Fig. 6 by containing the first indication 42e and second indication 42f of Fig. 6 again allowing the user of the application program to browse through and view data contained in various databases within or outside an organisation.

In order to allow users from different parts of an organisation to update the metadata model and for the central repository to communicate with the various database systems of the organisation which may be positioned in different global locations utilising different natural and computer languages, it is possible to provide the user terminals 2, 4 with another application program.

A user of the user terminal 2,4 activates the further application program which is capable of being accessed by the user terminal in an appropriate manner such as by utilising a pointing device to select the application program on the user terminals visual display unit (VDU). Once activated, a graphical user interface is presented on the user's VDU. A preferred graphical user interface 60 is shown in Fig 9a.

The user interface 60 comprises a main component 61 and a conversion component 62 which in this particular Figure is not immediately visible. The main component includes two tab menus, 61a,61b. The first tab menu 61a is not selected in this particular figure whereas the second tab menu 61b is and thus will be described in more detail.

When the second tab menu 61b is selected, the main component 61 displays the contents of a message file which is stored in the central repository 30. The message file contains data in relation to particular natural languages which are recognised by the application program. In addition, definitions of certain code which are to be utilised by the application program are defined in the message file.

For example, in this particular example, the display shows data in relation to "English" and "Hindi". In the English language definition, there is contained the equivalent English language representations of particular symbols and signs which are typically utilised in programming languages. More specifically, the sign, ":=", is represented as "Becomes", the sign, "=", is represented as "Equals" and "<=" is represented in the English language definition as "Less Than Or Equal

To". It will be appreciated that a complete list of definitions will define all the possible sign and symbols which are capable of being translated.

Following the English language definitions, the message file includes the equivalent Hindi language definitions of the same symbols and signs which are defined in the English language definition list. Furthermore, definitions of typical terminology utilised in programming code is provided. For example, the terms "If, "Then", "Else" and many more are provided with their respective language definitions.

It will be appreciated that the message file will contain all possible definitions in all languages which are to be recognised by the application program. In this regard, German, French and Chinese definitions may be included.

Also described in the message file is the definitions of certain coding objects which are to be utilised by the application program. These are displayed in the main component 61 when the scroll bar 61c is utilised, and in this case, scrolled down.

Referring to Fig 9b, a typical term which may be defined is

"CustomerRow" and each of the components utilised to define "CustomerRow" may also be defined in different natural languages. For example, "Forename" which is defined within the "CustomerRow" definition is provided with the corresponding Chinese, French and Hindi natural language definition.

The message file may be stored in the central repository 30 or in a local database server 1,3- Alternatively, it may be passed in or generated from an underlying object or database system.

Further, the message file is capable of being updated or amended by a user in the main component 61. For example, further language definitions may be provided.

Turning to a further control element 61 d which is provided on the main component 61 when the second tab component 61b is selected. The control element 61 d represents a parsing functional element which parses the message file when activated. That is, the message file is required to meet a certain structured definition to operate correctly. To ensure that the message file meets these requirements the file is parsed and checked with a certain structured definition when the control element 61d is selected. The certain structured definition is preferably stored in the memory (not shown) of a user's terminal.

Fig 10 shows the display generated when the first tab 61a is selected by a user. The generated display includes a drop-down menu 6 Ie and a toolbar 61f enabling functions such as "save", "open", "cut", "paste" and many more which can be performed on the contents of the main component 61 and such functionality is known to the skilled person.

The drop-down menu 61 e contains a list of the possible languages to which the contents in the main component can be displayed in. The list will depend upon the language definitions which have been included in the message file.

Fig 11 shows an example of code being entered into the main component. The main component 61 displays programming code which is consistent with the code definitions which are included in the message file. The rules to be followed when entering code in the min component 60 are specific to the present invention and relate to the definitions provided in the message file. Code is entered in the main component 61 by a user and the validity of the code entered is checked as the user types. Any code which is invalid is indicated to a user in an appropriate manner. For example, the invalid code is colour coded to indicate an error. Alternatively, a separate indicator may appear on the main component 61. As shown in Fig 11, an indicator 61g on the top of the main component 61 indicates

the number of errors which are present in the code. This is updated as code is entered.

Moreover, another useful feature of the application program is that a dropdown list 6 Ih is generated and displayed on the main component after a pause in the entry of code to show a list of all valid entries and allowing a user to select one of these entries if required. The drop down list 6 Ih corresponds to object definitions which are contained within the message file and the generated of this list is achieved by locating the object names in the message file and generating the drop-down list based on the object names. In this particular embodiment, the drop-down menu 6 Ie displays "standard" which indicates that the code is displayed in structured English. This enables the code to be understood by users who have very little programming knowledge.

Fig 12 shows a further feature of the application program in respect of the drop-down menu 6 Ie. As mentioned hereinbefore, the menu 6 Ie contains a list of all possible natural languages in which the code displayed in the main component 61 can be translated. The natural languages contained in the list depends upon the language definitions which have been provided in the message file. For example, the message file contains the English equivalent definitions of the symbols and signs utilised when coding such as ":=", ">", etc. When "English" is selected from the drop-down menu, the message file is consulted to identify the definitions which have been provided and the code in the main component 61 is analysed and any code which has an English language equivalent defined in the message file is replaced by the corresponding English phrase. In Fig 12, the sign ":=" and ">" has been replaced by "Becomes" and "Greater Than" respectively. This type of replacement occurs for the entire code contained in the main component 61.

Fig 13 shows the translation which occurs when the "Hindi" selection is made in the drop down menu 6 Ie. As shown, in addition to the symbols such as

":=" and ">" being converted to their Hindi language equivalents, other code expressions are also translated into Hindi after having consulted the message file. For example, "If, "Else", and "End If in the original standard code shown in Fig 11 has been translated into "Yadi", "Athwa", and "AnthYadi" respectively to represent the Hindi equivalent. It should also be noted that the object definitions such as "Cust.Forename" and "Cust. Surname" are translated into their Hindi equivalents which are provided in the message file. That is, "Cust.PrathamNam" and "Cust.KulNaam" respectively. This translation is performed for the entire program code in the main component 61. It will be appreciated that any type of translation can be carried out if the language is available in the drop-down menu. For example, German, French, Spanish, Chinese translations may be carried out. This allows users of different nationalities to understand and utilise the application program.

The above description describes the main component 61. The conversion component 62 will now be described with reference to Fig 14.

The conversion component 62 is capable of being expanded such that the user interface 40 displays the conversion component 62 and the main component 61 on a single graphical user interface. In this particular embodiment the conversion component 62 is shown on the left frame. The conversion component 62 is a code generator configured to generate code in a particular language based on the code which is entered in the main component. It is possible for the code in the main component to be converted into any of a number of languages such as C#, Jscript, VP, C++, J#. The conversion component 62 is provided with a series of selection elements 62a which each represent a different programming language. By simply selecting one of these elements will cause code to be generated in that particular language.

Moreover, the code in the conversion component is generated as code is entered into the main component, thus in real time a user types and completes a line or statement in the main component 61.

Fig 15 shows schematic overview of the configuration of the preferred embodiment of the further application program.

The main component 61 and the conversion component 62 represent the user interface 60. The message file 60 is arranged to be consulted by the user interface 60 when certain data is required or a certain function is to be performed by the user interface. The input to the user interface 60 is the code which is input into the main component 61. It will be appreciated that the code may be accessed from a separate location and does not necessarily have to be entered into the main component. The output of the user interface is the code generated from the code in the main component 61. This may be C#, J#, C++, Jscript or any other language which is compatible with the application program. The functionality of the further application program is used for the enabling the central repository to interrogate the various underlying database systems regardless of the programming languages or the natural languages which are used to initially input the data to the respective databases That is, the raw data which is contained on the various databases Ia, 3 a, may have been input into the databases Ia, 3 a using programs created from different programming languages. In addition, the schemas of each database which define the contents of the database may be in different natural languages such as English or Hindi. With this functionality it is possible for the central repository to obtain the required data from the respective underlying databases by performing the conversion described above in real time. Therefore the system is not limited to the types of languages which are used to enter data as the functionality of the further application program can be adapted for use with the metadata model stored in the central repository.

It may be the case that certain types of schema and related raw data are not recognised as a result of the interrogation carried out by the central repository. However, the central repository is provided with an analyser which can analyse the retrieved unknown data and the metadata model will be able to be modified on the basis of the unknown data such that it will be available. In this way the model can be gradually expanded with certain types of data which were initially unknown.

In summary, the further application program is capable of converting a business computer language to many different language versions of the business computer language, many different programming languages in English, many different programming languages in mixed English and natural language and any programming language that has full natural language versions.

This enables users from different parts of the organisation to communicate with their local database server 1 ,3 in their local natural language. Although each local database server 1,3, is in communication with the central repository 30, the use of the further application program allows the central repository 30 to obtain the required data from the database server 1,3, regardless of the local natural language or programming language due to the conversion capability.

It will be appreciated that although the application program and the further application program have been described above, the user interfaces 40,60 may be incorporated into a single application program if required.

With the above arrangement, the system according to the present invention allows one database system to provide information to another system without requiring any action to be taken by the other database system when the information is requested.

Moreover, the system according to the present invention allows communication between all underlying databases of a particular organisation and

further enables relationships between database systems to be created. Accordingly, navigation between various database systems is possible.

In view of the above, the preferred embodiment of the present invention has the following features: a) gathers data about data ("metadata") from the various underlying databases forming part of the system; b) allows relationships to be declared and identified between disparate underlying databases c) allows navigation through a database without the user having to use original application stored on the user's terminal d) allows navigation across multiple databases using the relationships declared e) generating maps which include location data of the underlying databases. f) multiple end users to use their multiple natural languages to share and edit data in the databases situated in different locations of an organisation. g) allows the metadata model to be updated regardless of the natural language utilised to update the model.