WO1998034185A1

WO1998034185A1 - Integrated computer databases

Info

Publication number: WO1998034185A1
Application number: PCT/US1998/002299
Authority: WO
Inventors: Robert Dourandish
Original assignee: Ams Services, Inc.
Priority date: 1997-02-04
Filing date: 1998-02-04
Publication date: 1998-08-06
Also published as: AU6271298A

Abstract

A computer system is provided with a database containing stored data, an application adapted to provide a user interface to a user operating the computer system, the application having a first view of the data stored in the database, a data manager having a second view, different from the first view, of the data stored in the database, and a session manager interfaced between the application and the data manager. The session manager is adapted to receive from the application a first request for data formatted according to the first view of the data, translate the first request for data into a second request for data formatted according to the first view of the data , and forward the second request for data to the data manager. In this way, the application is able to access data stored in the database without requiring the application to have knowledge of the second view of the data. The session manager may also be further adapted to receive from the data manager a first response containing a first subset of data formatted according to the second view of the data, translate the first response containing the first subset of data into a second response containing the first subset of data formatted according to the first view of the data, and forward the second response containing the first subset of data to the application.

Description

INTEGRATED COMPUTER DATABASES

Technical Field

This application relates to the field of computer data storage and more particularly to the field of integration and sharing of stored computer data.

Background of The Invention

It is known how to use computer software programs to store and retrieve digital data in a systematic fashion. The data may be organized in a variety of ways such as in a relational database, a hierarchical database, and/or an object-oriented database. Many databases permit storage and retrieval of data using a standard query language, such as SQL. In some instances, special database systems are designed for use by a particular application. Each specially designed database may have its own unique format for storing and retrieving data. Any application accessing the data adapts to this unique format.

Data accessing systems may be viewed as having many levels. One level corresponds to each application's particular view of the data. Each application that accesses data may have a different view, or differing assumptions, about how data is stored. This may be referred to as an

"external view" of the data. Unfortunately, different application programs may have different external views of what appears within the same database. Thus, coordination of different external views of data within a single database system can be difficult.

Another level corresponds to a conceptual data model of the database. This model is the internal view of the database engine. Another level of abstraction for a database system corresponds to a physical data model, which represents how conceptual data model information is actually stored in a physical medium. In addition to the above levels, data access systems may also include an access language and protocol which define how storage and retrieval of data within a database is affected. The language relates to the structure, format and effect of program requests to store, retrieve and manipulate data. SQL is an example of such a database access language.

Thus, data may be accessed by first making a request using the applicable access language and protocol. The structure of the call is based on an external view of the data. The call may then be mapped into a corresponding conceptual data model for the database, which, in turn, is mapped onto the physical data model in order to access the stored data item.

The proliferation of different applications accessing data in different ways makes it difficult for the different applications to share data. There is a need to coordinate access to data that is spread across a variety of databases, database locations, and database programs. Past solutions have focused on the creation of data warehouses. For a data warehouse, all of the data in the existing database is converted into a single storage system, using a single conceptual data model and a single physical data model.

The data warehouse approach, however, suffers from a number of disadvantages. First, the system requires conversion of all of the data in the existing, disparate databases into a single database. Moreover, the transition from the existing systems and databases to a new data warehouse is done in a single large step, thus requiring that the entire investment be made up- front. In addition, once the conversion begins and after the conversion is complete, the conceptual data model must remain relatively static, thus making it difficult or impossible to achieve efficiencies that are discovered after the conversion begins and reducing or eliminating the ability to respond to changes in the data that may make different models for structuring the data more efficient.

Accordingly, what is needed is a method and a data accessing system permitting access to data that is stored in a variety of databases and that does not require massive conversion of the data in the existing databases. Advantageously, such a system would permit the use of the existing databases and a number of different existing applications that use data in one or more of the existing databases.

Summary Of The Invention

