Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The von Neumann Architecture vs. Database Applications

DZone's Guide to

The von Neumann Architecture vs. Database Applications

The success story of modern computers began with the von Neumann architecture — and the external architecture of a database application looks very similar to it.

· Database Zone
Free Resource

Read why times series is the fastest growing database category.

The success story of modern computers began with the von Neumann architecture which is shown below.Image title

The distinguishing features of this architecture are:

  • All hardware blocks are universal (independent on the task)
  • Fixed connections between blocks 
  • Solving a problem means developing a program — the sequence of instructions 
  • Both the program and data are saved in the common memory

The external architecture of a database application looks very much like the previous build. Image title

The database here corresponds the memory and the application's code seems to correspond the central processor unit. But a computer is a completely universal device that can solve an infinite number of different tasks whereas each database application is a very specialized product intended to process data structures specific only for this application.

Several features make a computer a universal machine.

  • Any data are represented in the common low-level form — the binary code. 
  • Any algorithm is decomposed into a sequence of low-level instructions from the finite common set — the program. 
  • Instructions are represented in the same form as data — as a binary code. 
  • Both data and instructions are saved in the main memory. 

By using a computerized system to solve a problem, a computer is the immutable part of the system, invariant to a task. The program is the mutable part of the system adapted to the task. High-level program languages and modern operational systems, as well as integrated development environments, can be also included in the list of the immutable environment. Using ready (immutable) components increases developer productivity and quality of the system.

Database applications use other approaches.

  • A database stores only data. 
  • Data schema within the database must be adapted to the application. 
  • All application programs are specified to the application and located somewhere in the file system outside of the database. 
  • The standard interface language provides communication between database and application programs. 
  • Data objects representation, as well as application programs, are specific to the database application in contrast to the main memory and central processor unit of the computer, which are invariant to the current task. Each database application must be developed from scratch.

The main question discussed in the article is: Could we apply computer principles to database applications in order to gain the same universality of architecture and decrease development efforts? Obviously, to achieve success with this the application architecture, we should adopt the computer features:

  • Unify data objects in the database so that they can keep any user data as well as pieces of program code. 
  • Decompose the application code into the immutable part that is common for all application and into the specified parts that adapt the application to the current area of interests. The common code is the analogy of the central processing unit and can be referenced as the central application unit (CAU). The CAU is the only separate program located outside the database.  The specified pieces of the code must be saved within the database as ordinary data objects. 

The logical structure of data objects and the relationships between them are mostly described in terms of the entity-relationship model (ERM). A data object in ERM is represented as a structured entity — a set of named attributes. However, the majority of user data are semi-structured — they contain the structured part (the metadata as a set of attributes) and actual data — usually files in native format. Entities that include program code are examples of semi-structured data. Hence, we need a database for managing of semi-structured data for our universal database application.

Concerning the decomposition of a program, it is seemingly impossible to reduce a set of all possible operations over data objects to any finite set of instructions. Nevertheless, the facet-oriented approach lets us create the immutable central application unit and place the current area code into entities within the database.

The facet-oriented data model is based on the assumption that any object can be represented as a composition of more elementary components called facets. A facet is defined as a portion of data and processing this data code. An entity is considered as a facet container that may accumulate data pieces related to different facets. The facet code is enclosed in the library or class files. These files are interpreted as data within the separate entities dedicated as program containers.

The CAU takes over management of common operations on entities and facets independent on the actual business area. The business application itself is actually a set of data and program entities placed within the database. The CAU recognizes the facets saved within program entities, loads corresponding code into the memory, and provides the corresponding interface to manage business entities for the end user. Finally, the facet-oriented application architecture is shown below.Image title

The JEntigrator is an example of the facet-oriented database application. It is implemented in Java as an executable library file jentigrator.jar.

Implementation of the Entities Database

