Introducing InterSystems IRIS Document Database

Features and Benefits

By its nature, InterSystems IRIS Document Database is a schema-less data structure. That means that each document has its own structure, which may differ from other documents in the same database. This has several benefits when compared with SQL, which requires a predefined data structure.

Some of the key features of Document Database include:

• Application Flexibility: Documents do not require a predefined schema. This allows applications to rapidly set up their data environments, adapt to changes in data structure, and rapidly capture data in various formats. Document Database can begin capturing data immediately, without having to define a structure for that data. This is ideal for unpredictable data feeds, as are often found in web-based and social media data sources. If in capturing a body of data, structures within that data become evident or emerge as useful, your document data structure can evolve. Existing captured data can co-exist with this more-structured data representation. It is up to your application to determine the data structure for each document and process it appropriately. One way to do this is to establish a key:value pair representing the document structure version. Thus, conversion of data from one JSON structure to another can be performed gradually, without interrupting data capture or access.

• Sparse Data Efficiency: Document databases are very efficient at storing sparse data because attributes with a particular key do not have to appear in all documents of a collection. A document may have one set of defined keys; another document in the same collection may have a very different set of defined keys. In contrast, SQL requires that every record contain every key; in sparse data many records have keys with NULL values. For example, an SQL patient medical record provides fields for many diagnoses, conditions, and test; for most patients most of these fields are NULL. The system allocates space for all of these unused fields. In a Document Database patient medical record only those keys that contain actual data are present.

• Hierarchical Data Storage: Document Database is very efficient at storing hierarchically structured data. In a key:value pair, data can be nested within the data to an unlimited number of levels. This means that hierarchical data can be stored de-normalized. In the SQL relational model, hierarchical data is stored normalized by using multiple tables.

• Dynamic Data Types: A key does not have a defined data type. The value assigned to the key has an associated data type. Therefore a key:value pair in one document may have one data type; a key:value pair for the same key in another document may have a different data type. Because data types are not fixed, you can change the data type of a key:value pair in a document at runtime by assigning a new value that has a different data type (see Data Types and Values later in this document).

These features of Document Database have important implications for application development. In a traditional SQL environment, the database design establishes data structure that is followed in developing applications. In Document Database, data structure is largely provided in the applications themselves.

JSON Structure

Document Database supports InterSystems JSON Dynamic Objects and JSON Dynamic Arrays (see “Creating and Modifying Dynamic Entities” in Using JSON). The examples in this section create JSON structures using the ObjectScript SET command.

The following example shows how hierarchical data can be stored using JSON. The first SET creates a dynamic abstract object containing nested JSON-structured key:value pairs and arrays. The example then converts the dynamic abstract object to a JSON string, then inserts that JSON string into an existing document database as a document.

  SET dynAbObj = {
   "FullName":"John Smith",
   "FirstName":"John",
   "Address":{
              "street":"101 Main Street",
              "city":"Mapleville",
              "state":"NY",
              "postal code":10234
             },
   "PhoneNumber":
              [
               {"type":"home","number":"212-456-9876"},
               {"type":"cell","number":"401-123-4567"},
               {"type":"work","number":"212-444-5000"}
              ]
  }
  SET jstring = dynAbObj.%ToJSON() // dynamic abstract object to JSON string
  DO personDB.%FromJSON(jstring)   // JSON string inserted into document database

In this example, FullName is stored as a simple key:value pair. Address has a substructure which is stored as an object consisting of key:value pairs. PhoneNumber has a substructure which is stored as an array.

De-Normalized Data Structure

The following is a JSON example of a traditional SQL normalized relational data structure. It consists of two documents, which might be contained in two different collections:

{
   "id":123,
   "Name":"John Smith",
   "DOB":"1990-11-23",
   "Address":555
}

{
   "id":555,
   "street":"101 Main Street",
   "city":"Mapleville",
   "state":"NY",
   "postal code":10234
 }

The following is the same data de-normalized, specified as a single document in a collection containing a nested data structure:

{
   "id":123,
   "Name":"John Smith",
   "DOB":"1990-11-23",
   "Address":{
              "street":"101 Main Street",
              "city":"Mapleville",
              "state":"NY",
              "postal code":10234
             }
 }

In SQL converting from the first data structure to the second would involve changing the table data definition then migrating the data.

In Document Database, because there is no fixed schema, these two data structures can co-exist as different representations of the same data. The application code can access either data structure as required. You can either migrate the data to the new data structure, or leave the data unchanged in the old data structure format, in which case Document Database migrates data each time it accesses it using the new data structure.