To achieve this and other objectives, a computer system is provided with a database containing stored data, an application adapted to provide a user interface to a user operating the computer system, the application having a first view of the data stored in the database, a data manager adapted to interface with the database to retrieve the data stored in the database, the data manager having a second view, different from the first view, of the data stored in the database, and a session manager interfaced between the application and the data manager. The session manager is adapted to receive from the application a first request for data formatted according to the first view of the data, translate the first request for data into a second request for data formatted according to the second view of the data, and forward the second request for data to the data manager. In this way, the application is able to access data stored in the database without requiring the application to have knowledge of the second view of the data. The session manager may also be further adapted to receive from the data manager a first response containing a first subset of data formatted according to the second view of the data, translate the first response containing the first subset of data into a second response containing the first subset of data formatted according to the first view of the data, and forward the second response containing the first subset of data to the application.

A memory manager may be provided to allocate memory space between components of the computer system. Preferably, the memory manager may have at least an application data group table defining data groups specifically used by the application according to its first view of the data, a system data group table containing default data groups, and a system data group definition table indicating to the data manager where to find the data from within the database. In this instance, the system manager receives from the application the first request for data formatted according to the first view of the data, obtains from the memory manager one of a data group specified for the application from the application data group table and a default data group from the system data group table, and uses the data group to translate the first request for data in to the second request for data formatted according to the second view of the data. When the data manager receives the second request for data formatted according to the second view of the data, it obtains from the memory manager the system data group definition table and uses information provided thereby to access the data from within the database.

Each application may be provided with a unique identifier, which is used by the system data group definition table to match the specific application with a specific application data group stored in the application data group table. The memory manager may also include a system data area containing the application data group table, system data group table, and system data group definition table, and a global data area available for storage of data used by the computer system. A network manager may be provided to facilitate communication between the computer system and at least one of another computer and a network of computers.

The computer system may be designed to provide data from a database to an application by formulating a query at an application level according to a first view of a data structure, communicating the query to a system manager, transmitting the data query to the data manager, and obtaining data from a database in accordance with the data query form the system manager. In this embodiment, the system manager translates the query before transmitting the query to the data manager by retrieving a data group from one of an application data group table and a default data group table stored in a memory manager and using the data group to translate the query into a data query understandable by a data manager. Data can then be returned from the database to the data manager, stored in the global data area, and returned to the application after being translated in accordance with parameters associated with the data group.

The system will also work with more than one application and more than one database. Specifically, the computer system can have a plurality of databases, a plurality of applications adapted to provide user interfaces to users operating the computer system, and a data manager adapted to interface with the database to retrieve the data stored in one or more of the databases in response to a query. A session manager is interfaced between the applications and the data manager, which is adapted to receive queries from the applications, the queries being formatted in a manner specific to the application irrespective of the data structure of the data in the data bases. A memory manager is provided to allocate memory space between components of the computer system, and has at least an application data group table defining data groups specifically used by the applications, a system data group table containing default data groups used by the applications, and a system data group definition table indicating to the data manager where to find the data from within the database. In operation, when the system manager receives from a querying application a query for data formatted in a manner specific to the application, the system manager obtains from the memory manager one of a data group specified for the querying application from the application data group table and a default data group from the system data group table, and uses the data group to translate the query for data into the request for data formatted in a manner understandable by the data manager. Likewise, when the data manager receives a properly formatted request for data, the data manager obtains from the memory manager the system data group definition table and uses information provided thereby to access the data from within the database.

The system manager has an input layer for communicating with application programs, a translation layer adapted and coded to translate queries submitted by the applications programs into queries readable by a data manager, and an output layer for communicating translated queries to the data manager. The system manager may also include a memory layer for communicating with a memory manager to obtain from the memory manager data groups associated with the applications submitting queries to facilitate translation of the queries prior to outputting the translated queries to the data manager.

Brief Description Of Drawings

The preferred embodiments of the present invention will now be described more specifically with reference to the attached drawings, wherein:

Figure 1 shows a computer system for use with the invention;

Figure 2 is a schematic block diagram illustrating a data accessing system according to the invention;

