Simplifying the Development and Maintenance of Database Apps

Database applications are complex program products. Traditionally, they comprise three components: an application code, a database, and data content within the database. These components must be arranged in a precise way in order to work together. If data objects are rigid and do not change their structure and behavior, then the development of the application code and designing of the database schema can be done only once in the design time. Unfortunately, the majority of real objects evolve — they change their structure and behavior during their lifetime. Co-evolution of the application is an error-prone, time-consuming, and expensive procedure usually involving application developers, database designers, and end users.

The facet-oriented data model dramatically simplifies the development, maintenance, and evolution of a database application. This model is based on the assumption that an object can be represented as a collection of more elementary components called facets.A facet is a composition of pieces of data (attributes) and pieces of code (handlers) processing this data. An entity is the only unified data object in the database that can be considered a universal facet container. Data design means adding and removing facets to and from entities. Facets handlers are packed into libraries within entities with an extension type that is stored in the same database. Physically, the database is a file directory. An entity is an XML file stored in this directory.

JEntigrator serves as a facet manager and demonstrates how elegantly and effectively the facet-oriented approach can be applied to create and maintain different database applications.

The Concept

There are hundreds of database management systems on the market. The reason to develop another one is the fact that existing systems don’t efficiently support management of evolving data objects.

According to the object-oriented paradigm, the real world is considered a set of objects. An object has a state and behavior. A real object can be represented as a program object having a set of named fields reflecting the object’s state and a set of methods reflecting its behavior. We distinguish evolving and non-evolving objects. Non-evolving objects only change values of state variables during their lifetime. Numbers and names of state variables and sets of methods do not change. Evolving objects can change a set of state variables and methods during their lifetime.

A relational database keeps data in tables. The structure of data objects defines the scheme of the database — a set of related tables. The database designer creates the scheme and the application designer creates a front-end application that provides an interface to the end user and communication with the database. For non-evolving data objects, all this work will be done only once throughout development. The end user takes over management of state variables in the working time through the application interface.

A much more complicated challenge is the management of evolving data. Both the scheme and the application code must be changed when data objects change their structure. This dramatically increases costs as well as the time of application evolution (migration).

NoSQL databases have no scheme. The application developer doesn’t need the assistance of the database designer and can complete the evolution themselves. The participation of the application developer in migration is inevitable.

A facet-oriented data model provides the ability to design and evolve data objects in the working time without any coding. This work can be delegated to the end user. The facet-oriented data model is based on the assumption that a real object can be represented as a composition of more elementary components called facets.

A facet is a portion of data that has a certain behavior associated with it. For example, the phone facet includes the phone number (data) and the call (behavior). Another example is the image facet, which includes the image file (data) and viewing of the image (behavior). A facet can be implemented as a program object in which the data component is represented as a set of named fields and the behavior 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 the application code. The data object can be considered a facet container, and the data object design refers to adding or removing facets to or from 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. Both end users and developers benefit from this architecture. An end user can create or evolve data objects without assistance from developers. A facet developer must provide only a facet code without intervention into the main application code.

The facet-oriented data model uses only one kind of data object (facet containers) called entities. An entity is a mutable construct that can have a varying number of attributes depending on the assigned facets. It also contains a list of facet handlers and may have an assigned folder to keep files in native format. An entity defines itself and how it can be processed. In other words, the application is data-driven.

The pool of facets can be extended by including into the database entities of the extension type. Such entity contains the library file within the entity’s folder and attributes with facets descriptors belonging to this extension. Actually, the development of a business application means creating extensions. The mutable part of the applications code is stored within the database in form of extensions. The immutable part of the application (JEntigrator) is the only file outside of the database and should not be changed. It recognizes extensions within the database and makes all facets available to the end user.

The Implementation

Physically, JEntigrator is compromised of two parts: the executable file jentigrator.jar and one or more database directories on the disk. The library jentigrator.jar provides facet management and a small pool of common purpose facets. Its graphical user interface is designed as a context control frame. A context control is a panel that contains control elements relevant to the current user’s activity. It can be a list of selected entities, a list of entity’s facets, a facet control panel, and so on. A user switches between contexts in order to fulfill tasks.

Each entity is stored in the database directory as a separate XML file. An entity has two identifiers unique within the database: the key and the label. A key is an immutable string assigned to the entity by creation that cannot be changed anymore. A label is a user friendly name of the entity that can be edited during entity’s life time. Some attributes in entities are defined as properties. The application supports global properties index for quick search.

The initial application jentigrator.jar contains only a small pool of common facets and an interface to manage universal facet containers (entities). To adapt the application to the user’s business area, JEntigratoruses the extension mechanism. An extension is an entity containing a library with facet handlers relevant to certain business area. It is enough to insert an extension entity into the database to enhance the facets pool. The application code stays intact.

Summary

The facet-oriented data model has no advantages if data objects have unchangeable structure/behavior. Even more, it is principally slower in comparison to traditional data management systems (especially when it comes to processing big arrays of data objects) because each data object has to be loaded separately from the disk.

The flexibility and adaptability of the facet-oriented model have critical advantages for applications processing semi-structured evolving data objects. Below is a short list of the most interesting features of the facet-oriented model.

• Individual design and evolution of data objects. Entities of the same type may include different facets and attributes. The adding/removing of facets or attributes can be done during runtime in the same fashion as content changing from the GUI without any coding and can be delegated to the end user.

• Safe and rapid design and evolution of database applications. The development of business area applications means the development of extension libraries. Common services are already implemented in the main application jentigrator.jar. Only business-specific services must be coded in the extension. Evolution means inserting new extensions into the database that can be done in the runtime. After that, the new facets are available and an end user can assign them to entities also in the runtime. Note that the application and the data content stay permanently consistent during the evolution.

• Friendly user experience. A user can browse the database like a file system without any previous knowledge about the structure of data objects. The global properties index provides quick search for entities by properties.

You can also check out some demo database applications that illustrate different aspects of the facet-oriented approach.