Conversion script: link fix

2015-02-26T23:48:55Z

link fix

New page

= A formal mathematical critique of Relational Theory and its [[MultiValue]] opposition. =

This paper is intended to show, by use as far as possible of formal
mathematics, that relational theory for the most part is a subset of
[[MultiValue]], and that many of the problems with Relational stem from the
constraints applied to it that are not relevant to its [[MultiValue]]
sibling.

----

= Mathematical Logic =

But firstly, we need a basic introduction into Mathematical Logic. It's
all very well saying "let's be mathematically rigorous", but if your
mathematical foundation has thumping great cracks running throught it,
then the entire superstructure is going to come crashing down!

All mathematical theory is built upon axioms. An axiom is true "because
I said so". In order to "prove" an axiom (in the old-fashioned meaning
of the word - to test - "the exception proves the rule (is wrong)"), you
start with the assumption that the axiom is true and try to prove it is
false, and vice versa. If it survives this battering, then it is
consistent, and circular logic at least proves you're not being stupid.
Even better, however, is to succeed in proving your axiom is true
without assuming it is true to start with - ie proving it using solely other
axioms. If you can do this, it ceases to be an axiom, and becomes a
theorem - a fact derived from other axioms.

In all walks of intellectual endeavour, the desire is to reduce the
number of axioms and replace them by theorems. To the extent that many
lay (and not so lay) practitioners of theory do not even realise the
difference between an axiom and theorem - they think axioms are proven
fact.

To give a perfect example of the havoc this can cause, consider Euclid's
statement that parallel lines never meet. For thousands of years, this
was considered an axiom of geometry. So much so, that even Newton didn't
question it. Then, in the 19th century, various logicians said "what if
we assume parallel lines *can* meet?", and they came up with some very
strange geometries. Einstein picked up on this, and we ended up with
Relativity.

Just take a look at the wikipedia's entries for [http://en.wikipedia.org/wiki/Euclid Euclid] and [http://en.wikipedia.org/wiki/Axiom Axioms]

----

= The Relational Model and the Two-Dimensions Rule =

According to C.J.Date, the first rule of relational databases is:

1. The Information Rule simply requires all information in the database
to be represented in one and only one way, namely by values in column
positions within rows of tables.

And the second rule is:

2. The Guaranteed Access Rule. This rule is essentially a restatement of
the fundamental requirement for primary keys. It says that every
individual scalar value in the database must be logically addressable by
specifying the name of the containing table, the name of the containing
column, and the primary key value of the containing row.

(Quoted from "An introduction to Database Systems", 5th Edition)

Note that the formal proof, as noted above, is "because". These two
rules basically require that the database store data as two-dimensional
tables. Now what's all this crap about "clustering", if not an attempt
to get round these rules without actually breaking them?

Meanwhile, [[MultiValue]] represents data as n-dimensional arrays where n is
unrestricted (but usually limited in practice to 3 or 4 at the outside).
Any individual scalar value can be accessed by specifying the FILE name,
RECORD primary key, FIELD name, and then as many sequence offsets as are
required (almost invariably 1 at most). So we can easily meet
relational's requirements by specifying a subset of [[MultiValue]] with n=2.

Don't forget - in Mathematics, the general proof always trumps the
specific! So if I can up with a proof for "n", where n is any number, it
will always trump a proof for "n where n=2".

----

= Systematic Treatment of Null Values =

Both relational and [[MultiValue]] fall down here, in practice. To quote
Date:

3. Systematic Treatment of Null Values. The DBMS is required to support a
representation of "missing information and inapplicable information"
that is systematic, distinct from all regular values (for example,
"distinct from zero or any other number", in the case of numeric
values), and independent of type. It is also implied that such
representations must be manipulated by the DBMS in a systematic way.

[[MultiValue]] uses the empty string. Relational uses NULL. Both mechanisms
are incapable of distinguishing between "missing" and "inapplicable",
and hence are incapable of manipulating the two in a systematic way. What
is even worse, picking on Date's own example, is that relational cannot
handle "infinity", which is a valid number ...

The important point to note here is that relational seeks to handle it
within the database (and fails). [[MultiValue]] just admits that it can't,
and pushes it out to the application level.

----

= Defining the Database in terms of itself =

Both [[MultiValue]] and Relational require that the metadata be accessed
using the standard query tools. In principle, there is no difference.

In practice, however, [[MultiValue]] simply makes no distinction between
data and metadata. Relational treats metadata as very distinct from
data, just accessed via the same tools. There is nothing to stop
relational from implementing a metadata query differently from a data
query so long as the user doesn't see the difference. [[MultiValue]] is not
allowed to know that there is a difference. Which is approach is simpler
and more generic?

----

= Comprehensive Data Access and Update =

WHY!? The primary aim of Date's rules 5, 6 and 7 seems to be to ensure
that data integrity can be maintained when the data to be updated is
necessarily scattered across multiple tables. The obvious cause of this
is where data in the real world is packaged in n-dimensional chunks
called objects, and it is a requirement to keep reality and the database
in sync. Now why does [[MultiValue]] define data as coming in n-dimensional
arrays, again?

Implementing a bi-directional access language (read and write) is a
nightmare. SQL was meant to be for end-users - it was originally
called Structured English Query Language. I can only presume the
"English" was dropped because the end result bore no acceptable
resemblance to English.

On the other hand, one of the names for [[MultiValue]]'s query language is
"English", precisely because it is reasonably close to it. There is no
standard write language for [[MultiValue]] (unless you count SQL as it),
though, precisely because the generic task is so complex.

However, [[MultiValue]] does not need to require that we be able to update
views. A relational view is n-dimensional, and for any view where
requiring updates would make logical sense, [[MultiValue]] would store it as
a single array.

Equally, high level insert, update and delete is a completely arbitrary
requirement that is presumably relied upon to delete all related rows
that, in [[MultiValue]], would have been stored in a single array.

----

= Physical and Logical Independence =

This requirement in particular seems predicated on viewing things as a
database, rather than an information store. Okay, it is a
Relational Database Management System we're trashing...

"Logical Independence" requires that the DBA be able to rearrange how
data is stored without affecting the user's view of that data. MV,
however, restricts the DBA's freedom by imposing a practical requirement
that that view approximates to the real-world view of the thing being
modelled by the data. No single requirement highlights the divorce
behind relational's theory of data and the real world more clearly than
this one.

Given that MV imposes some resemblance between the database and the
reality it is modelling, and given also that modern implementations use
an OS file store rather than seeking to manage their own storage as one
huge blob, the physical independence is easily achieved. FILEs can be
placed in any convenient location.

This also addresses rule 11 - Distribution independence - in pretty much
the same way.

----

= Integrity Independence and Non-Subversion =

Currently missing from the MV model as a formal constraint. But the
relational model does not distinguish between "natural law" constraints,
where a description has no meaning outside of the object it describes,
and "statute law" constraints, relationships where the two objects can
have an independent existence independent of the relationship between
them.

A "natural law" constraint is unnecessary in MV because in a properly
designed database, the description is stored with the object and if the
object does not exist there is nowhere to store the description.

On the other hand, "statute law" constraints can be very dangerous -
enforcing constraints that don't exist in the real world thereby
requiring that the user enter data that is invalid in order to persuade
the database to accept data that is valid.

So this sort of satisfies the non-subversion rule in exactly the same
way - you can't subvert "natural law" constraints because the MV
structure enforces it. But you can subvert "statute law" relationships
because you can get at and edit the data directly.

MVDefinition - Revision history

Conversion script: link fix