Figure 3 is a flow chart illustrating steps taken to initialize the backbone of Fig. 2;

Figure 4 is a flow chart illustrating steps taken to determine if the backbone of Fig. 2 is available; Figure 5 is a flow chart illustrating steps taken when the session manager of Fig. 2 is started;

Figure 6 is a schematic block diagram illustrating allocation of memory in the data accessing system of Fig. 2;

Figure 7 is a schematic block diagram illustrating the detailed operation and interaction of the memory manager and data manager; and

Figure 8 is a flow chart illustrating operation and interaction of the memory manager and data manager when an application requests data.

Detailed Description Of The Preferred Embodiments Referring to FIG. 1, a computer system 80 includes a CPU 81, a CRT 82. a keyboard input device 83, a mouse input device 84, and a storage device 85. The CPU 81 , CRT 82. keyboard 83. mouse 84, and storage device 85 are conventional, commonly available, computer hardware devices such as those provided for use with the Intel '486 and Pentium processors. The related software may include the Windows NT or Windows 95 operating system, available from Microsoft Corporation of Redmond, Washington. The mouse 84 may have conventional, user- actuatable, left and right buttons (not shown).

The system 80 may further include a cable 86 and appropriate hardware and software for connecting the system 80 to one or more computer networks in a conventional manner. Thus, the cable 86 may be an Ethernet connector (with suitable hardware and software), phone line (with modem and other suitable hardware and software), or any other connection that is appropriate for connecting the system 80 with other computer systems.

FIG. 2 is a schematic block diagram illustrating a data accessing system 100, also referred to as "the backbone," that may be implemented using the system 80 shown in FIG. 1. The backbone 100 permits different applications 102a-c to access data 1 1 Oa-c stored in different formats. The system 100 may also permit the applications 102a-c to access other network resources 1 14a-c, including databases that are accessible over one or more networks, using conventional network protocols and connections. The applications 102a-c may be any one of a variety of end-user programs.

As described in more detail below, each of the applications 102a-c accesses the data 1 lOa-c through a session manager 106. The session manager 106 interfaces with the applications 102a-c in a conventional manner, and passes data and requests for services to and from system resources. The system resources include a data manager 108. a network manager 112, and an other services manager 1 16. Thus, the session manager 106, data manager 108 and network manager 112 may not interact directly with a user. Instead, the session manager 106 may interact with the applications 102a-c. each of which may have an appropriate user interface.

The backbone 100 has a number of advantages, including:

• The applications 102a-c need to deal with only one interface for requesting resources and services. • The applications 102a-c need only be concerned with communication with the session manager 106. The session manager 106 handles any communication with the system resources, which may be implemented as DLL's (dynamically linked libraries) in Windows.

• The session manager 106 may provide centralized and consistent error handling.

The session manager 106 may pass an error number/message to the appropriate one of the applications 102a-c in which case it would be the responsibility of each of the applications 102a-c to handle the error in an appropriate manner.

• The session manager 106 could provide "batching" and "priority queuing^"' of requests from the applications 102a-c on a centralized basis for the backbone 100.

• Changes within the data accessing system 100 may be made without affecting the applications 102a-c.

• The session manager 106 may perform common tasks like global memory management, loading or unloading DLL's, and checking for available memory.

The session manager 106 may also provide functionality other than controlling the interactions between applications 102a-c and the backbone 100. This additional functionality may include managing global resources and managing calls from system resources.

The data manager 108 receives from the session manager 106 requests to access the data 1 lOa-c. The data manager 108 formulates a query against one or more of the databases 11 Oa-c by taking a request for particular data from one or more of the applications 102a-c (presented to the data manager 108 by the session manager 106), breaking the request down and returning or storing data, as appropriate.

The data manager 108 provides seamless data sharing and synchronization of data between the applications 102a-c (through the session manager 106) and various ones of the databases 11 Oa-c.

