Dataphor - a Formal Defintion

A formal defintion of Dataphor can be found here.

Simply put Dataphor represents a new declarative solution
to application development. At the heart of dataphor is
data management based on a true implementation of the
Relational Model. Dataphor builds on this relational foundation
to provide various application development services such as
the presentation layer. Dataphor therefore represents a new
paradigm for development called automated application
development. And is the next step in the evolution of
application development technology beyond current rapid
application development or RAD. 

The relational model in dataphor is based on the work of
E. F. Codd and continued by C. J. Date.

The data management language used in dataphor is formally
called D4. It is a relational language embedded in an 
imperative language. The relational component is based
on the relational language put forth by C. J. Date and
Hugh Darwen called Tutorial D in:

'Databases, Types and the Relational Model (3rd Edition)'
which can be found here.

The imperative part of D4 is based on the Pascal language.

In other words, in D4 the statement:

if x=y then
<do something>
else
<do something else>

is as appropriate for integers, as it is for strings
as it is for tables!

Unlike sql systems, the dataphor compiler is a relational
inference engine. In faithfully following the relational
model, keys are inferred for newly derived tables. Whereas
sql systems emphasis keys to physically access tables,
dataphor uses keys to logically access tables. Such
emphasis on the relational logical model allows operations
on tables that are not supported in sql. Updatability of
views of almost any complexity and the ability to declare
constraints of any complexity are but two examples.

Dataphor is also a derivation engine. At the presentation
layer forms are derived from the logical definition of tables
and from user declared metadata. It is in this sense that
dataphor uses a declarative method for application development.

Dataphor uses a device to store and access data. In other
words data resides in a repository accessed by dataphor.
A device can be any sql system such as MS Sql Server,
Oracle, DB2 etc. If desired the device can be accessed directly
thru D4 by the dialect of sql it supports. Data created
directly on an sql system can be easily made available
to dataphor. In this sense you can have the best of both
worlds:)

The following quote from the Dataphor Help docs succinctly
conveys Dataphors new paradigm for development, the inherent
limitations historically built into sql and how they are
overcome with the relational model in the context of an
imperative language in a declarative application development
environment.
 
'SQL was designed as a 'database sublanguage.' It was
intended to be used from 3GL programming environments as
a means of retrieving and manipulating data in the database.
As such, it had no facilities for imperative programming.
This implies that application development is done in one
language, while data manipulation is done in another. 
This disparity of language environments is called
impedance mismatch. D4 is really just an imperative
programming language where one of the types of data that
can be described is a table. As a result, applications
can be developed entirely in D4, with no resulting
impedance mismatch.'

I will be concentrating on D4 as it manipulates data in a
relational model as opposed to sql data management.

I hope you find it inspirational and uplifting:)