Abstract:
A method, system, and computer program product of building a Native XML Object Database, the present invention dynamically generates database API from object-oriented design and persists data in native XML files. The structure of data is maintained from front end API to back end file storage for better security and performance.

Description:
BACKGROUND OF INVENTION  
       [0001]     1. Field of the Invention  
         [0002]     The present invention is about building an NXOD—Native XML Object Database that is object oriented in the API layer and native XML in the persistence layer.  
         [0003]     2. Related Art  
         [0004]     A typical database system comprises of three layers: API, database core, and data persistence. The API layer takes orders from external database applications. The database core processes orders, causes physical changes in the persistence layer, reports the processing result to the API layer, which in turn reports to external applications.  
         [0005]     Modern database technology renders mainly three categories of databases: relational database, object database, and XML database. Relational databases focus on relationships between tables and integrity of data while object and XML databases emphasis on mapping real world entity relationships to the structure of data. XML databases use XML in either or both of the API and persistence layers.  
         [0006]     Database applications interact with databases mainly through three categories of APIs: SQL, Get/Set operations, and SOAP. SQL is a query language for relational databases; Get/Set operations are programming interfaces for object databases, get operation being for data retrieval, set for data update/removal; SOAP is an XML plain text messaging mechanism for XML databases.  
         [0007]     A data file at the persistence layer can take a proprietary binary form or a plain text form. Most of the relational and object databases use a binary form. XML databases use an XML plain text form or a binary form.  
         [0008]     XML databases comprise of XML enabled database and Native XML database. A relational or object database is an XML enabled database if it supports SOAP API or XML data input/output. A native XML database uses XML for data file format at the persistence layer, or saves data to proprietary data stores via DOM—Document Object Model. SQL Server 2000 by Microsoft, for instance, is an XML enabled relational database management system; Matisse by Matisse Software an XML enabled object database management system; dbXML by dbXML Group a native XML database management system.  
         [0009]     The present invention uses Get/Set operations at the API layer and XML files for data persistence. That is how NXOD—Native XML Object Database gets named.  
         [0010]     Database systems on the market support a variety of programming interfaces: C, C++, Java, Perl, etc. All of the APIs are static, manually coded, and shipped along with their respective products. The present invention provides means and steps of dynamically generating APIs based on object oriented design. Dynamic NXOD API is more user friendly, which cuts database application development time. Dynamic NXOD API also embeds data links to achieve fast query processing and database transactions.  
         [0011]     In the persistence layer, U.S. patent application No. 20040103105 by Christopher Lindablad and Paul Padersen proposes a tree like hierarchy for the data store. As it assumes static APIs, data links are embedded in the tree. Also, It does not examine data persistence in a coherent lifecycle of design, API, and storage. In XNOD, API and storage hierarchy are driven by object oriented design.  
         [0012]     Existing native XML databases are trying to store the structure of data in XML files, which has performance penalties due to XML parsing of nested structures. The present invention separates structure and value of data. The hierarchy is represented by file system paths. Native XML files have flat structures and store name/value pairs. No elements except the document root in the XML file has child elements. When viewing the data store as a tree, all the inner nodes including the root are file directories; all leaf nodes are XML files.  
         [0013]     At the database design phase, all three categories of databases start from entity relationship diagrams. Relational databases then map the entity relationship diagrams to tables that satisfy Boyce-Codd Normal Form; object and XML databases to a hierarchy of objects.  
         [0014]     The present invention starts from entity relationship diagrams. The data representation, however, is both a set of relational tables and a hierarchy of objects.  
       SUMMARY OF INVENTION  
       [0015]     The present invention provides steps and means for building an NXOD—Native XML Object Database that offers a combination of features from heterogeneous database systems. NXOD follows an object-oriented design. The data representation is both of normalized tables like in relational databases, and of a tree of objects like in object databases. At the front end, NXOD offers a set of getters and setters like in object databases. At the back-end, NXOD saves data in XML files like in native XML databases.  
         [0016]     The present invention comprises of following differentiators: 1) Dynamic design driven API, 2) Separation of structure and value of data, 3) Data links embedded in dynamic API, 4) Better granularity for data access control and encryption, 4) Better reliability and resilience to data corruptions, 5) Smaller memory footprint, faster query processing and operations.  
         [0017]     In a word, being a hybrid of native XML and object databases, the present invention innovates in API, implementation, storage, security, and performance. 
     
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0018]      FIG. 1  depicts an embodiment of the present invention NXOD to interact with an external database application via Get/Set operation pairs.  
         [0019]      FIG. 2  depicts a generic workflow of the present invention.  
         [0020]      FIG. 3  depicts a sample object oriented design utilized by NXOD.  
         [0021]      FIG. 4  depicts a sample mapping from said design to a file system structure.  
         [0022]      FIG. 5  depicts the database core and its internal working. 
     
    
     DETAILED DESCRIPTION  
       [0023]     The present invention hides all the complexity of database queries from end users. As depicted in  FIG. 1 , NXOD  180  interacts with external applications  100  via Get/Set operations.  
         [0024]      FIG. 2  offers a close view of how the present invention works in real world. First, the Database Application  200  talks to dynamic API  240 , which talks to the Database Core  260 , which manipulates native XML files  280 .  
         [0000]     Data Mapping  
         [0025]     The present invention provides steps and means for transparently mapping an object oriented database design, an entity relationship diagram as depicted in  FIG. 3 , to the file system structure as depicted in  FIG. 4 . For simplicity, said database design comprises two entities: Primary Holder  310  and Bank Account  380 . The relationship is 1 to N, i.e., one primary account holder can have one or more bank accounts, but one bank account can only have one primary holder. Primary Holder has four attributes: SSN  312 , Account Numbers  314 , First Name  316 , and Last Name  318 . Account Numbers holds a list of bank account numbers that reference to Bank Account  380 .  
         [0026]     Bank Account has three attributes: Account Number  382 , Bank Name  384 , and Balance  386 . Bank Account has two descendant entities: Checking Account  390  and Brokerage Account  396 . Checking account has an attribute Overdraft  392 ; Brokerage Account an attribute Margin  398 .  
         [0027]     The present invention follows said design and dynamically generates following interfaces and classes, which can be done in any object-oriented programming language. See the Program Listing Deposit for Java examples.  
         [0028]     1. Interfaces: i) IPrimaryHolder extends Identity, ii) IBankAccount extends Identity, iii) ICheckingAccount extends IBankAccount, iv) IBrokerageAccount extends IBankAccount.  
         [0029]     2. Implementation Classes: i) PrimaryHolder implements IPrimaryHolder, ii) BankAccount implements IBankAccount, iii) CheckingAccount extends BankAccount implements IBankAccount, iv) BrokerageAccount extends BankAccount implements IBrokerageAccount.  
         [0030]     3. Query Classes: i) PrimaryHolders runs queries for PrimaryHolder, ii) BankAccounts runs queries for BankAccount, iii) CheckingAccounts runs queries for CheckingAccount, iv) BrokerageAccounts runs queries for BrokerageAccount.  
         [0031]     Running sample database Application A in the Program Listing Deposit stores Primary Holder data in the XML content:  
                                                   &lt;?xml version=“1.0”encoding=“utf-8” ?&gt;           &lt;PrimaryHolder&gt; &lt;ssn&gt;123&lt;/ssn&gt;           &lt;userName&gt;a_user&lt;/userName&gt;           &lt;firstName&gt;John&lt;/firstName&gt;           &lt;lastName&gt;Smith&lt;/lastName&gt;           &lt;accountNumber&gt;456&lt;/accountNumber&gt;           &lt;accountNumber&gt;789&lt;/accountNumber&gt;           &lt;/PrimaryHolder&gt;                      
 
         [0032]     Running sample database Application B in the Program Listing Deposit stores Checking Account data in the XML content:  
                                                   &lt;?xml version=“1.0”encoding=“utf-8” ?&gt;           &lt;CheckingAccount&gt; &lt;userName&gt;a_user&lt;/userName&gt;           &lt;accountNumber&gt;456&lt;/accountNumber&gt;           &lt;bankName&gt;a_bank&lt;/bankName&gt;           &lt;balance&gt;2000.68&lt;/balance&gt;           &lt;overdraft&gt;1000.00&lt;/overdraft&gt; &lt;/CheckingAccount&gt;                      
 
         [0033]     Running sample database Application C in the Program Listing Deposit stores Brokerage Account data in an XML content:  
                                                   &lt;?xml version=“1.0”encoding=“utf-8”?&gt;           &lt;BrokerageAccount&gt; &lt;userName&gt;a_user&lt;/userName&gt;           &lt;accountNumber&gt;456&lt;/accountNumber&gt;           &lt;bankName&gt;b_bank&lt;/bankName&gt;           &lt;balance&gt;8000.26&lt;/balance&gt; &lt;margin&gt;yes&lt;/margin&gt;           &lt;/BrokerageAccount&gt;                      
 
         [0034]     Said XML contents are saved in the file system as depicted in  FIG. 4 . The ROOT DIRECTORY  400  is created while NXOD is being loaded. Execution of said sample database applications causes four directories and three files to be created. Directory PrimaryHolders  420  contains XML file  426 . Directory BankAccount  440  has two sub directories (to map said inheritance of bank account entities): CheckingAccounts  60  and BrokerageAccounts  480 . CheckingAccounts contains XML file  466 ; BrokerageAccounts XML file  486 .  
         [0035]     Each XML file stores one instance of the data object. Data for 1000 primary account holders will be stored in 1000 XML files under the PrimaryHolders directory  420 . Each primary account holder can have one or more checking accounts. The number of XML files under the CheckingAccounts directory  460  is the total number of checking accounts held by all primary account holders. The number of XML files under the BrokerageAccounts directory  486  is the total number of brokerage accounts held by all primary account holders.  
         [0036]     The present invention separates structure from value of data. As depicted in  FIG. 4 , the hierarchy is represented by file paths. Flat name/value pairs are stored in XML files  426 ,  466 , and  486 .  
         [0000]     Database Query  
         [0037]     The present invention eliminates the need for a query language like SQL or XQuery. An NXOD query is initiated by the external application  200  and executed by a series of get operations in the API  240  and the database core  260 .  
         [0038]     Locating an instance of data is by following said data link (file path) embedded in said dynamic API. As shown in the Program Listing Deposit, at each data object instantiation, a database handler called entrance is constructed. For example,  
         [0039]     entrance=Manager.getEntrance(PrimaryHolders.dataDir, ssn);  
         [0040]     This is to say, the parent directory of a PrimaryHolder data file is PrimaryHolders. The returned object entrance points to the instance of specific ssn.  
         [0041]     Print out all ssn, bank account numbers, and balances. Application D in the Program Listing Deposit executes this query.  
         [0000]     Security  
         [0042]     The present invention delivers access control to each instance of the data. Each XML file has a username element to hold the user credential against which data access can be checked in real time. As shown in said sample applications, user name is a required argument for object instantiation.  
         [0043]     The present invention delivers data encryption to the attribute/field level. For example, ssn—social security number of the primary holder is sensitive data and needs to be encrypted. As ssn is an argument for the PrimaryHolder constructor, an encryption utility is called from the constructor as listed in APIE in the Program Listing Deposit.  
         [0044]     After setting values for userName, firstName, lastName, and accountNumber, the XML data content  466  looks as follows. You can see ssn gets encrypted.  
                                                   &lt;?xml version=“1.0”encoding=“utf-8”?&gt;           &lt;PrimaryHolder&gt; &lt;ssn&gt;*({circumflex over ( )}Re#%[KrP$&lt;/ssn&gt;           &lt;userName&gt;a_user&lt;/userName&gt;           &lt;firstName&gt;John&lt;/firstName&gt;           &lt;IastName&gt;Smith&lt;/IastName&gt;           &lt;accountNumber&gt;456&lt;/accountNumber&gt;           &lt;accountNumber&gt;789&lt;/accountNumber&gt;           &lt;/PrimaryHolder&gt;                      
 
 Comparisons 
 
         [0045]     Given said bank account example, the present invention differentiates itself throughout the design process, API and persistence layers.  
         [0046]     Relational databases starts with entity relationship diagrams, but most likely with no entity inheritance like bank accounts  380 ,  390 , and  396 . Also, relational database systems do not support native arrays or lists.  
         [0047]     From a relational perspective, NXOD creates three tables: PrimaryHolder—ssn, firstName, lastName, accountNumbers; CheckingAccount—accountNumber, bankName, balance, overdraft; BrokerageAccount—accountNumber, bankName, balance, margin.  
         [0048]     A relational database, however, takes a more fragmented approach. Four tables are created: PrimaryHolder—ssn, firstName, lastName; BankAccount—accountNumber, bankName, balance, ssn; CheckingAccount—accountNumber, overdraft; BrokerageAccount—accountNumber, margin.  
         [0049]     Now, PrimaryHolder and account tables are linked by ssn instead of accountNumber in NXOD. The obvious fact that the primary holder has several bank accounts becomes hidden among the relationships. Given social security number ‘23456789’print out his/her bank account numbers. A relational database application will run a SQL statement with externally configured access control:  
         [0050]     SELECT ACCOUNTNUMBER FROM BANKACCOUNTS WHERE SSN=123456789  
         [0051]     The present invention executes in said sample Java application following statements with a built-in security:  
         [0052]     PrimaryHolder holder=new PrimaryHolder(credential, ssn);  
         [0053]     String [ ]accounts=holder.listAccounts();  
         [0054]     An object database would run following statements with pre-manufactured API and an externally configured security:  
                                                   IClass iClass = findData−           Class(path_to_PrimaryHolder_class);           IObject object = iClass.constructObject(ssn);           String []accounts = (String           [])object.getPropertyValue(accountNumbers);                      
 
         [0055]     An XML database application would send a bulky SOAP message with externally configured security:  
                                                   &lt;?xml version=“1.0”encoding=“UTF-8”?&gt;           &lt;soapenv:Envelope           xmlns:soapenv=“ttp://schemas.xmlsoap.org/soap/envelope/           “xmlns:xsd=“ttp://www.w3.org/2001/XMLSchema“xmlns:           xsi=“ttp://www.w3.org/2001/XMLSchema-instance” &lt;           soapenv:Body&gt; &lt;listAccounts           xmlns=“rn:PrimaryHolder.gmorpher.com”           &lt;/listAccounts&gt; &lt;/soapenv:Body&gt;                      
 
         [0056]     In the persistence layer, relational, object, and some XML oriented databases store data in one blob file, which makes database vulnerable for data corruptions. Existing native XML databases may store data in a tree of XML files, but each XML has nested structures of data. The database is still vulnerable for local data corruptions.  
         [0057]     The present invention maps the structure of data to file system paths. Each XML data file is flat and holds name/value pairs, but no nested structures. Each XML data file represents one instance of data, which is a row/tuple from a relational perspective. Therefore, data corruption is quarantined and minimized to the row/tuple level.  
         [0058]     On the performance side, as structure of data is mapped to file system paths, locating a piece of data triggers OS system calls, which are faster than application level method invocations. NXOD has the ability to load any desired row of data on the fly without engaging unrelated data while existing databases need to load the whole blob file or deeply nested XML files into memory even if only a small portion of data is actually accessed. Therefore, NXOD has smaller memory footprints and faster transactions.  
         [0000]     DataBase Core  
         [0059]     The present invention provides means and steps for building a processing center to map Get/Set operations in the API layer to XML content changes in the persistence layer. Get operations in the API comprising of getxxx() and listxxx( ) where xxx is the data field name, are for data retrieval. Set operations in the API comprising of setxxx( ), deletexxx( ), addxxx( ), removexxx( ), and commit( ), are for data modifications. addxxx( ) and removexxx( ) are for a list of values/references.  
         [0060]      FIG. 5  can be viewed as an expansion of  FIG. 2  to drill down to the database core which comprises of four major components:  560 ,  562 ,  564 , and  568 .  
         [0061]     Dynamic API  540  starts a representative get operation getBalance( ). Core Entrance  560  translates it into getDouble(“balance”); then Core Porter  562  into get(“balance”) The computer-readable program code of the present invention utilizes Apache Xerces XML parser for component  568 , which translates the get operation further into getNodeValue( ) and fetches data from XML Files  580 .  
         [0062]     API  540  also starts a representative set operation setBalance( ). Core Entrance  560  translates it into setDoubleo. Core Porter  562  sets the value to Core Cache  564 . To persist cumulative set operations, the external application calls commito exposed via API  540 , which saves the changes to XML Files  580  and cleans up Core Cache  564 .  
         [0063]     Create, update, delete are three major NXOD operations at the data field level. The set operation in dynamic API  540  causes a new field value to be created if it is not preexistent. Otherwise, it is an update operation to overwrite existent data. Therefore, create and update map to setxxx( ) in dynamic API  540  for a single value/reference, to addxxx( ) for a list of values/references. And delete maps to deletexxx( ) or removexxx( ). See the Program Listing Deposit for Java code examples.  
         [0064]     At the instance/tuple level, NXOD starts with the instantiation of a data object. If the instance does not exist, it is an insertion operation; update operation, otherwise. Delete is accomplished by removing the correspondent XML file.