The network manager 112 handles access to and from any of the network resources 114a- c. The network resources 114a-c may include hardware and software for Local Area Networks, such as Ethernet connections, Wide Area Networks, telephone connections, TCP/IP connection or connections to the Internet. The network manager 112 can also be used to access data stored on different types of network systems. The network manager 112 may be implemented in a conventional manner using the Windows 95 "Winsock" module. Requests by one of the applications 102a-c for one or more of the network resources 114a-c is formatted by the network manager 1 12 into an appropriate Winsock call.

The session manager 106 may also implement or handle access to other system resources 116. These other system resources 1 16 may include, for example, a configuration control module to provide some level of configuration control and/or security in support of licensing software and/or managing multi-level access to shared data.

The backbone 100 may also include a memory manager 107. The memory manager 107 handles memory transactions and management for the system resources/services 108, 1 12, 116.

The session manager 106 is preferably implemented as two DLL's (dynamically linked libraries, in Windows). The first DLL may be initially loaded by the first one of the applications 102a-c that requests access to a resource handled by the session manager 106. The second DLL implements the functions of the session manager 106. The purpose of the first DLL is to load and initiate the second DLL if and when one of the applications 102a-c requests service. In this manner, a small first DLL can be retained in memory, while a larger second DLL may be swapped in and out of memory as needed.

FIG. 3 is a flow chart 140 that illustrates steps that each of the applications 102a-c executes in order to initialize and connect with the backbone 100. The process begins at a test step 142 where it is determined if the backbone 100 is available. If the backbone 100 is not available (i.e., has not yet been loaded), control passes from the step 142 to a step 143 where a process is implemented to launch the backbone 100. If, on the other hand, it is determined at the step 142 that the backbone 100 is available, then the particular one of the applications 102a-c that is call (i.e.. connecting with) the backbone 100 simply registers with the backbone 100, as shown at a step 144.

Performance of the steps 142-144 results in the return of a registration identification.

Each of the applications 102a-c that wishes to use the backbone 100 is assigned a unique registration identification that may be used for identifying information and data passed between the applications 102a-c and backbone 100. Execution of the step 143 that starts the backbone automatically registers the calling application. Once the registration identification is complete. the calling application may proceed with normal operation.

FIG. 4 is a flow chart 150 that illustrates determining if the backbone 100 available at the step 142 of FIG. 3. Operation begins at a test step 151 where it is determined whether the backbone 100 is available by checking if the DLL corresponding to the session manager 106 is loaded. If not, then control transfers from the step 151 to a step 152 where the value NULL is returned, thus indicating that the backbone 100 is not available. If, on the other hand, it is determined at the step 151 that the backbone 100 is loaded, then control transfers from the step 151 to a step 153, where it is determined which of the services requested by the calling application are available. Following the step 153 is a step 154 where the backbone 100 then returns a "YES" (i.e., TRUE) and a list of services that are available to the calling application.

In determining the list of services that are available, the backbone 100 may secure or lock-out services that should not be made available to certain applications, even though those services are available to other applications. Thus, for example, the backbone 100 could limit the number of applications that can invoke a particular service at any given point in time in order to comply with a per-user license for particular software.

In a preferred embodiment, the list of services available that is returned at the step 154 is represented by a binary code. Thus, the data manager 108 could be indicated by a code of 0x01 and the network manager 112 could be indicated by a code of 0x02. By using a unique bit marker for each service, requests for multiple services may be represented by a Boolean OR of the words representing each individual service. The same codes may be used by the session manager 106 to specify which services will be made available to the applications 102a-c. FIG. 5 is a flow chart of the steps taken when the session manager 106 is started. Operation begins at a step 171 where memory is allocated by the backbone 100 for use in providing services to the applications 102a-c. Following the step 171 is a step 172 where the data definition tables are set up. The data definition tables are used for accessing data through the data manager 108 and are described in more detail below. Following the step 172 is a step 173 where the system data group table is set up. The system data group table is also used for accessing data through the data manager 108 and is described in more detail below. Following the step 173 is a step 174 where the requested services are loaded. As indicated by an arrow 175, the step 174 is repeated until each requested service is loaded.

