Evolution of Data Objects Within Database Applications

What is the Data Object Evolution?

The subject of this tip is database applications. These applications reflect objects from the real world in program objects in the application. The application provides the interface to control data objects and synchronize changes of corresponding objects in both environments.

Under the data object, we understand an object having state and behaviour. The state is represented as an array of named fields, the behaviour is defined as a set of reactions on impacts. We distinguish two kinds of object changes: content and structure. The content change means changing the state variable values. The number and names of state variables stay intact as well as objects behaviour. The structure change (evolution) means either changing the set of state variables or object behaviour. When the content change is the standard operation under the responsibility of the end user (the application usually provides the convenient interface for it), then the structure changes are much more complicated challenge that demands changes in the application code and the database schema.

The figure below shows the evolution of the data object across the application based on the classical relational database management system (RDBMS). Assume the application user has recognized the necessity to change the structure of the real data object. He requests changes by the application developer. The application developer modifies the application code and requests changes of the schema in the RDBMS by the database developer. The evolution process involves both program and database components of the application under the responsibility corresponding developers.

If the application data is not relational, then a NoSQL database can be used. The NoSQL database management system has no schema and its interface is independent on the structure of data objects. The application developer does not need assistance of the database developer to complete the evolution. All changes are encapsulated in the code of the application. In that case, the evolution process shown on the figure below demands lesser efforts and can be marked quicker and cheaper. The participation of the application developer in the evolution process seems to be inevitable. The code of the program object must be changed to reflect changes in the real data object, or maybe not?

The Compositional Data Model

The compositional data model is based on the assumption that the real data object can be represented as a composition of more elementary components called facets. A facet is defined as a portion of data and associated with its behaviour. For example, the phone facet includes the phone number (data) and the call (behaviour). Another example is the image facet uncluding the image file (data) and viewing of the image (behaviour). A facet can be implemented as a program object where the data component is represented as a set of named fields and the behaviour is implemented as a facet's handler – the code processing these fields. The most fundamental fact is that the set of facets is essentially smaller and stabler than the set of data objects. The second important fact is that the data object structure can be built or modified in the same fashion as the content – by assigning data to the object without changing of the application code. In other words, the data object design can be delegated to the end user. The data object can be considered as a facet container and the data object design means to add/remove facets to it. The application developer must provide the permanent part of the application: a pool of facets and the interface to manage universal data objects – facet data containers. The end user takes over the design and maintenance of data objects, again, without any coding. This work belongs to the mutable part of the application as shown in the figure below.

But what if there are no facets in the pool to fulfill new requirements? The application code, finally, must be changed in that case, or again not necessarily? The composition data model has the ability to absorb data objects of the special extension type. The extension contains the library file and descriptors of the facets belonging to this extension. It is enough to import the extension data object in the data object storage in order to add new facets in the facet pool. The application loads the extension library and makes new facets available to the end user. The application code stay intact.

The Personal Data Manager Entigrator

The personal data in the smartphone matches very well to the compositional data model. The number of data items is not too large but the item's structure is very volatile and can be changed during the lifecycle of the item. The personal data manager Entigrator is the Android application that uses the compositional data model to collect and manage personal data. Any data item independently on its nature is represented as universal basic container of services (facets) – the entity. The empty entity has no content and has very few properties: the uniqual identifier, the label and the icon. The user can add/remove different services to an entity in order to specialize or adapt it. As the universal user interface, the Entigrator uses the list of terms. For example, the list of contacts (in the demo database) is shown in the picture below. The next picture shows the list of services assigned to the Author contact. The service will be called by the click on the service item.