As mentioned above, an entity in the common case must contain the structured part having arbitrary number of named attributes and the container for files in the native format. Tables from relational databases or jason-objects from document databases do not math these requirements. The database in the JEntigrator stores entities in the file system in form of XML files. Such files contain only the structured part of the entity. Each entity may also have an individual folder to keep native files associated with the entity. The example below illustrates the internal structure of the Community entity that contains the code of the sample Community application.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<sack path="null" key="_v6z8CVgemqMI6Bledpc7F1j0pVY">
	<attributes>
		<attribute type="String" name="alias" value="community" />
		<attribute type="null" name="icon" value="folder.png" />
		<attribute type="null" name="key" value="_v6z8CVgemqMI6Bledpc7F1j0pVY" />
		<attribute type="null" name="origin_entihome" value="/home/imasa/Community" />
		<attribute type="String" name="residence.base" value="_xXsnV5R_SGxkuH_SpLJDeXCglybws" />
		<attribute type="null" name="save id" value="_nxyY2lL5Bnryk2UcX9dFJ6StsGE" />
		<attribute type="null" name="timestamp" value="1504819576203" />
	</attributes>
	<elements>
		<element title="content.fhandler" >
			<item type="gdt.jgui.console.JFacetOpenItem" name="gdt.data.entity.AddressHandler" value="_v6z8CVgemqMI6Bledpc7F1j0pVY" />
			<item type="gdt.jgui.console.JFacetOpenItem" name="gdt.data.entity.BankHandler" value="_v6z8CVgemqMI6Bledpc7F1j0pVY" />
			<item type="gdt.jgui.console.JFacetOpenItem" name="gdt.data.entity.ContactHandler" value="_v6z8CVgemqMI6Bledpc7F1j0pVY" />
			<item type="gdt.jgui.console.JFacetOpenItem" name="gdt.data.entity.EmailHandler" value="_v6z8CVgemqMI6Bledpc7F1j0pVY" />
			<item type="gdt.jgui.console.JFacetOpenItem" name="gdt.data.entity.PersonHandler" value="_v6z8CVgemqMI6Bledpc7F1j0pVY" />
			<item type="gdt.jgui.console.JFacetOpenItem" name="gdt.data.entity.PhoneHandler" value="_v6z8CVgemqMI6Bledpc7F1j0pVY" />
		</element>
		<element title="content.jfacet" >
			<item type="gdt.jgui.entity.address.JAddressFacetAddItem" name="gdt.data.entity.AddressHandler" value="gdt.jgui.entity.address.JAddressFacetOpenItem" />
			<item type="gdt.jgui.entity.bank.JBankFacetAddItem" name="gdt.data.entity.BankHandler" value="gdt.jgui.entity.bank.JBankFacetOpenItem" />
			<item type="gdt.jgui.entity.contact.JContactFacetAddItem" name="gdt.data.entity.ContactHandler" value="gdt.jgui.entity.contact.JContactFacetOpenItem" />
			<item type="gdt.jgui.entity.email.JEmailFacetAddItem" name="gdt.data.entity.EmailHandler" value="gdt.jgui.entity.email.JEmailFacetOpenItem" />
			<item type="gdt.jgui.entity.person.JPersonFacetAddItem" name="gdt.data.entity.PersonHandler" value="gdt.jgui.entity.person.JPersonFacetOpenItem" />
			<item type="gdt.jgui.entity.phone.JPhoneFacetAddItem" name="gdt.data.entity.PhoneHandler" value="gdt.jgui.entity.phone.JPhoneFacetOpenItem" />
		</element>
		<element title="content.jrenderer" >
			<item type="gdt.jgui.console.JFacetRenderer" name="gdt.data.contact.ContactHandler" value="gdt.jgui.entity.contact.JContactEditor" />
			<item type="gdt.jgui.entity.fields.JFieldsEditor" name="gdt.data.entity.AddressHandler" value="gdt.jgui.entity.address.JAddressEditor" />
			<item type="gdt.jgui.entity.fields.JFieldsEditor" name="gdt.data.entity.BankHandler" value="gdt.jgui.entity.bank.JBankEditor" />
			<item type="gdt.jgui.tool.JTextEditor" name="gdt.data.entity.EmailHandler" value="gdt.jgui.entity.email.JEmailEditor" />
			<item type="gdt.jgui.entity.fields.JFieldsEditor" name="gdt.data.entity.PersonHandler" value="gdt.jgui.entity.person.JPersonEditor" />
			<item type="gdt.jgui.tool.JTextEditor" name="gdt.data.entity.PhoneHandler" value="gdt.jgui.entity.phone.JPhoneEditor" />
			<item type="null" name="gdt.jgui.console.JRequester" value="Value" />
		</element>
		<element title="content.super" >
			<item type="null" name="gdt.jgui.entity.address.JAddressFacetAddItem" value="gdt.jgui.console.JFacetAddItem" />
			<item type="null" name="gdt.jgui.entity.address.JAddressFacetOpenItem" value="gdt.jgui.console.JFacetOpenItem" />
			<item type="null" name="gdt.jgui.entity.bank.JBankFacetAddItem" value="gdt.jgui.console.JFacetAddItem" />
			<item type="null" name="gdt.jgui.entity.bank.JBankFacetOpenItem" value="gdt.jgui.console.JFacetOpenItem" />
			<item type="null" name="gdt.jgui.entity.contact.JContactFacetAddItem" value="gdt.jgui.console.JFacetAddItem" />
			<item type="null" name="gdt.jgui.entity.contact.JContactFacetOpenItem" value="gdt.jgui.console.JFacetOpenItem" />
			<item type="null" name="gdt.jgui.entity.email.JEmailFacetAddItem" value="gdt.jgui.console.JFacetAddItem" />
			<item type="null" name="gdt.jgui.entity.email.JEmailFacetOpenItem" value="gdt.jgui.console.JFacetOpenItem" />
			<item type="null" name="gdt.jgui.entity.person.JPersonFacetAddItem" value="gdt.jgui.console.JFacetAddItem" />
			<item type="null" name="gdt.jgui.entity.person.JPersonFacetOpenItem" value="gdt.jgui.console.JFacetOpenItem" />
			<item type="null" name="gdt.jgui.entity.phone.JPhoneFacetAddItem" value="gdt.jgui.console.JFacetAddItem" />
			<item type="null" name="gdt.jgui.entity.phone.JPhoneFacetOpenItem" value="gdt.jgui.console.JFacetOpenItem" />
		</element>
		<element title="fhandler" >
			<item type="null" name="gdt.data.entity.facet.ExtensionHandler" value="null" />
			<item type="null" name="gdt.data.entity.facet.FieldsHandler" value="null" />
		</element>
		<element title="field" >
			<item type="null" name="lib" value="community.jar" />
			<item type="null" name="res" value="community.tar" />
		</element>
		<element title="jfacet" >
			<item type="null" name="gdt.data.entity.facet.ExtensionHandler" value="gdt.jgui.entity.extension.JExtensionFacetOpenItem" />
			<item type="gdt.jgui.entity.fields.JFieldsFacetAddItem" name="gdt.data.entity.facet.FieldsHandler" value="gdt.jgui.entity.fields.JFieldsFacetOpenItem" />
			<item type="gdt.jgui.entity.folder.JFolderFacetAddItem" name="gdt.data.entity.facet.FolderHandler" value="gdt.jgui.entity.folder.JFolderFacetOpenItem" />
		</element>
		<element title="property" >
			<item type="entity" name="_brcbTWuxoGLkUhMJRGGxYu0nZF0" value="extension" />
			<item type="extension" name="_hxXsrPotVgWFN6DecDH86csu9A4" value="community" />
			<item type="fields" name="_qneP3DeL2_SMYS_HavHBwu20v7lE" value="community" />
			<item type="label" name="_v6z8CVgemqMI6Bledpc7F1j0pVY" value="community" />
		</element>
	</elements>