Referring to FIG. 6, the memory manager 107 uses two types of data areas (locations in memory where the data is stored), a system data area 182 and a global data area 184. The system data area 182 maintains system-related tables, data, etc. for the backbone 100. The global data area 184 contains memory for communication of data among applications 102a-c and system resources 108, 112, 1 16. A request for data from one of the applications 102a-c may cause the session manager 106 to first identify available memory in the global data area 184. The session manager 106 may then invoke the data manager 108, informing the data manager 108 of the data requested and of the location in the global data area 184 where the data should be stored. The data manager 108 then stores the data (through the memory manager 107) in the global data area 184.

Referring to FIG. 7, a schematic block diagram 200 illustrates in detail operation and interaction of the memory manager 107 and the data manager 108. The data manager 108 receives registration information and data requests from the session manager 106 . The data manager 108 provides and receives data to and from the session manager 106. As discussed above, all data read and write operations by the applications 102a-c are processed by the session manager 106. Therefore, the registration information, the data requests, and the data that is provided by the session manager 106 to the data manager 108 originates with a request by one of the applications 102a-c to the data manager 106. Similarly, data is provided by the data manager 108 to the session manager 106 at the request of one of the applications 102a-c and ultimately is provided by the session manager 106 to the requesting one of the applications 102a- c. The nature and form of information communicated between the session manager 106 and the data manager 108 is set forth in more detail below.

The System Data Area 182 of the memory manager 107 contains three tables that are used by the data manager 108: the System Data Group Definition Table 202, the System Data Group Table 203, and the Application Data Group Tables 204. A data group is a structure used by an application to access data through the data manager 108 and is provided in the form of: <DATA GROUP IDENTIFIER> = <DATE GROUP DEFINITION

The data group identifier is used by an application to reference and specify the data while the data group definition indicates to the data manager 108 where to find the data from within the data bases 1 lOa-c. The application data group tables 204 contains data group structures that correspond to specific applications that have registered with the backbone 100. Each of the applications 102a-c can have its own data group table within the application data group tables 204. An application's data group table defines the data groups specifically used by a particular one of the applications 102a-c. The System Data Group Table 203 contains default data groups that are used by applications that have registered with the backbone 100 but have not provided their own application data group table. That is, if an application does not have its own application data group table stored in the application data group tables 204, then the data manager defaults to the system data group table 203 for that application.

The system data group definition table 202 correlates each application with a specific application data group table stored in the application data group tables 204. As discussed above, an application that registers with the backbone 100 receives a unique identifier. The system data group definition table 202 uses this unique application identifier to match a specific application with a specific application data group table stored in the application data group tables 204. Part of the registration process can include the application passing to the session manager 106 the application's data group table. The session manager 106 would then pass this table to the data manager 108 which would then make appropriate calls to the memory manager 107 to include the table information in the system data area 182.

A data request that is made by an application through the session manager 106 is provided by the session manager 106 to the data manager 108. The data request from the session manager 106 is in the form of a data group name and includes the identifier of the requesting application.

The data manager 108 processes this request by first translating the data group into the appropriate data definition. Then the data manager 108 makes a call to the memory manager 107 to determine if the specific data that is requested has been previously requested and is therefore already available in the global data area 184. If so, then the data manager returns a handle (a conventional doubly indirected pointer) that points to the section in the global data area 184 that corresponds to the data. The application can then use this handle to access the requested data in the global data area 184. If, on the other hand, the requested data is not already stored in the global data area 184, then the data manager makes an appropriate request to one or more of the data bases 1 1 Oa-c in order to access the data. The data that is obtained from the data bases 11 Oa-c by the data manager 108 is passed on to the memory manager 107 to be loaded into the global data area 184.

Data may also be modified by an application. Assuming that an application is authorized to modify particular data, then the application notifies the data manager 108 that the particular data in the global data area 184 has been modified. The data manager then copies the data from the global data area 184 back to one or more of the data bases 11 Oa-c. In addition, the data manager 108 may notify other applications that use the same data that the data has been modified. An application that has been so notified can then take whatever action is appropriate for that application.

