Method for adapting a relational database management system so that it can address foreign information
BACKGROUND OF THE INVENTION 
     This invention relates to a method for adapting a relational database management system (DBMS) in a digital computer so that the system will have the ability to utilize foreign information. More particularly, this invention relates to a method for adapting a DBMS so that it can utilize data which is foreign in its location, foreign in its file format, or foreign in its order. These forms of foreign data may, by way of example, include real time data, such as data concerning a process that is being monitored in real time; distributed data, such as data that is stored at different physical locations in a large industrial plant; distributed real time data, which presents both the problems of real time data as well as the problems of distributed data; data which is in a format which is foreign (different from) the format which is required for the operation of the DBMS; data which is in a format which is compatible but which is so ordered that it is not useful to the DBMS; and computed data, data which is not stored as files but is computed at the time it is needed to fulfill a query of a client, a user of the system. 
     For the purposes of this description a relational database management system (DBMS) is defined as a system for managing data in which data is organized in one or more rectangular tables of rows and columns, and wherein the contents of each column is data of the same type throughout all of the rows of the column. Thus, in a relational database the data organization fits set theory, and the records in different files can be linked (cross-referenced) by the content of columns that are common in the different files. 
     While there are many relational database management systems available, none of these systems is able to use foreign data without a conversion of the data into an appropriate format by entry of the data into a standard file of the database prior to the need to query the data. This placing of the data in the proper format becomes particularly difficult when it is necessary to utilize data which is being obtained in real time and which must be queried in real time. In such cases, it is important to have the ability to query such data without taking the time to first incorporate it into the database in the desired format. It is therefore an object of this invention to provide a method for adapting or constructing a relational DBMS to make it capable of incorporating foreign data so that the normal DBMS functions, such as reading and writing that data, may be accomplished. 
     More particularly, it is an object of this invention to provide a method for adapting or constructing a relational DBMS for incorporating real time data for use by the DBMS. 
     Since there are many good commercially available DBMSes, it is particularly useful to adapt an existing one for the incorporation of foreign data, in some circumstances one might incorporate the present invention in the construction of a relational DBMS from scratch. Therefore, since the same steps are required in either case, the words &#34;adapting&#34; and &#34;constructing&#34; are used interchangeably in this description, as they are applied to the invention. 
     SUMMARY OF THE INVENTION 
     To accomplish the objects of this invention there is provided a method and,means for adapting a relational database management system, for a computer so as to provide it with the ability to access foreign information for the examination and processing of that information by the DBMS. In this connection, the operating system being used in the computer is provided with a kernel which includes a driver which simulates for the DBMS a standard file format for the foreign information that is to be accessed. The information itself is obtained by a server activated by the driver. The server gets the foreign information and passes it back for the simulated file so that the simulated file can be addressed by the normal DBMS&#39;s queries. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     In the drawings, FIG. 1 is a block diagram showing the organization of the novel relational database management system of the present invention, as it is applied to the use of real time information by a standard DBMS where the index file for a relation is kept in a real DBMS file. 
     FIG. 2 is a diagram of the scenario illustrated by FIG. 1 and the program described below. 
     FIG. 3 is a diagram of the scenario described in the following description as &#34;Direct with Virtual Index&#34;. 
     FIG. 4 is a diagram of part of the scenario described in the following description as &#34;Indirect with Simulated Index&#34;. 
     FIG. 5 is a diagram of another part of the scenario described by FIG. 4. 
     FIG. 6 is a diagram show which tells the DBMS what to do. 
     FIG. 7 is a diagram showing the flow through the driver from the DBMS corresponding to blocks 26 and the bc side of block 32. 
     FIG. 8 is a diagram showing blocks 34 and the bs side of block 32 as well as block 36. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     For the purpose of describing the invention, the drawing in conjunction with the present specification describes a system which makes real time distributed data accessed by input/output (I/O) devices or systems 12 and 14 available for collection and review by a commercially available relational DBMS running on a commercially available operating system without substantial modification being necessary to the DBMS. Additionally, it is desired that no impact to the structure or to the performance of the real time portion should result from this relational view. The data should also be editable through direct relational views using standard query language. 
     The real time I/O devices or systems 12 and 14 are connected to networks for accomplishing the input and output process, identified as Real Time Net I/O #1 and Real Time Net I/O #2 and identified by the reference characters 16 and 18, respectively. Those networks are operated by a Real Time Processor 20. The processor 20 of the present system is, in turn, under the control of the Logical Network Access System 22, which serves the function of requesting the real time data which the DBMS is addressing. The Logical Network Access System may, for example, be one of the well known interconnect systems such as Ethernet or SCSI. Alternatively, this real time system may be a system such as that shown in U.S. Pat. No. 4,482,980, which accesses a large amount of real time data that is distributed in a large number of widely scattered locations. More particularly, the apparatus of the figure could be the host computer 14 of the patent. 
     For the purposes of describing the present invention, U.S. Pat. No. 4,482,980 is hereby incorporated as part of this specification. 
     As shown, the Network Access System 22 is under the control of the Operating System File Server Interface 24, which, for example, may be the file server interface of a Unix operating system in a computer using an Intel 80386 processor. 
     As shown in the drawing, a commercial DBMS, such as Informix, which is available from Informix Software, Inc., is represented by the block 26 and may be utilized in the environment of the Unix operating system. 
     The operating system, as is the usual case, takes care of handling the data and also takes care of the control of the disc drives, such as drive 28, as by means of a driver 30 for the disc drives 28. 
     In order to use a commercially available relational DBMS such as Informix to process the real time data, it is necessary to add the software shown as the File I/O Wrapback Server 32, which for convenience will be known as the &#34;Backdoor Driver&#34;,and the Real Time Data Access Programs 34, (The Backdoor Server) which in the scenario being illustrated, requires a Shadow file 36. The shadow file provides the relationship between tags which identify the data to the database and the information needed to get desired real time data from the real time system. 
     The File I/O Wrapback Server 32 (the Backdoor Driver) serves the function of making the real time information or data look like a normal file to the DBMS so that the user or client may use standard DBMS query language on the real time data. 
     The Real Time Data Access Programs 34 serve the purpose of obtaining the real time data from the real time system through the Logical Network Access System 22. Thus, these programs talk directly to the real time system and obtain the data requested by the backdoor so that the data can be put in standard DBMS form by the backdoor. 
     The scenario being illustrated by the drawing and by the program disclosed subsequently may be characterized as follows: 
     Direct With Real Index 
     In this scenario the index for a relation is kept in a real DBMS file. However, the data file is trapped by the file I/O wrapback server. In this case the data records have a regular file associated with them but the real time data server augments and changes the data as it is read and written. The file maintained by the real time data server must contain the key data and physical or simulated room for the elements of the tuple (relational database row or record) which are to be extracted or filled in. Then, when the data is accessed the real time server can by record number alone determine the augmentation or extraction which is to occur and route the request again to the real time system for execution. This scenario provides for the simplest real time data servers. 
     This scenario is shown in FIG. 2 which indicates that the first step is to read the file by record number, the second step is to perform real time data augmentation and the last step before the end is to return the data. 
     There are a number of other scenarios which can be used in accessing foreign data. Several of the possibilities are set forth below. 
     Direct with Virtual Index 
     In this scenario the file I/O wrapback server (backdoor) acts as an interceptor of the DBMS&#39;s operation and appears to the operating system as two devices on which there are multiple files. The first of these devices responds to all functions that a file normally would (READ, WRITE, SEEK). The second device relays these requests and their data to the real time data access programs. These real time data access programs simulate files of data and their indexes so that the DBMS can request data as if it were stored in an ISAM file structure. The real time data access programs can identify the record being requested because they presented the DBMS with the record number of the record to ask for in the simulated pages of the index. Then, when the data is actually accessed the real time data server makes a request of the real time system to collect or store the appropriate data. This scenario allows for access to more data than one has disk space to hold the indexes for. 
     This scenario is shown in FIG. 3 in which the decision as to which operation type is to be carried out is the first step, followed by the fetch of data from real time using last ISAM key returned when the operation type is &#34;data&#34;. When the operation type is &#34;index&#34; then the ISAM file structure is simulated. 
     Indirect with Simulated Index 
     In this scenario the amount of data to be collected and stored exceeds the DBMS&#39;s capacity to do so. However, in many instances it is possible to create non-relational storage which will have the capacity to hold the data as well as the performance to update it. Usually the data is of the form of barrels and is accessed as a matrix with one index being cyclic. By mapping the two dimensions of a barrel into simple row/column indexes through simple relations, the barrel becomes an index invariant structure. Usually only one row of mapping relation needs to be updated every time any values are changed in the actual data. Therefore, the DBMS can be presented a simulated index for the non-existent row and column fields of the tuples, and then the data when accessed can be augmented in the same way. This scenario allows large quantities of data to be stored quickly in a compressed format, without indexes. It will be fast and disk efficient. A variant of this scenario uses a real disk table where the location of the data is known, and it is written to directly by the real time access program without the file I/O wrap back server. 
     This scenario is shown in FIG. 4 and FIG. 5. FIG. 4 shows the first step as a decision as to the type of operation, &#34;data&#34; or &#34;index&#34;. If it is &#34;data&#34; the data is fetched from the barrel using the last ISAM key returned, whereas if it is &#34;index&#34; the ISAM data file structure is simulated. FIG. 5 shows that the data is obtained from real time and put in barrels. 
     The programs which are reproduced below have been utilized in a microcomputer with an Intel 80386 processor, in conjunction with a Unix operating system, and an Informix database system to access real time data in environments such as that described in the patent referenced above. The programs associated with the Backdoor and the Real Time Data Access Programs are written in &#34;C&#34;. These programs can, in general terms, can be described as accomplishing the following tasks: 
     1. bkdoor.h This is the &#34;include&#34; file for common data structures. 
     2. bkdoor.c This is the actual program that is linked to Unix libraries to form the new Unix kernel required. 
     3. bs/config Program for configuring Unix. 
     4. bc/config Program for configuring Unix. 
     5. BKSERVE.C This program is the Real Time Data Access Program and is exemplary of a program for getting the data from the real time system. It gets requests for data from the Backdoor, connects to the Logical Network Access System to get real time data, and passes the data to the &#34;backdoor&#34;. 
     Four programs are presented which tell the DBMS what to do. These programs are written in 4GL (the fourth generation Informix command language) and, in the respective order in which they are listed below, accomplish the following tasks. 
     1. Makes table for shadow file. 
     2. Turns table into shadow file which makes backdoor connection. 
     3. Tells where real time data is and puts records in shadow file. 
     4. Causes DBMS to go out and get real time data and returns values requested 
     The following programs, written in &#34;C&#34; are associated with the Backdoor and serve to make the real time information being accessed by the access program look like a standard format to the DBMS. ##SPC1## 
     In FIG. 6 the four programs of the previous listing which tell the DBMS what to do are shown in flow diagram form so that the flow of those programs is evident. 
     Thus, on the left-hand side of FIG. 6 the first vertical path shows the creation of a table, BKTRIAL, for the shadow file. In the second vertical path from the left the program turns that table into a shadow file and makes the backdoor connection. In the next vertical path, third from the left, the program tells where real time data is (tagged as C60S1 and C60S2) and puts records in the shadow file. Then in the right-hand vertical path the DBMS goes out and gets real time data and returns the values requested for display. 
     In FIG. 7 the flow of the program listing for the backdoor driver is shown with the bcread shown in the left-hand vertical path and the bcwrite shown in the right-hand vertical path. The various blocks in this diagram will be recognized in reference to the preceding program listing. With the bcread, which handles a read from a client, a read command is sent to the server, then the bcread routine sleeps until the server wakes it, at which time it copies the read data from the bk --  buf, put there by the server. In handling a write from the client the write command is sent to the server, then the routine sleeps until awakended by any &#34;wakeup client&#34; block in FIG. 8. 
     In FIG. 8 the flow of the program listing for the backdoor server is shown. This is the program listed as BKSERVE. The program starts in the right-hand vertical path by opening the needed device files after which the device driver is told to map the client. The requests for data are then processed by reading from the server block. The same routine is used whether the server is reading the command or is reading to service a client write. Thus, the BSREAD block in the lower right-hand corner is reading the command and it is the same as the BSREAD block in the middle of the drawing which is servicing a client write as determined by the decision block labeled &#34;IF SB --  READ&#34; and the path labeled &#34;NO&#34;. If a client read is indicated by the &#34;YES&#34; path from that decision block the vertical path on the left hand side of the drawing is followed. The program gets the point from the real time system and fills the read real time value into the returned record which is then processed by a BSWRITE in the block at the lower left hand corner of the Figure.