The Google Firestore noSQL database has a document oriented data-model. The structure is an alternating hierarchy of collections and documents. Within a collection, which is specified by a string label, is a set of documents. A document is a map of property-value pairs. The value specified by the document can either be an object, such a string or numerical value, or it can be a label to a further subcollection. Thus the final document (one with no further subcollections under it) is a set of property-object value pairs at the end of a hierarchy. Access to this document is through a alternating set of collection labels and subcollection labels within a document.
Within the JThermodynamicsCloud implementation, the catalog objects, a mapping data structure similar to a JSON object, are found at the end nodes of hierarchy of collection and documents nodes. The nodes of the branch leading to the catalog object are designated by string labels. The string labels are either a collection label or a document property label pointing to a subcollection. Thus each of the documents in the hierarchy leading to this final catalog object only have a single label for the subcollection. In the document form of noSQL databases, the design model is to group all 'documents' into a single collection. In JThermodynamicCloud, all collections of documents are at the end of a branch designated with string labels for each node. The address, meaning the set of labels of the nodes in the branch leading to the catalog object, are specified in the FirestoreID class.
Thus each data catalog object is found on the root nodes of a hierarchy of nodes with string label names. These string labels represent categories of related data. At the top nodes of the directory, there are three categories of data: user information, account information and data. The user and account categories have all data objects having to do with managing users and accounts. The data category is the heart of the database having the thermodynamic data and all the auxiliary data associated with its management, for example transaction data supplementary data. The first set of nodes of the data hierarchy differentiate the different user's data. Each user 'owns' the data in the hierarchy below the user node. When a given user generates new data, it is put in the hierarchy under the user node. This hierarchy of labels is anologous to a file structure where the labels denote the individual folders and the last label is the filename.
Further categorization of the user's data is done through different types of labels. These labels access collections of catalog objects that belong together. The transactions used to produce these catalog object are also references with these labels. These labels are not only for the user to keep track of catalog objects, but it is fundamental for finding objects in the implementation of the database. There are three distinct labels that differentiate types of data and where they are found in the data hierarchy:
Supplementary data label: For example, when creating a new component for the fundamental data set, there could be preliminary catalog objects that are produced. These are reference by this label. All objects in the hierarchy under this label have to do with the supplementary data that was used to create a fundamental object.
Fundamental Dataset Label: This reflects a complete set of data that could be used for the calculation. The hierarchy under this label contains all the data objects having to do with the fundamental data having this label. This includes not only the fundamental data itself, and its modifications, but also the supplementary dataand transaction objects used to create this data. Each complete set of fundamental data has its own unique label. For example, the complete set of current Benson Rules would be referenced by this one label. This label is what is used in the dataset collection.
Dataset Collection Label: The dataset collection label references one configuration of fundamental data. Another dataset collection configuration would have another label. This label is often the same as the fundamental data label.
The FirestoreID object holds the address of labels leading to the leaf node where the data object resides. The last label is the CatalogObjectKey of the particular data object. If a collection is to be referenced, such as the set of fundamental data that should be used for a calculation, then the last element in this chain of label, namely the CatalogID, is left blank. To illustrate the FirstoreID and the database hierarchial structure, the location of a specific Benson rule will be used. The following list is the address in the hierarchy of the fundamental data. This list is basically the ordered set of labels found in the the FirestoreID:
hierthermodynamicdataset: Under this node is all the data created and used by the system. At this level, the other nodes denote where the account and the user information is stored.
UOqk0KtFtaXma5TGsi8Seh9RMbx1: This level differentiates between the data of different users. The hierarchy under this node, having the user ID as the label, contains all data structures owned by the user.
StandardData: This is unique name for a particular set of fundamental datasets. The user can have several datasets, possibly each representing a different version or technique. Also at this level under different nodes is the data for the dataset collections.
hierdatasetcollection: This is a fixed label representing the fundamental data sets used. Also at this level are the 'Supplementary data labels' having all the data that was used to create the fundamental data.
ThermodynamicBensonRuleDefinition: This level differentiates the fundamental data types. In this example, the Benson rules are labeled with ThermodynamicBensonRuleDefinition.
1.0: Different versions of a particular data type are differentiated. The label is a string so can be a number or any other combination of characters.
CatalogObjectStatusCurrent: Under this node is the current set of fundamental data of the type to be used for a calculation. Also at this level are nodes holding the older versions of individual pieces of data if the data has been changed. This is an example of how no data is lost and all versions of individual pieces of data are kept.
(so4)-(c)/2: This is the last node in the hierarchy and is this the catalog object itself, in this case the particular Benson rule with the CatalogObjectKey (so4)-(c)/2.