Referring to FIG. 8, a flow chart 210 illustrates operation and interaction of the memory manager 107 and the data manager 108 when an application requests data. Processing begins at a first step 212 where the application presents a data request to the session manager 106 and the session manager 106 passes the data request to the data manager 108. As discussed above, the data access request is in the form of a data group identifier and includes an identification of the specific application making the data access request and includes information indicating whether the request is read-only or read/write. Following the step 212 is a test step 214 where the data manager 108 determines if the requesting application has a specific application data group table stored in the application data group tables 204. The memory manager 107 and data manager 108 use the system data group definition table 202 to determine if the requesting application has its own application data group table stored in the application data group tables 204. If the application does not have its own application data group table, then control passes from the step 214 to a step 216 where the data manager 108 takes appropriate steps in order to use the system data group table 203. As discussed above, when the requesting application does not have its own data group table stored in the application data group tables 204, the system data group table 203 is used.

If it is determined that the step 214 that the application has its own application data group table, then control transfers from the step 214 to a test step 218 which determines if the applications data group table is loaded in the system data area 182. Note that it is possible, especially during initial processing, for an application to have initially registered with the backbone 100 and specified its own application data group table but that the application data group table has not yet been loaded into the system data area 182.

If it is determined that the step 218 that the application data group table is not loaded, then control transfers from the step 218 to a step 220 where the specific table of the requesting application is loaded in the application data group tables 204. If, on the other hand, it is determined as a step 218 that the application data group table is already loaded, then control transfers from the step 218 to a step 222. Note that the step 222 is also reached following the step 216 and also following the step 220. At the step 222, the data manager 108 interprets the request made by the application through the session manager 106. Interpreting the request involves examining the data group specified in the request and using the data group definition (either from the system data group table 203 or the application data group tables 204, as appropriate) to determine the specific data requested by the application. Following the step 222 is a test step 224 where it is determined if the requested data is already stored in the global data area 184. If not, then control transfers from a step 224 to a set of steps 226-228 where the data manager 108 obtains the data from one or more of the data bases 1 lOa-c by issuing a data base query at the step 226, storing the information in the global data area 184 at the step 227, and making a call to the memory manager 107 to update the memory information to indicate that the data that was retrieved and stored at the steps 226, 227 has been stored in the global data area

184.

If it is determined that step 224 that the requested data is already stored in the global data area, then control transfers from the step 224 to a step 230. Note that the step 230 is also reached following the step 228 so that the step 230 is performed once the data is in the global data area 184 in either case. At the step 230. the memory manager 107 updates the memory manager bookkeeping information to indicate that the requested data in the global data area 184 is being accessed by an application. This bookkeeping information also includes whether the requesting application has requested read-only or requested read/write. This bookkeeping is performed in a conventional manner and is useful when data needs to be swapped out (i.e., removed) from the global data area 184. Data is removed from the global data area 184 when it is not being accessed by any applications. Therefore, the bookkeeping information that is updated at the step 230 includes the list of applications that are accessing the requested data. An application that no longer needs specific data makes a call to the data manager 108 which calls the memory manager 107 to indicate that the calling application no longer needs the specific data.

Following the step 230 is a step 232 where the requested data is returned by the memory manager 107 to the data manager 108. The data manager 108 then provides the data to the session manager 106 which ultimately passes the handle onto the requesting application. While the invention has been disclosed in connection with the preferred embodiments shown and described in detail, various modifications and improvements thereon will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present invention is to be limited only by the following claims.

Claims

What is claimed is:

1. A computer system, comprising: a database containing stored data; an application adapted to provide a user interface to a user operating the computer system, said application having a first view of the data stored in said database; a data manager adapted to interface with said database to retrieve the data stored in said database, said data manager having a second view, different from the first view, of the data stored in said database; and a session manager interfaced between said application and said data manager, said session manager being adapted to receive from the application a first request for data formatted according to the first view of the data, translate the first request for data into a second request for data formatted according to the second view of the data, and forward the second request for data to the data manager, to thereby enable said application to access the data stored in the database without requiring the application to have knowledge of the second view of the data.

