Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Date's First Great Blunder

Re: Date's First Great Blunder

From: Anthony W. Youngman <wol_at_thewolery.demon.co.uk>
Date: Fri, 23 Apr 2004 18:23:16 +0100
Message-ID: <JfBFsBEEEViAFw6b@thewolery.demon.co.uk>


In message <pan.2004.04.20.22.11.28.448611_at_dutra.fastmail.fm>, Leandro Guimar„es Faria Corsetti Dutra <leandro_at_dutra.fastmail.fm> writes
>Em Mon, 19 Apr 2004 14:01:11 -0500, Dawn M. Wolthuis escreveu:
>
>>> Alphora Dataphor.
>>
>> Great -- so what advantages can you see in a real relational database
>> management system that are not present in the not-exacxtly-relational
>> implementations that are out there? In other words, in what way is a pure
>> relational implementation more useful than one that is not-so-pure?
>
> User defined types as first class citizens, including special
>values to get us rid of NULLs.

As I said in another post - great! But I've been thinking ...

Does relational draw a distinction between data and metadata? Does it also require a separation between the database (that acts on metadata) and applications (that act on data)?

Because if the answer to both questions is yes, then we are trying to square a circle. "Nature opposes any change". Apply a voltage across a wire, current starts to flow, which causes a voltage in the opposite direction, which resists the flow of the current ... - the normal behaviour of the physical world ...

Analysis of a real-world object to obtain data to put into a database involves considerable transformation. In particular, it involves the destruction of a large amount of metadata. As others have noted, analysis is not a closed system and the metadata can be replaced by the equivalent data (the metadata that two "order details" are physically on the same piece of paper called an invoice is replaced by the data that both order detail rows in the database share the same invoice-no as a foreign key).

The only way to make this information available to the DBMS again is to put application logic INSIDE the DBMS - indeed - to make user-defined types "equal citizens" with pre-defined types we need to be able to allow the user to modify the DBMS, and not just the database.

To me this flies in the face of all the claims by the current "relational" databases to be able to protect the data from the programmer - how can it if the programmer has the ability to write code to convert data into metadata?

This seems to me to be even more evidence in favour of the Pick approach, which is to separate data integrity from data storage, and to store metadata as "just more data". In other words, data integrity should be enforced by a mechanism similar to the current relational trigger, and not by metadata in the datastore itself.

The application layer sits on top of a data integrity layer which sits on top of a datastore layer. Current "relational" databases muddle the integrity layer into both the datastore and the application layer. Pick just shoves the whole lot into the application layer ... (although it's added a trigger layer which could do it.)

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
Received on Fri Apr 23 2004 - 12:23:16 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US