Relational model applications methodology

The following is a basic overview of the suggested approach for building relational model applications on the CEDA platform

It's appropriate to use the following layers

• base schema modules
• business logic modules in the form of
  • derived schema modules; and
  • update function modules
• presentation layer modules

The challenge is for a DBMS to make this easy and efficient. Parameterised relation types and tuple types eliminate the need for an O/R mapping.

Base schema modules

Each base schema defines a representation that is the target of update transactions.

A base schema should be relatively unconstrained (i.e. have weak integrity constraints), promoting

• A partition of the code base into many base schema modules, where the modules have high cohesion and low coupling
• Each base schema module is protected by a single mutex, which has far less overhead that the lock managers conventionally used in a DBMS.
• Base schema modules can be updated independently, promoting high concurrency
• Dead-locks caused by cycles in the wait-for graph are impossible, because a thread that updates a base scheme module only locks the mutex, applies the updates then releases the lock - i.e. no other resources are accessed while holding the lock.
• Weak integrity constraints allow for Operational Transformation
• Weak integrity constraints mean update transactions are fast and efficient
• Allows work in progress, conflicting information and partial information to come under proper data management

Derived schema modules

A derived schema module can be any function of one or more base schema module(s). It is code that defines what can be read from the database, and represents the read access part of a business logic layer.

This typically involves procedural/functional code, and of course the relational algebra. OO state machines aren't all that useful here.

Derived schema modules naturally compose, because both base and derived relational schemas are treated similarly as far as read-access is concerned.

Since a derived schema module is read-only it can be a non-injective function of the base schema modules(s) and therefore:

• Can satisfy very strong integrity constraints
• Can provide a cleaned up version of the data such as by resolving conflicts or removing duplicates, or records that violate foreign key constraints, or work in progress.
• Can highlight the problems and errors in the data, such as the work in progress, conflicts and missing information.

A derived schema involving an injective function [] preserves all the information in the base schema. Allowing non-injective functions means allowing some of the information to be dropped.

A derived schema module allows control over policies for the caching of calculated values, and requires infrastructure for ensuring derived variables are updated efficiently and automatically when the base variables are updated.

Update function modules

This is code that defines what updates can be applied to the database, more specifically to base schema modules, and represents the part of the business logic layer that is concerned with updates.

Derived schema modules are irrelevant because they are not updatable.

This typically involves procedural/functional code, and of course the relational algebra. OO state machines aren't all that useful here.

Presentation layer

A derived schema module is apropriate for defining what relational information needs to be presented.

However the presentation layer (user interface) itself falls outside the scope of the RM. This is because the UI is a state machine.

OO is typically useful here.

The UI code should be relatively thin, i.e. avoid containing any business logic.