2. The computer system of claim 1, wherein said session manager is further adapted to receive from said data manager a first response containing a first subset of data formatted according to the second view of the data, translate the first response containing the first subset of data into a second response containing the first subset of data formatted according to the first view of the data, and forward the second response containing the first subset of data to the application.

3. The computer system of claim 2. further comprising a memory manager for allocating memory space between components of the computer system, and having at least an application data group table defining data groups specifically used by the application according to its first view of the data, a system data group table containing default data groups, and a system data group definition table indicating to the data manager where to find the data from within the database, and wherein, when the system manager receives from the application the first request for data formatted according to the first view of the data, the system manager obtains from the memory manager one of a data group specified for the application from the application data group table and a default data group from the system data group table, and uses the data group to translate the first request for data in to the second request for data formatted according to the second view of the data, and wherein when the data manager receives the second request for data formatted according to the second view of the data, the data manager obtains from the memory manager the system data group definition table and uses information provided thereby to access the data from within the database.

4. The computer system of claim 3, wherein the application has a unique identifier, and the system data group definition table uses this unique application identifier to match the specific application with a specific application data group stored in the application data group table.

5. The computer system of claim 3, wherein the memory manager comprises a system data area containing the application data group table, system data group table, and system data group definition table, and a global data area available for storage of data used by the computer system.

6. The computer system of claim 1, further comprising: a network manager to facilitate communication between the computer system and at least one of another computer and a network of computers.

7. A method of providing data from a database to an application, comprising: formulating a query at an application level according to a first view of a data structure; communicating the query to a system manager; the system manager retrieving a data group from one of an application data group table and a default data group table stored in a memory manager and using the data group to translate the query into a data query understandable by a data manager; and transmitting the data query to the data manager; and obtaining data from a database in accordance with the data query form the system manager.

8. The method of claim 7, further comprising: returning data from the database to the data manager; storing the data in a global data area; and returning data to the application after translating the data returning from the database in accordance with parameters associated with the data group.

9. A computer system, comprising: a plurality of databases; a plurality of applications adapted to provide user interfaces to a user operating the computer system; a data manager adapted to interface with said database to retrieve the data stored in one or more of said databases in response to a query; a session manager interfaced between said applications and said data manager, said session manager being adapted to receive queries from the applications, said queries being formatted in a manner specific to the application irrespective of the data structure of the data in the data bases; and a memory manager for allocating memory space between components of the computer system, and having at least an application data group table defining data groups specifically used by the applications, a system data group table containing default data groups used by the applications, and a system data group definition table indicating to the data manager where to find the data from within the database; wherein, when the system manager receives from a querying application a query for data formatted in a manner specific to the application, the system manager obtains from the memory manager one of a data group specified for the querying application from the application data group table and a default data group from the system data group table, and uses the data group to translate the query for data into the request for data formatted in a manner understandable by the data manager, and wherein when the data manager receives a properly formatted request for data the data manager obtains from the memory manager the system data group definition table and uses information provided thereby to access the data from within the database.

10. A system manager, comprising: an input layer for communicating with application programs; a translation layer adapted and coded to translate queries submitted by the applications programs into queries readable by a data manager; and an output layer for communicating translated queries to the data manager.

11. The system manager of claim 10, further comprising a memory layer for communicating with a memory manager to obtain from the memory manager data groups associated with the applications submitting queries to facilitate translation of the queries prior to outputting the translated queries to the data manager.

12. The system manager of claim 10, wherein the output layer further is adapted to receive data from the data manager in response to a submitted query, and wherein the input layer is adapted to transmit data to the appropriate application.

13. The system manager of claim 12, wherein the translation layer is adapted to translate data received through the output layer from the data manager prior to transmitting the data to the appropriate application through the input layer.