Re: foundations of relational theory?

Originally posted by byrmol

> Here is the relational models conformance to a definition of a
> data model.

>

> Its general theory is set theory and predicate logic expressed as...

>

> * Structure - R-tables

> * Integrity - Domain, attribute, relation, database

> * Manipulation - R-operations (R-algebra & R-calculus)

>

> From your reply I am getting the impression that MV/PICK is not a data
> model at all but simply an application.

My reply wasn't intended to provide a mathematical model. I'm not a mathematician, so I couldn't give you a definition of the Pick model in those terms - and besides, I was getting hungry. Also, as I'm not a mathematician, I don't really understand http://plato.stanford.edu/entries/logicrelevance /#1 but I am sure nonetheless that there is *something* missing in relational theory in that it treats all data according to its relatedness and not according to its relevance. In meeting real world requirements involving sets of related data the Pick model *is* flexible enough and capable of treating data according to both relatedness and relevance. The other thread in CDT "Dreaming about redesigning SQL" is currently discussing a PersonsPhones example that illustrates this.

What is an application? I generally use the word to mean the application of software to solve a particular problem.

Particularly relevant to me at the moment, in the context of this discussion:

I have developed a framework consisting of Pick programs and parameter files of my own design. On its own the framework is a tool - nothing more. I wouldn't call it an application.

I'm currently developing an application that sits on top of the framework and allows people to develop applications. Applications developed this way also sit on top of the framework - like the flesh on a skeleton.

All of it sits on top of Pick. That means I structure data according to the definition I gave you. Pick insists I use these structures for my data sets - although it also allows me a great deal of freedom.

My framework has various layers - including one for input validation and also a data-abstraction layer. I guess you could, if you wanted to, equate the validation layer to the reactions a person might have to various stimuli - like, depending on whether something tastes good and/or is good for you, you'll either swallow it or spit it out immediately, if it ever gets as far as your mouth. It's not a Pick requirement that these matters of taste/discretion be defined, nor is it a requirement in my framework. Similarly, when you've swallowed something it might not agree with something you ate earlier - and it will be ejected (I'm beginning to think maybe I shouldn't have started on this analogy).

What users of my application choose to do in these layers is up to them - they ought to know what tastes good and can decide what's good for them. At a deeper, more biological level, some things can be said to "go together" but not others. It depends entirely on what you want *your* application to do.

When it comes to your third category, "Manipulation", I really don't know what to say. Whatever it is I certainly wouldn't say it in algebraic or calculus - I don't speak it. I can tell you that Pick stores data in a very compact but eminently useable form and that, especially due to the direct hashing method for accessing data, it is highly efficient. Can you translate some of that algebra and calculus into words that might have more relevance to me?

Regards

Mike.

--
Posted via http://dbforums.com