</sack>

The section attributes contains the system information. The key attribute is unique for the entity and matches exactly to the name of the file. The attributes from the  property element are included in the global index and can be used for searching. The label is the unique user-friendly name for the entity.

Elements fhandler, field, and jrenderer contain information about facets assigned to this entity. For example, the element field contains names of code and resource libraries located in the entity’s folder.

Elements content.* contain information about facets included in this extension. The CAU uses this information to load and activate extension classes. Note a regularity of facet classes.

The database in the JEntigrator is actually a file directory that contains entities, their folders, and indexes.

Implementation of the Central Application Unit

The CAU is the program that collects all common purpose functionalities in database applications. These functionalities include database management (creation, navigation, export/import operations, etc.) and entities management (creation, deletion, getting and putting information, adding/removing facets, etc.) as well as a few common facets and the graphic user interface. The JEntigrator implements CAU as an executable library file jentigrator.jar. The running CAU displays a window containing the Menu bar, the Context Panel, and the Status Panel, as shown below.Image title

An end user navigates between task contexts using menu and items on the context panel. All context elements (name, menu, panel, and status) change their content depending on the current task. You can also check out some demo database applications that illustrate different aspects of the facet-oriented approach.

Summary

The long-term work with the JEntigrator allows some conclusions regarding facet-oriented architecture.

  • The structure of entities in the database is flexible enough to reflect any data objects and relations between them. The implementation of well-known sample databases Movie and Northwind confirms it. 
  • A great deal of application code is not necessary to create. It can and must be used from the CAU.  
  • An application code has a regular structure as a set of facets. Most of them can be derived from the common purpose facets (fields, folder, etc.) embedded into the CAU. That makes development much easier. 
  • The structure of entities can be modified individually. Entities of the same type may have different sets of facets that enhance flexibility.  
  • Modification of structure of the entity can be done by adding/removing facets or attributes in the same fashion as content changing without any coding within runtime. This work can be delegated to the end user. 
  • In contrast to traditional database applications, the evolution of facet-oriented applications is a much more easy procedure. Actually, we must develop the extension library containing new facets, put it into the extension entity, and add this entity into the database. After that, these facets will be accessible to the end user and can be added to target entities through the GUI. It is not necessary simultaneously change all target entities. We can do it one after another in runtime permanently keeping the consistency between code and data during all evolution steps. 
  • Entities can be transferred between databases through copy-paste operations. 

I hope the facet-oriented design of database applications has a future.

Learn how to get 20x more performance than Elastic by moving to a Time Series database.

Topics:
database ,tutorial ,von neumann ,architecture ,database application

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}