Abstract:
One embodiment of the present invention provides a system that transparently maps a request to open a data file. First, the system receives a request from a user or client application to open the data file. Next, the system determines from file meta information that the file is a relational data file, and proceeds to transparently map the file open operation to a corresponding relational database operation by discovering a database service configured to manage the relational data file and then sending a request to open the relational data file to this database service. By transparently mapping the file open operation to the corresponding relational database operation, the system allows an underlying data file to be changed to a relational data file without changing the way the user interacts with the client application and/or data file.

Description:
BACKGROUND 
     Related Art 
       [0001]    The present invention generally relates to client-server computer systems. 
         [0002]    Computer-based applications often access data which is stored in files. For example, a financial application typically operates on data which is stored in a “company file.” As such applications become increasingly more sophisticated, significant advantages can be gained by moving from a simple company file to a more-sophisticated database system, which is controlled by a database server. Using a more-sophisticated database system can provide improved performance, reliability, and scalability, especially for larger company files and simultaneous users. 
         [0003]    However, it is typically necessary to configure a database server to operate in specific modes depending upon location of the data and the types of file accesses which are desired. For example, it may be necessary to configure the database server to access a remote file, or to support multi-user accesses to a file. This can be a problem because application users are typically used to existing file-based data operations, and are not very knowledgeable about the technical details related to invoking and/or configuring a database server. Hence, the desire to preserve a simple user experience may limit the improvements that can be incorporated into a system. 
       SUMMARY 
       [0004]    One embodiment of the present invention provides a system that transparently maps a request to open a data file. First, the system receives a request from a user or client application to open the data file. Next, the system determines from file meta information that the file is a relational data file, and proceeds to transparently map the file open operation to a corresponding relational database operation by discovering a database service configured to manage the relational data file and then sending a request to open the relational data file to this database service. By transparently mapping the file open operation to the corresponding relational database operation, the system allows an underlying data file to be changed to a relational data file without changing the way the user interacts with the client application and/or data file. 
         [0005]    In a variation on this embodiment, the relational data file and the database service are hosted on the same computing device. 
         [0006]    In a variation on this embodiment, the relational data file and the database service are hosted on different computing devices. 
         [0007]    In a further variation, the client application is hosted on: the same computing device as the relational data file; the same computing device as the database service; or on a computing device that hosts neither the relational data file nor the database service. 
         [0008]    In a variation on this embodiment, instances of the client application can include instances of the database service, potentially leading to multiple simultaneous instances of the database service. In this embodiment, one instance among these multiple instances manages access to the relational data file, and the system discovers this managing database service from among the multiple database service instances. Subsequent requests by instances of the client application to access the relational data file are then handled by this managing database service. 
         [0009]    In a further variation, the system discovers the managing database service by:
       determining whether the computing device hosting the relational data file also hosts the managing database service;   determining whether the computing device hosting the client application also hosts the managing database service;   using a configuration file in proximity to the data file to assist in finding the managing database service; and/or   using a network query and/or broadcast request to discover the managing database service.       
 
         [0014]    In a further variation, the managing database service changes based on the behavior and actions of the user, the client application, and the multiple instances of the database services. 
         [0015]    In a further variation, the request specifies that a given instance of the database service always serves as the managing database service. 
         [0016]    In a further variation, if no managing database service is found, the system configures a local instance of the database service associated with the client application to become the managing database service. 
     
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0017]      FIG. 1  illustrates a client application and database management system (DBMS) service executing on a computer in accordance with an embodiment of the present invention. 
           [0018]      FIG. 2  is a flow chart illustrating the process of opening a relational data file by connecting to a DBMS in accordance with an embodiment of the present invention. 
           [0019]      FIG. 3  illustrates a system configuration in which a client application and relational data file are located on separate computers in accordance with an embodiment of the present invention. 
           [0020]      FIG. 4  illustrates a system configuration in which multiple client applications communicate with one computer that hosts the relational data file locally in accordance with an embodiment of the present invention. 
           [0021]      FIG. 5  illustrates a system configuration in which multiple users access a remote relational data file through a DBMS service on a separate computer in accordance with an embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0022]    The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims. 
         [0023]    The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer readable media now known or later developed. 
       Performance and User Interface Trade-Offs 
       [0024]    As mentioned previously, as applications become increasingly more sophisticated, significant advantages can be gained by moving from a simple company file to a more-sophisticated database system controlled by a database server. Using a more-sophisticated database system can provide improved performance and scalability, especially for larger company files and simultaneous users. 
         [0025]    However, typical system users may not be familiar with installing, configuring, and maintaining a more-complex database system. Many applications that incorporate databases are either single-user applications that use a database embedded into an application, with little or none of the database complexity directly exposed to the end-user, or use a heavy-weight multi-user database with an involved set-up procedure typically managed by a system administrator. In the latter case, such heavy-weight databases typically involve multiple files, and are not mobile. The system in one embodiment of the present invention provides the performance and scalability of a client-server database system while maintaining a database-transparent user experience with minimal or non-existent administration needs. 
         [0026]    In typical non-database systems, applications store user data in files, and the user can browse through a file structure to select a data file and/or to invoke a client application related to the data file. This data file may be located on a local computing device, or may be present on a remote computing device but transparently displayed using a file browser run on the local computing device. 
         [0027]    One embodiment of the present invention maintains this experience of “opening an ordinary file” on a local or remote file system using a standard file open user interface, but changes the data file to be a relational data file, and enhances the client applications to interact with a database management system (DBMS) that manages and operates upon the data in the relational data file. Multiple users in this system can continue to think of the relational data file as a “normal” file, as in previous systems, and can perform actions such as individually accessing and copying the file, while the system transparently invokes, maintains, and connects the client applications to a DBMS service that manages the relational data file. Hence, the system hides from the end-user the presence of the client-server database, thereby presenting unchanged system usability and maintaining a user experience of a single-file data management system yet also providing enhanced database functionality. 
         [0028]      FIG. 1  illustrates a client application  104  and DBMS service  106  executing on a computer A  102 . The client application  104  interacts with the DBMS service  106 , which provides access to a relational data file  108 . 
         [0029]      FIG. 2  is a flow chart illustrating the process of opening a relational data file by connecting to a DBMS service. First, the system receives a request to open a relational data file (step  202 ). This request can, for instance, be generated when a user selects a data file from a file browser, thereby triggering a client application associated with the file type of the data file by the operating system (e.g. Microsoft™ Windows™). Alternatively, the request may also be generated by the user selecting the file from within a client application. Upon determining that the data file is a relational data file, the system then determines a set of parameters for the relational data file and a DBMS service, if present (step  204 ). For instance, the client application can use an operating system application programmer interface (API) to ascertain whether the relational data file is local to the computer or on a remote server. 
         [0030]    In one embodiment of the present invention, the system uses the location of the relational data file to determine whether an active DBMS service managing the file is already available on the computer hosting the relational data file. Alternatively, the system can also determine whether such a service is already active elsewhere by checking on the machine hosting the client application, using a network query or broadcast, and/or checking a configuration file in proximity to the relational data file. 
         [0031]    If the system finds an active DBMS service for the relational data file (step  206 ), the client application proceeds to communicate with the DBMS service and attempt to access the relational data file through the DBMS using an appropriate database API (step  210 ). Note that connecting to the DBMS via the database API may involve additional steps such as the exchange of user credentials and/or other information. In one embodiment of the present invention, if the system does not discover an active DBMS service, the system launches an instance of the DBMS service on the computer hosting the client application (step  208 ), and then proceeds to access the relational data file by communicating with the newly-launched DBMS service (step  210 ). Note that some of these steps may vary in complexity depending on usage scenarios. 
       Single-User Scenarios 
       [0032]    In the simplest usage scenario (shown in  FIG. 1 ), the client application  104 , the DBMS service  106 , and the relational data file  108  are installed on a single system and accessed by a single user. In this scenario, the system may only search for the DBMS on the local machine (computer A  102 ), and only launch the DBMS service  106  when the client application  104  actually accesses the relational data file. Note that the system may balance the resource usage of the client application  104  and the DBMS  106  to optimize overall application performance on computer A  102 . 
         [0033]      FIG. 3  illustrates a more complex single-user usage scenario in which the relational data file  108  is no longer co-located with the client application  104 , but is instead stored on a remote computer B  302 . This scenario might occur, for instance, if the relational data file is located on a separate file server with regular backups. In this scenario, the system may again proceed to use or launch a local instance of the DBMS service  106  on the same computer as the client application  106 . While remote access to the relational data file may cause degraded performance due to network communication, other benefits from such a system organization may make this a desirable arrangement. 
       Multiple-User Scenarios 
       [0034]    The system can also transparently manage multiple-user scenarios.  FIG. 4  illustrates a system configuration in which multiple instances of client application  104  communicate with one computer A  102  that hosts the relational data file  108  locally. 
         [0035]    In one embodiment of the present invention, an instance of the DBMS service  106  can be installed in combination with each installed instance of the client application  104 . Such a configuration allows different instances of the DBMS service  106  to manage access to the relational database file depending on access patterns, system operations and failures, and other factors. Note that typically only one instance of the DBMS service can actively manage access to the relational data file at a time, leaving most of the DBMS service  106  instances in  FIG. 4  inactive or un-launched during operation. 
         [0036]    In one embodiment of the present invention (shown in  FIG. 4 ), a user or system administrator can decide to select one computer (such as computer A  102 ) to permanently host the relational data file  108  and the managing DBMS service  404  for this file, for instance by selecting an option of “host my company files for multiple-user access” in the instance of the client application  104  local to computer A  102 . Other instances of the client applications  104  attempting to access the relational data file  108 , such as those on computer B  302  and computer C  402 , then follow the process shown in  FIG. 2 . When these client applications attempt to open the relational data file, they check whether the computer hosting the relational data file (computer A  102 ) also hosts a managing DBMS service  404  for the file, and proceed to find and communicate with computer A&#39;s  102  DBMS service  106 . Note that the system can bias the resources or system parameters of computer A  102  to improve the performance of the DBMS service  106  if computer A  102  is expected to primarily provide data services, and not actively run an instance of the client application  104 . 
         [0037]    In a further embodiment, the first client application  104  to open the relational data file  108  and thereby activate a managing DBMS service  404  on the computer (hosting the prompting client application) takes charge exclusively of managing the relational data file  108 , until such time that the managing client application  104  is terminated, the corresponding computer (hosting either the relational data file or the managing DBMS service) fails, and/or some other prompt for release occurs. 
         [0038]      FIG. 5  illustrates a system configuration in which multiple users access a remote relational data file  108  through a DBMS service  106  on a separate computer A  102 . If the client application  104  on computer A  102  attempts to access the relational data file  108  on computer B  302  first, the DBMS service instance  106  on computer A  102  activates to provide access to the relational data file  108 . A subsequent access attempt by the client application  104  on computer C  402  finds that the file is already managed by the managing DBMS service  404  on computer A  102 , and results in a connection from the client application  104  on computer C  402  to the managing DBMS service instance  404  on computer A  102 . If at some later point computer A  102  fails, the client application  104  on computer C  402  might proceed to launch or activate the DBMS instance  106  on computer C  402  and take over the management of the relational data file  108  on computer B  302 . 
         [0039]    Note that preserving a transparent non-database user experience in the previous configuration may involve a performance penalty. For instance, the configuration in  FIG. 5  may involve substantial time delay and network traffic, because data accesses by the client application  104  on computer C  402  need to travel first through the DBMS service  106  on computer A  102 , then to the actual file on computer B  302 , and back. Note also that while no assumptions can be made about where an active DBMS service may be running, users do need to know the location of the data file to properly access their data and thereby invoke the DBMS system. However, since knowing the location of the file follows with the existing single-data-file-based user experience, this presents no additional overhead. 
         [0040]    Note that the technique in the present invention differs from an approach in which the data file is replaced by a stub file that contains information for locating a DBMS server. The relational data file in the present invention still includes the actual data used by the DBMS service, and thus can be copied and used transparently as a normal file, for instance when transported to a home computer using a portable storage medium. In the case of the stub file, if only the location information data is copied, the data may not be accessible without a network path to the DBMS server, thereby violating the abstraction of a normal file experience. 
         [0041]    In summary, the present invention provides the performance and scalability of a client-server database system while maintaining a database-transparent user experience with minimal or non-existent administration needs. The system allows a user to invoke a file that triggers transparent access to the improved functionality and efficiency of the hidden client-server system. Note that the approach described in the present invention is not limited to data files mapped to relational data files, but can also be used generally to transparently map between other types of data files as well. 
         [0042]    The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.