Do Data Models Need to built on a Mathematical Concept?
Ian
Example, The relational model has set theory.
Bob Badour
news:17ce58cf.03042...@posting.google.com...
> Do Data Models Need to built on a Mathematical Concept?
>
> Example, The relational model has set theory.
What, other than mathematics, do you propose?
Ian
with the relational model, not agree?
"Bob Badour" <bba...@golden.net> wrote in message
news:saVpa.620$325.12...@mantis.golden.net...
Marshall Spight
>
> Example, The relational model has set theory.
Only if you care about things like correctness. Most people
don't; most people only care about performance. If you get
the right answer most of the time, they're happy.
The general thinking seems to be that coming up with the
wrong answer really quickly is much better than coming up
with the right answer a bit more slowly.
Most data models today are built on "The C Programming
Language" by Kernigan and Ritchie.
Marshall
Alfredo Novoa
> Do Data Models Need to built on a Mathematical Concept?
The "Data Model" concept is a mathematical concept.
But the term is not very fortunate. I would be better it were called
"Theory of Data"
> Example, The relational model has set theory.
The Relational Model IS the application of predicate logic and set
theory to the data management camp.
Regards
Alfredo
Alfredo Novoa
> What about the Object Model - It wasn't built on a mathmatically proof , as
> with the relational model, not agree?
There is not a Data Model called "The Object Model".
Regards
Alfredo
Eric Junkermann
> with the relational model, not agree?
>
>
Perfectly correct. What was it built on? And also what is it? If you know
where there is a reasonably widely agreed definition of the Object Model,
please point me to it.
(I assume that we are talking about an Object Data Model, not, for instance, an
Object Programming Model.)
Eric
Ian
a mathematical concept, they are not "correct". Data model follow rules, If
the model conforms to the rules, it is correct. You talk about the
implementation of data models as a deciding factor is the design?
"Marshall Spight" <msp...@dnai.com> wrote in message
news:A73qa.74656$Si4....@rwcrnsc51.ops.asp.att.net...
Ian
Sorry, The object Data Model. I could make make the same claim about
the object-relational data model, any one agree?
Regards
Ian.
Costin Cozianu
> Do Data Models Need to built on a Mathematical Concept?
>
> Example, The relational model has set theory.
Jayadev Misra once said: (
http://www.cs.utexas.edu/users/misra/Speeches.dir/Schlumberger.Jan02.pdf
) :
"...And, I contend that lack of useful theorems about a typical C++
program is what makes it so difficult to make claims about it: its
intent, whether a particular change will have a disastrous effect on its
execution and whether it can be integrated with other programs. In other
words, we typically build mathematical systems whose properties we
cannot discern."
Se here you have it: Computer Systems, Software Systems, Informations
Systems -- whatever you want to call them are in essence *mathematical
objects*, whether you like them or not to be that's what they are.
So even if you think you build your object model, custom C hacks, device
driver -- whatever, without using or better said without thinking about
Mathematics, in the end you'll end up with a *mathematical object*
that's the essence of it. So here you have it: all data models, even the
bad XML data model, or the equally bad ODMG object data model are
*mathematical*, from this perspective your question has no sense.
And now, once we put this confusion behind we can see that there are two
categories or two extremitities on a quality scale, there are
mathematical objects :
- WHO'S PROPERTIES WE *CAN* DISCERN
or
- WHO'S PROPERTIES WE *CANNOT* DISCERN
If you buid your mathematics starting from a sound theory, using careful
design and forethought about your objectives (what in the end you want
to accomplish), and *mathematical rigor*, you end up with a mathematical
system who is sound, who's properties you can discern, and who is very
*adequate* to tackle the problem you want it to tackle (otherwise you
can try to apply differential equations to solving integer optimization
problem years in a row you'll bang your head against the all).
Or you can say you don't need to have to do anything with mathematics
and you'll end uo in ignorance, and with mathematical objects who's
properties you cannot discern. In case of object models, it's even worse
than that: practitioners don't even have a *ing clue what properties
they should look for.
For example in relational model you can establish useful properties
about the database schema: whether it's normalized or not, while using
today SQL implementation you can reasonably establish how long a
operation will take, you will establish the ACID properties as part fo
the deal with the DBMS vendor, again reasonably well ( cause I don;t
know of any DBMS vendor who aquitted itself of the Proof Obligation
Dijkstra talked about), and also you know, and you know _why those
properties are important for your system_.
Now compare that to your typical OO mathematical objects:
- You largely have no clue what properties they have
- People don't know what properties are really important about their
mathematical objects
For typical examples:
- most Java programmers know how to use threads and they programmed
at list one multithreaded program. But they have no clue if it's safe,
if their program will not deadlock, lead to starvation, etc
- even Sun's engineers have no clues, because key APIs exhibit
critical bugs like deadlock, infinite loops, OutOfMemory errors, JVM
crashes etc.
- C++ programmers: anyone has seen one that can prove that his
non-trivial programs doesn't have memory leaks or memory access violation ?
- Object Management Group. They did the stupid UML specification
that all OO "architect" (by the way, I am one of those) and their
grandmas use to monkey around with the upper management for the
"illusion of control". Anybody knows about any property you should look
for in a UML diagram ? No, and frankly you can't really look for any
property, because UML is not a mathematical system *well defined*.
In the end, if you looked for a debate there's no room for debate in
here, it is your choice.
Either you build software systems who's important properties you can
discern, or you can build software systems about which all you can say
is: it si likely to work, or 3 months of extensive QA shows that the
defect rate is acceptable and let's ship the hell out of it ot the customer.
Bob Badour
news:<e4330f45.03042...@posting.google.com>...
> > "Ian" <kellizer(nospam)@hotmail.com> wrote in message
news:<SWXpa.670$xI5...@newsfep3-gui.server.ntli.net>...
> >
> > > What about the Object Model - It wasn't built on a mathmatically proof
, as
> > > with the relational model, not agree?
> >
> > There is not a Data Model called "The Object Model".
> >
> > Regards
> > Alfredo
>
> Sorry, The object Data Model.
There is not one of those either.
> I could make make the same claim about
> the object-relational data model, any one agree?
The term "object-relational" is hype. Anyone adequately educated could
recognize that on their own without needing any reassurance from others.
Marshall Spight
> I think that's a widely inaccurate notion, that if data models don't follow
> a mathematical concept, they are not "correct". Data model follow rules, If
> the model conforms to the rules, it is correct.
Well, what I'd call a data model is a set of rules. It sounds like perhaps
you're calling the implementation of the rules in code the "data model."
It seems to me that if the data model, the rules, or whatever, are built
on sound mathematical foundations, you've got something sound. If
it was just thrown together in order to be easy to implement, (the
usual case) then what you've got is anyone's guess.
> You talk about the
> implementation of data models as a deciding factor is the design?
I didn't quite understand this sentence, but I'll note that I'm just talking
about model, not implementation; they are separate.
See also Costin's post, which says a lot of interesting and important
things really well. (That is, better than I could have.)
Marshall
Paul Vernon
news:b8bk2f$8cccm$1...@ID-152540.news.dfncis.de...
> Ian wrote:
> > Do Data Models Need to built on a Mathematical Concept?
> >
> > Example, The relational model has set theory.
>
> Jayadev Misra once said: (
> http://www.cs.utexas.edu/users/misra/Speeches.dir/Schlumberger.Jan02.pdf
> ) :
>
> "...And, I contend that lack of useful theorems about a typical C++
> program is what makes it so difficult to make claims about it: its
> intent, whether a particular change will have a disastrous effect on its
> execution and whether it can be integrated with other programs. In other
> words, we typically build mathematical systems whose properties we
> cannot discern."
Top post Costin, top post.
That lecture is very interesting indeed. Here we have Jayadev Misra, the
inheretor of one of Dijkstra's chairs saying:
"... let me suggest a problem worthy of your attention. The fundamental
structuring principle for systems is hierarchical organization. It permeates
the world around us; social and political systems are hierarchical. We have
found from experience that tree-structured file systems, hierarchical
organization of large domains such as the internet, and system designs in
which each component itself is regarded as a system, is convenient. Even
within object-oriented programming, the notions of components and
encapsulation impose hierarchical structures."
but wait, he then says next
"Is it time to consider a more democratic structuring principle, similar
to what they have in relational databases?"
Unbeliveable! Why have computer scientists taken 30 years to to consider this?
Where have they been? His next words just confim this.
"I am driven to these considerations by the need to view a system from
different angles. I can look at this building floor by floor, or by its
electrical, plumbing and computational infrastructures, or by the people who
work here by their professions. I would like to slice the same system in a
variety of ways depending on which aspect of it I want to study. I would like
to see my file system not only as being hierarchical but also providing
groupings according to other criteria: all files that constitute the chapters
of a book ought to be arranged in a sequence so that I can read from Chapter 3
to 7, say. I would like to see the list of all printers in the campus, even
when the campus network is organized by departments. How do we support
multiple views of a system while retaining the advantages of hierarchical
structuring? How do we exploit multiple views during program design and
evolution?"
This was one of the fundamental incites of the relational model. It was
highlighted when Codd created formal network and hierarchal data models with
the purpose of comparing them to the relational model and in the process
showing the superiority of the relational model. That superiority being
exactly as characterised by Jayadev; the RM is democratic - all data is
treated equally - and therein lies it's advantage.
To me, this lecture shows that the wider academic community never really *got*
the Relational Model. They got the relational algebra/calculus (albeit mostly
restricting themselves to binary relations), they could see the benefit of
data independence, but they missed the equally important *application
independence* that relationally defined data can provide.
Note how Jayadev said "...similar to what *they* have in relational
databases". Why did he not say "what *we* have"? Why does he not consder
relational databases as part of his heratige? Maybe the fact he said
'relational databases' and not in 'the relational data model' is also telling.
His question "How do we exploit multiple views during program design and
evolution?" is one that us relational people have always been able to answer
(at least since views have been considered updatable).
His other question "How do we support multiple views of a system while
retaining the advantages of hierarchical structuring?", is, if you will allow,
being partially answer by the more sensible efforts to integrate XML with SQL
databases. Specifically I'm thinking of XQuery and XTables, that look much
more respectable than you might think would come out of such an effort. (See
To conclude, I think there is still a big gap in understanding between the
'programming community' - the academic side typified by Jayadev - and the
'database community' - the academic side being represented in it's seeming
absence in the universities by outsiders such as Chirs Date.
To bridge this gap, I am thinking that there needs to be bridging of
functional programming with relational programming. Such a bridging is not
just a matter of a relational interface to FPs that allows persistent data
storage, no, it is the full integration of the two worlds.The Relational model
needs improving with the type theory and program/theory proving of FPs and FPs
need to have relations and the relational algebra as first class primitives,
and they need to accept the principle that all permantly stored, generally
accessible data needs to be represented as relations.
Reflecting Jayadev's closing remarks, we need the relational model and
relational programming to become part of the mainstream of computer science. I
don't believe we are there yet.
Thanks. Online & off-line discussions encouraged.
Paul Vernon
Business Intelligence, IBM Global Services
Paul Vernon
news:b8eg1v$1pbo$1...@gazette.almaden.ibm.com...
[snip]
> His other question "How do we support multiple views of a system while
> retaining the advantages of hierarchical structuring?", is, if you will
allow,
> being partially answer by the more sensible efforts to integrate XML with
SQL
> databases. Specifically I'm thinking of XQuery and XTables, that look much
> more respectable than you might think would come out of such an effort. (See
Opps, I missed off the link
"XTABLES: Bridging relational technology and XML" (IBM Systems Journal 41,
No. 4, 2002)
http://www.research.ibm.com/journal/sj/414/funderburk.pdf
Regards
Marshall Spight
>
> to what they have in relational databases?"
Absolutely.
> Unbeliveable! Why have computer scientists taken 30 years to to consider this?
> Where have they been? His next words just confim this.
The model I have for the relationship that the relational world has with
the rest of the programming world is that of the Indian subcontinent's
drift into Asia: inexorable but very slow, and causing chaos on
a Himmalayan scale.
> To me, this lecture shows that the wider academic community never really *got*
> the Relational Model. They got the relational algebra/calculus (albeit mostly
> restricting themselves to binary relations), they could see the benefit of
> data independence, but they missed the equally important *application
> independence* that relationally defined data can provide.
While I agree, I think there's still more. For example, the fact that relational
data is content-addressable is huge. Lots of other things, too.
By the way, I thought the file system example [not quoted] was interesting.
Date's fond of saying that many things that are modeled as hierarchies
aren't really hierarchies, and the example I always use is the filesystem.
It seems to me that filesystem design reflects the thinking of the standard
modern programmer. The basic meme is that there are only two data structures:
list and tree. If you can't make a list work, use a tree. So we model the filesystem
as a tree. But then, hey, you have to have *hard links* don't you? And you
also need soft links, right? So you end up with a graph, but everyone insists
on pretending that it's a tree. (There's gotta be a line about "can't see the
forest" in here somewhere.) Modern application programmers use a tree
structure for almost everything more complex than a list, whether it's
appropriate or not. Witness the ascendance of XML.
> Note how Jayadev said "...similar to what *they* have in relational
> databases". Why did he not say "what *we* have"? Why does he not consder
> relational databases as part of his heratige?
Well, because it's not. The database world has been off in a corner all this
time. Database programming is a definite ghetto.
> To conclude, I think there is still a big gap in understanding between the
> 'programming community' - the academic side typified by Jayadev - and the
> 'database community' - the academic side being represented in it's seeming
> absence in the universities by outsiders such as Chirs Date.
Totally agree.
> To bridge this gap, I am thinking that there needs to be bridging of
> functional programming with relational programming.
Why functional programming? Why not imperative programming as
well? It seems to me that an imperative programming language with
first-class relational support, and a type system a la ML would be
Most Excellent. (I've been kicking this idea around for about
a year now. I have some primitive notes, and of course I've read
TTM a few times. Still wrestling with my OOP heritage, though.)
Marshall
Costin Cozianu
You'll excuse me if what I read in the article triggered my recollection
of this formidable saying of Dijkstra:
"In the software business there are many enterprises for which it is not
clear that science can help them; that science should try is not clear
either."
XML is doomed to be such an enterprise.
I find many of the (unspecified) premises of the article rather not
happening in practice, if I'm ever going to see them I'll probably
consider them bad engineering, and of course those premises do raise a
hell of a lot of problems, that the proposed approach might or might not
address.
The quality of ad-hoc solutions to ad-hockery kind of problems is
certainly not going to be great, and frankly speaking reading the
article and seeing some of the unnecessary complexities in their code
samples, one has to wonder how have we got here ? Where do we depart
them and what is such a serious problem that requires such a complex of
a solution for moving a bunch of bytes around the computer ?
Well, the point that the authors departed from is that you have to have
XML in the database, or to "integrate" XML whatever that means. Yes, of
course, then you have problems, lots of them.
Well, those are not the problems of my users. The problems of my users
are orthogonal to whether I store native XML in relational databases
(which is something that I refrain from qualifying for the sake of
civility). So the article has 0 value for me, and I consider that IBM
will likely spend a hell of a lot more money for no benefit of their
users. Reminds me of the sheer engineering effort of Oracle to put first
objects in the database as a PL/SQL extension, and then make room for
them in tables, of course I would regard any usage of those features a
serious engineering mistake.
Of course, I can imagine a reply, but you have to deal with XML because
it is industry standard, and other systems will want XML and so on so
forth, and even if XML is technically less than desirable, the sheer
force of the whole industry being behind it makes it a better
engineering solution to virtually all its competitors, byt the amount of
tools put at your disposal, your needs fo integration, etc, etc, etc
Yes. I will admit XML is a neccessary evil for the time being, but I
won't make a deal with the devil for the sake of it :) And the forces
of industry might be great, but they are petty nothing compared to the
daunting force of Mathematics.
That's what made COBOL obsolete, C++ obsolete, and will make Java , UML,
C# and XML onsolete soon. That's what makes Lisp still alive with a
design dating back to 1958, that's what makes Dijkstra's Discipline Of
Programming be still a book in print. You can have all your industry
behind you, that's easy part, the hard part in our business is to deal
with Mathematics.
Best regards,
Costin Cozianu
Lauri Pietarinen
>
>
> "Is it time to consider a more democratic structuring principle, similar
> to what they have in relational databases?"
>
> Unbeliveable! Why have computer scientists taken 30 years to to consider this?
> Where have they been? His next words just confim this.
YES! This is the very question I have been trying to find an answer
to for the last years! Any suggestions?
[snip]
Thanks Paul, for summarising the issue so nicely. I am, though a bit
sceptical on the XML-stuff...
>
> To bridge this gap, I am thinking that there needs to be bridging of
> functional programming with relational programming. Such a bridging is not
> just a matter of a relational interface to FPs that allows persistent data
> storage, no, it is the full integration of the two worlds.The Relational model
> needs improving with the type theory and program/theory proving of FPs and FPs
> need to have relations and the relational algebra as first class primitives,
> and they need to accept the principle that all permantly stored, generally
> accessible data needs to be represented as relations.
I tend to agree with Marshall here that there is still room for
an imperative component, both inside the implementations of the
datatypes and their operators and outside and around the relations.
This is what I understand is proposed in TTM (www.thethirdmanifesto.com)
and implemented in Dataphor by Alphora.
Of course the more we can keep in the relational realm the better,
but I believe there will always be parts of the application that
will have to be tackled imperatively.
>
> Reflecting Jayadev's closing remarks, we need the relational model and
> relational programming to become part of the mainstream of computer science. I
> don't believe we are there yet.
I think it requires that computer scientists realise that what's good for
mathematics (i.e. relations) is good for computer science also and that
in the end of the day we have to base everything on mathematics anyway.
regards,
Lauri Pietarinen
Paul Vernon
> "Paul Vernon" <paul....@ukk.ibmm.comm> wrote in message
news:b8eg1v$1pbo$1...@gazette.almaden.ibm.com...
> >
> > "Is it time to consider a more democratic structuring principle,
similar
> > to what they have in relational databases?"
>
> Absolutely.
>
>
> > Unbeliveable! Why have computer scientists taken 30 years to to consider
this?
> > Where have they been? His next words just confim this.
>
> The model I have for the relationship that the relational world has with
> the rest of the programming world is that of the Indian subcontinent's
> drift into Asia: inexorable but very slow, and causing chaos on
> a Himmalayan scale.
LOL
> > To me, this lecture shows that the wider academic community never really
*got*
> > the Relational Model. They got the relational algebra/calculus (albeit
mostly
> > restricting themselves to binary relations), they could see the benefit of
> > data independence, but they missed the equally important *application
> > independence* that relationally defined data can provide.
>
> While I agree, I think there's still more. For example, the fact that
relational
> data is content-addressable is huge. Lots of other things, too.
I'd be interested in your list.
Although I think I would consider content addressed data as but an aspect of
the Information Principle which for me, is itself just a weak version of
application independence.
All data is equal - all is relations. If data was index addressed, or
positionally addressed or whatever, then there is information embedded in the
addressing scheme that is not relations, not equal. Anything but content
addressing is going to be specific to some set of applications.
> By the way, I thought the file system example [not quoted] was interesting.
> Date's fond of saying that many things that are modeled as hierarchies
> aren't really hierarchies, and the example I always use is the filesystem.
> It seems to me that filesystem design reflects the thinking of the standard
> modern programmer. The basic meme is that there are only two data
structures:
> list and tree. If you can't make a list work, use a tree. So we model the
filesystem
> as a tree. But then, hey, you have to have *hard links* don't you? And you
> also need soft links, right? So you end up with a graph, but everyone
insists
> on pretending that it's a tree. (There's gotta be a line about "can't see
the
> forest" in here somewhere.) Modern application programmers use a tree
> structure for almost everything more complex than a list, whether it's
> appropriate or not. Witness the ascendance of XML.
Spot on.
In a way, XML is our failiure, or at least it stems from the failure to bridge
your two continents. I'ld be very interested to know what Tim-Berners Lee
knows of the relational model. (ho-ho maybe this is it
http://www.w3.org/2002/Talks/1107-marconi-tbl/slide13-2.html (found using his
marvellous WWW I must add) )
> > Note how Jayadev said "...similar to what *they* have in relational
> > databases". Why did he not say "what *we* have"? Why does he not consder
> > relational databases as part of his heratige?
>
> Well, because it's not. The database world has been off in a corner all this
> time. Database programming is a definite ghetto.
So it seems. I would like to understand why it is so, although I think the
answers are probably many and there are more pressing matters.
> > To conclude, I think there is still a big gap in understanding between the
> > 'programming community' - the academic side typified by Jayadev - and the
> > 'database community' - the academic side being represented in it's seeming
> > absence in the universities by outsiders such as Chris Date.
>
> Totally agree.
>
>
> > To bridge this gap, I am thinking that there needs to be bridging of
> > functional programming with relational programming.
>
> Why functional programming? Why not imperative programming as
> well? It seems to me that an imperative programming language with
> first-class relational support, and a type system a la ML would be
> Most Excellent. (I've been kicking this idea around for about
> a year now. I have some primitive notes, and of course I've read
> TTM a few times. Still wrestling with my OOP heritage, though.)
Why functional programming? For all the reasons that the folks on
comp.lang.functional would give for the superiority of FP over conventional
ones. Because functions _are_ relations. Because they don't have variables,
and we have one great big one to let them use for all their interactions with
the outside world and so maybe solve their I/O and GUI difficulties.
In short because FPs and relational programming are already very similar (as
far as I can tell - I've written but one non-trivial functional program in my
life; in Miranda on my not so recent CS degree), and I would believe that a
merge, or at least a bridging of the chasm might not be that difficult.
Not being an acadmenc nor in research, I would not know how much work towards
such a merging might have already been done. A quick look around brought up
the following for one:
"Structural Recursion as a Query Language" with the quote
"We ... put forward a programming paradigm that tries to get close to both
the semantic simplicity of relational algebra and the expressive power of
unrestricted programming languages. Its main computational engine is
structural recursion on sets"
and in the introduction, they argue againt the concept of 'embedded query
languages' due to their "impedance mismatch" and (in my words) the
proving/understanding and optimisation difficulties when half an algorithm is
in relational algebra and the rest in some more powerful (read: potentially
non-terminating) external language.
Dijkstra's shortest path algorithm in SQL anyone?
Regards
Paul Vernon
news:e9d83568.03042...@posting.google.com...
> "Paul Vernon" <paul....@ukk.ibmm.comm> wrote in message
news:<b8eg1v$1pbo$1...@gazette.almaden.ibm.com>...
> >
> > but wait, he then says next
> >
> > "Is it time to consider a more democratic structuring principle,
similar
> > to what they have in relational databases?"
> >
> > Unbeliveable! Why have computer scientists taken 30 years to to consider
this?
> > Where have they been? His next words just confim this.
>
> YES! This is the very question I have been trying to find an answer
> to for the last years! Any suggestions?
Beats me. I didn't even have a relational databases course on my CS degree.
OK, so it was cancelled that year, but it no-one seemed particularly put out
about it and I knew no better at the time (I think I had the impression that
they were old hat, industry things only, and this newfangled OO thing would
replace them..!!!!)
> [snip]
>
> Thanks Paul, for summarising the issue so nicely.
No worries. It felt good to get that post out
> I am, though a bit sceptical on the XML-stuff...
So am I , so am I....
> > To bridge this gap, I am thinking that there needs to be bridging of
> > functional programming with relational programming. Such a bridging is not
> > just a matter of a relational interface to FPs that allows persistent data
> > storage, no, it is the full integration of the two worlds.The Relational
model
> > needs improving with the type theory and program/theory proving of FPs and
FPs
> > need to have relations and the relational algebra as first class
primitives,
> > and they need to accept the principle that all permantly stored, generally
> > accessible data needs to be represented as relations.
>
> I tend to agree with Marshall here that there is still room for
> an imperative component, both inside the implementations of the
> datatypes and their operators and outside and around the relations.
From what I understand of type theory, you would defiantly want to go the
functional route for user defined type implementations.
> This is what I understand is proposed in TTM (www.thethirdmanifesto.com)
> and implemented in Dataphor by Alphora.
Date & Darwen in The Third Manifesto (TTM) wrote:
"do not infer from our assumptions of an imperative style that we discount
the possibility of (e.g.) a "functional programming style" D at the time of
writing, however, we have not investigated such a possibility in any depth"
Did someone else on the group say that if Date knew functional programming, he
would much prefer it?
Maybe John Backus (circa '78) could convince you
"Can Programming Be Liberated from the von Neumann Style"
www.stanford.edu/class/cs242/readings/backus.pdf
> Of course the more we can keep in the relational realm the better,
> but I believe there will always be parts of the application that
> will have to be tackled imperatively.
Show me a (useful) algorithm that cannot be performed in a relational algebra
(hypothetically extended with 'features' from the FP world).
Why have two languages if we can get away with one?
BTW does anyone have a good defn of 'imperative'. In the footnotes of the
TTM, Date (and it would be him) says:
"we have recently observed a distressing tendency to confuse procedural
with imperative ... In particular, D - or its relational portion, at any
rate - is imperative but not procedural"
Regards
Paul Vernon
Re-reading my words, I said "much more respectable [ideas may come out of this
effort] than you might think". Following Fabian Pascal, you would think no
useful ideas could ever arrive, indeed after the experience of the OO
extensions to SQL (DB2 in my case), no useful ideas at all showed up (which
annoyed me, I thought I might get half-way useable User Defined Types at the
very least). This time I am just a little more hopeful, that is all. Maybe it
will be 'higher-order' languages (like SchemaSQL). That is certainly one thing
that the FP guys have (or are on the way to getting with 'meta-programming'
research) and it's one of the things that I want in my relational languages.
BTW I do believe that the _underlying_ goal is laudable. Namely
non-relational, non-scalar access to relational data. (albeit on relational
terms). Indeed the manifesto suggests ARRAY types that can be associated with
relation types. It's just a shame that the promoters of this XML + SQL stuff
don't see things in such terms...
Marshall Spight
> "Lauri Pietarinen" <lauri.pi...@atbusiness.com> wrote in message
> news:e9d83568.03042...@posting.google.com...
>
> OK, so it was cancelled that year, but it no-one seemed particularly put out
> about it and I knew no better at the time (I think I had the impression that
> they were old hat, industry things only, and this newfangled OO thing would
> replace them..!!!!)
Ha ha! At my university, I had the opportunity to take database classes
from Michael Stonebreaker, but I figured it would be about the same
thing as taking accounting.
> > I tend to agree with Marshall here that there is still room for
> > an imperative component, both inside the implementations of the
> > datatypes and their operators and outside and around the relations.
>
> From what I understand of type theory, you would defiantly want to go the
> functional route for user defined type implementations.
("defiantly" of "definitely?" Not that I am opposed to doing things defiantly.)
Could you expand on that? It seems to me that the core of what I get out
of TTM as far as UDTs goes is the clear definition of values and variables.
I don't see anything particularly wrong with having variables. It seems to
me the problems come when you allow variables to contain other variables.
(That is, objects, pointers, etc.) As long as all a variable can do is hold
a value, and variables can't be aliased, you are side-effect free. And
THAT I think is the real issue: ridding ourselves of side effects, and not
functional vs. imperative. (The functional guys just come out looking
better today because they've managed to free themselves from side effects.
But I'd say they did it the hard way.)
> Show me a (useful) algorithm that cannot be performed in a relational algebra
> (hypothetically extended with 'features' from the FP world).
> Why have two languages if we can get away with one?
Well, we certainly *can't* get away with one. There are application languages
and there are systems languages. Take Java and C++ today, for example. Sure,
they're deeply flawed, but they both have some cool things in them, and they're
the two most popular languages today. One is an application language; the
other is a systems language. I'd certainly hate to use either for the other's purpose,
although it can be done.
This language I'm semi-seriously designing, is an imperative relational language.
It's great for writing applications. It'd suck to write a device driver in, in a manner
similar to how much it would suck to write a device driver in Java.
And besides that, why not allow one language to be embedded in another?
I'd claim that's what regular expressions are: a special purpose sublanguage.
> BTW does anyone have a good defn of 'imperative'. In the footnotes of the
> TTM, Date (and it would be him) says:
>
> "we have recently observed a distressing tendency to confuse procedural
> with imperative ... In particular, D - or its relational portion, at any
> rate - is imperative but not procedural"
I always figured they meant the same thing. FOLDOC calls them synonyms:
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?imperative
Marshall
Marshall Spight
> *got*
> > > the Relational Model. They got the relational algebra/calculus (albeit
> mostly
> > > restricting themselves to binary relations), they could see the benefit of
> > > data independence, but they missed the equally important *application
> > > independence* that relationally defined data can provide.
> >
> > While I agree, I think there's still more. For example, the fact that
> relational
> > data is content-addressable is huge. Lots of other things, too.
>
> I'd be interested in your list.
Let's see:
relational calculus
content-addressable data
a *formal* way to prove that your data is free of redundancies, and
therefor immune to update, insert, and delete anomalies. And if it isn't,
a set of algorithms to transform it so that it is. (the Normal Forms.)
persistence
transactions
declarative integrity constraints
the ability to alter the performance characterstics of data access
at *runtime* by, say, adding an index.
I suppose a number of those are RDBMS features, and not features of
the relational model per se. But still. (I really ought to write that list
down; it comes out different every time I try to reproduce it.)
> Although I think I would consider content addressed data as but an aspect of
> the Information Principle which for me, is itself just a weak version of
> application independence.
> All data is equal - all is relations. If data was index addressed, or
> positionally addressed or whatever, then there is information embedded in the
> addressing scheme that is not relations, not equal. Anything but content
> addressing is going to be specific to some set of applications.
Hmm. It appears I have a very different definition of application independence
than you do. Maybe I'm too narrow about it. Come to think of it, I don't
think I've ever seen the term defined. I've always just thought of it as the
fact that your data is independent of your applications. That is, it survives
them and isn't directly tied to them, but rather accessed through some
API.
I definitely agree, though, that the Information Principle is key.
> In a way, XML is our failiure, or at least it stems from the failure to bridge
> your two continents.
Wow. "XML is our failure" is a very powerful way of saying it.
> I'ld be very interested to know what Tim-Berners Lee
> knows of the relational model. (ho-ho maybe this is it
> http://www.w3.org/2002/Talks/1107-marconi-tbl/slide13-2.html (found using his
> marvellous WWW I must add) )
I am very fond of saying, to whoever will listen, that Tim Berners-Lee set
computing back by decades. His sucess in pushing hierarchical XML for
data transfer takes data management back to the 1960s, and what's less
of a regression but perhaps a worse sin, he's taken user interfaces back
to about 1985. Having written both GUI client apps and web apps, it
is appalling to me how primitive the UI the web provides is. Where's
the tree control? Where are the menus? How about a sortable table?
It just sucks. And don't even talk to me about Javascript as being some
kind of cure. :-) And now the insult of the frickin' "semantic web." Argh,
I hate that guy.
Of course, I don't get much traction with that argument, especially at
work. My company lives and dies by the web.
> > > To bridge this gap, I am thinking that there needs to be bridging of
> > > functional programming with relational programming.
> >
> > Why functional programming? Why not imperative programming as
> > well? It seems to me that an imperative programming language with
> > first-class relational support, and a type system a la ML would be
> > Most Excellent. (I've been kicking this idea around for about
> > a year now. I have some primitive notes, and of course I've read
> > TTM a few times. Still wrestling with my OOP heritage, though.)
>
> Why functional programming? For all the reasons that the folks on
> comp.lang.functional would give for the superiority of FP over conventional
> ones. Because functions _are_ relations. Because they don't have variables,
> and we have one great big one to let them use for all their interactions with
> the outside world and so maybe solve their I/O and GUI difficulties.
> In short because FPs and relational programming are already very similar (as
> far as I can tell - I've written but one non-trivial functional program in my
> life; in Miranda on my not so recent CS degree), and I would believe that a
> merge, or at least a bridging of the chasm might not be that difficult.
Well, I don't see why a sequence of expressions, including the use of
local variables, is any more of a mathematical function than in a single
complex expression that eschews variables.
It seems to me that the reason why ML, say, is so awesome, is not because
it's functional, but because it has such an excellent type system. I can't
think of a single imperative language that has an excellent type system,
but I don't see anything that would make it impossible.
> and in the introduction, they argue againt the concept of 'embedded query
> languages' due to their "impedance mismatch" and ...
That whole impedance mismatch issue is, again, "merely" an issue with
the type system. Note that databases *must* use a value-based type
system, and functional languages *must* use a value-based type system.
Imperative language tend to use unnecessarily complex, close-to-the-metal,
variables-can-contain-other-variables type systems, but there's nothing
that *requires* them to do so. You could have an imperative language
with a type system as good as ML's, but including variables. (Local
variables, at least.)
> (in my words) the
> proving/understanding and optimisation difficulties when half an algorithm is
> in relational algebra and the rest in some more powerful (read: potentially
> non-terminating) external language.
> Dijkstra's shortest path algorithm in SQL anyone?
Hmm. Have to think about that.
> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services
Say, you wouldn't happen to be aware of the existence of an ODBC driver
in IBM's Single Sign On product line, would you? I wrote that.
Marshall
Lauri Pietarinen
>>I tend to agree with Marshall here that there is still room for
>>an imperative component, both inside the implementations of the
>>datatypes and their operators and outside and around the relations.
>>
>>
>
>From what I understand of type theory, you would defiantly want to go the
>functional route for user defined type implementations.
>
>
>
>>This is what I understand is proposed in TTM (www.thethirdmanifesto.com)
>>and implemented in Dataphor by Alphora.
>>
>>
>
>Date & Darwen in The Third Manifesto (TTM) wrote:
> "do not infer from our assumptions of an imperative style that we discount
>the possibility of (e.g.) a "functional programming style" D at the time of
>writing, however, we have not investigated such a possibility in any depth"
>
OK, I am a bit out of my depth here, I have to admit. I don't know the
difference between imperative
and procedural - I thought they were the same thing. I would be
grateful for any clarification on this...
>>Of course the more we can keep in the relational realm the better,
>>but I believe there will always be parts of the application that
>>will have to be tackled imperatively.
>>
>>
>
>Show me a (useful) algorithm that cannot be performed in a relational algebra
>(hypothetically extended with 'features' from the FP world).
>Why have two languages if we can get away with one?
>
Well, any algorithm can be performed by a Turing machine, and I faintly
remember seeing (and learning)
a proof that says that anything that can be expressed with a Turing
machine can be expressed
with relations - however, there where some slight performance problems
;-). Does anybody remember
such a proof? It must have been from the early 70's.
regards,
Lauri Pietarinen
Paul Vernon
> "Paul Vernon" <paul....@ukk.ibmm.comm> wrote in message
news:b8hirr$3kgo$1...@gazette.almaden.ibm.com...
> > "Marshall Spight" <msp...@dnai.com> wrote in message
> > news:WcBqa.632745$L1.180197@sccrnsc02...
> > > > To me, this lecture shows that the wider academic community never
really
> > *got*
> > > > the Relational Model. They got the relational algebra/calculus (albeit
> > mostly
> > > > restricting themselves to binary relations), they could see the
benefit of
> > > > data independence, but they missed the equally important *application
> > > > independence* that relationally defined data can provide.
> > >
> > > While I agree, I think there's still more. For example, the fact that
> > relational
> > > data is content-addressable is huge. Lots of other things, too.
> >
> > I'd be interested in your list.
>
> Let's see:
>
> relational calculus
I noted that one
> content-addressable data
> a *formal* way to prove that your data is free of redundancies, and
> therefor immune to update, insert, and delete anomalies. And if it
isn't,
> a set of algorithms to transform it so that it is. (the Normal Forms.)
Frankly I've always thought that normalisation is overblown. Redundancy is a
semantic matter. The database only know the semantics if you declare them to
it with integrity constraints. If you then want to keep more redundancies by
not normalising your database, then so be it. The DBMS won't allow you to
break the constraints so there is no problem. All you will find is that fewer
single relvar updates will work, and you will need to use multiple relvar
updates instead. Big deal.
> persistence
Hardly specifc to DBMSes. I think punch-cards got there first
> transactions
Dead wrong. Transactions are bad, real bad. In short they are not compatible
with the 'arrow of time'. They let you freeze time and that is not a good
model of reality. Start a new thread if you want to discuss the details, I've
a draft paper on the subject and a could do with some intelligent challenges
to sharpen up my argument.
> declarative integrity constraints
Yep, that is a big one, but again for me it is subsumed by application
independence. To use the terminology, unless all your business rules are
declared and enforced by the database, then each application will have to
reimplement your rules and be vetted before being given database access. The
goal of *strong application independence* is to allow any 'application'
whatsoever to access and update your database, and still gureantee maintian a
correct and working system even in a 'hostile' environment like the net.
> the ability to alter the performance characterstics of data access
> at *runtime* by, say, adding an index.
Just a consequence of data independence.
> I suppose a number of those are RDBMS features, and not features of
> the relational model per se. But still. (I really ought to write that list
> down; it comes out different every time I try to reproduce it.)
>
>
> > Although I think I would consider content addressed data as but an aspect
of
> > the Information Principle which for me, is itself just a weak version of
> > application independence.
> > All data is equal - all is relations. If data was index addressed, or
> > positionally addressed or whatever, then there is information embedded in
the
> > addressing scheme that is not relations, not equal. Anything but content
> > addressing is going to be specific to some set of applications.
>
> Hmm. It appears I have a very different definition of application
independence
> than you do. Maybe I'm too narrow about it. Come to think of it, I don't
> think I've ever seen the term defined. I've always just thought of it as the
> fact that your data is independent of your applications. That is, it
survives
> them and isn't directly tied to them, but rather accessed through some
> API.
>
> I definitely agree, though, that the Information Principle is key.
Its a term I use and possibly hasn't been defined. It's the independence of a
database from the applications that use it - the ability of a database to
stand alone and be valid even if it's only 'application' is the relational
language used dynamically directly by users.
> > In a way, XML is our failiure, or at least it stems from the failure to
bridge
> > your two continents.
>
> Wow. "XML is our failure" is a very powerful way of saying it.
>
Thank you. Of course it's not just our (by which I mean the 'database
community') failure. Some would even say it is the failure of society as a
whole, I would certainly not go that far, but it is certainly also a failure
of the 'programming community'. E.g. I saw this today on comp.lang.functional:
} Lately, I've spent some time working with Joe Armstrong's UBF
} (http://www.sics.se/~joe/ubf/site/home.html). In Joe's own words:
}
} "UBF is a language for transporting and describing complex
} data structures across a network. It has three components:
}
} * UBF(A) is a data transport format, roughly equivalent
} to well-formed XML.
} * UBF(B) is a programming langauge for describing types
} in UBF(A) and protocols between clients and servers.
} UBF(B) is roughly equivalent to to Verified XML,
} XML-schemas, SOAP and WDSL.
} * UBF(C) is a meta-level protocol between used between
} UBF servers."
[and Joe responded..]
} Actually this was the reason I designed UBF - it all goes back
} to a discussion that was floating around about 15 years ago -
} "wouldn't it be nice is Lisp could talk to Prolog and smalltalk etc...."
[snip]
} ..it appears to be at least as expressive as XML + WSDL but
} at a fraction of the complexity - UBF was *designed* to be easy
} to implement
> > I'ld be very interested to know what Tim-Berners Lee
> > knows of the relational model. (ho-ho maybe this is it
> > http://www.w3.org/2002/Talks/1107-marconi-tbl/slide13-2.html (found using
his
> > marvellous WWW I must add) )
>
> I am very fond of saying, to whoever will listen, that Tim Berners-Lee set
> computing back by decades.
I agree with you below, but man, without TimBL there would be no WWW. Even I
find it difficult to see how the relational model could have done a better job
at spreading the networked world than HTML and web browsers.
> His sucess in pushing hierarchical XML for
> data transfer takes data management back to the 1960s, and what's less
> of a regression but perhaps a worse sin, he's taken user interfaces back
> to about 1985. Having written both GUI client apps and web apps, it
> is appalling to me how primitive the UI the web provides is. Where's
> the tree control? Where are the menus? How about a sortable table?
> It just sucks. And don't even talk to me about Javascript as being some
> kind of cure. :-) And now the insult of the frickin' "semantic web." Argh,
> I hate that guy.
The 'semantic web' is obviously something that should be relational, and
indeed it is a shame that few seem to realise it.
[snip]
Paul Vernon
> "Paul Vernon" <paul....@ukk.ibmm.comm> wrote in message
news:b8hm0t$2h7s$1...@gazette.almaden.ibm.com...
> > "Lauri Pietarinen" <lauri.pi...@atbusiness.com> wrote in message
> > news:e9d83568.03042...@posting.google.com...
> >
> > Beats me. I didn't even have a relational databases course on my CS
degree.
> > OK, so it was cancelled that year, but it no-one seemed particularly put
out
> > about it and I knew no better at the time (I think I had the impression
that
> > they were old hat, industry things only, and this newfangled OO thing
would
> > replace them..!!!!)
>
> Ha ha! At my university, I had the opportunity to take database classes
> from Michael Stonebreaker, but I figured it would be about the same
> thing as taking accounting.
You were probably right.
Taken by Michael Stonebreaker, I guess it would be all implementation details
and little theory?
The class I missed is taken by Hugh Darwen would you believe.
> > > I tend to agree with Marshall here that there is still room for
> > > an imperative component, both inside the implementations of the
> > > datatypes and their operators and outside and around the relations.
> >
> > From what I understand of type theory, you would defiantly want to go the
> > functional route for user defined type implementations.
>
> ("defiantly" of "definitely?" Not that I am opposed to doing things
defiantly.)
Ha. I guess I meant the latter, but either are OK ;-)
> Could you expand on that? It seems to me that the core of what I get out
> of TTM as far as UDTs goes is the clear definition of values and variables.
> I don't see anything particularly wrong with having variables. It seems to
> me the problems come when you allow variables to contain other variables.
> (That is, objects, pointers, etc.) As long as all a variable can do is hold
> a value, and variables can't be aliased, you are side-effect free. And
> THAT I think is the real issue: ridding ourselves of side effects, and not
> functional vs. imperative. (The functional guys just come out looking
> better today because they've managed to free themselves from side effects.
> But I'd say they did it the hard way.)
I'm no expert on FP, but I agree that side-effects are the real issue. (In
relational also. Why do folks not see referential actions (and view updates!)
for what they are - side effect changes to the database value)
Functional programs are at a higher level of abstraction. To quote
http://www.haskell.org/aboutHaskell.html
"The focus is on what is to be computed, not how it should be computed"
What, not How. Now where have I heard that before...
> > Show me a (useful) algorithm that cannot be performed in a relational
algebra
> > (hypothetically extended with 'features' from the FP world).
> > Why have two languages if we can get away with one?
>
> Well, we certainly *can't* get away with one. There are application
languages
> and there are systems languages. Take Java and C++ today, for example. Sure,
> they're deeply flawed, but they both have some cool things in them, and
they're
> the two most popular languages today. One is an application language; the
> other is a systems language. I'd certainly hate to use either for the
other's purpose,
> although it can be done.
Systems languages? That's almost like including 'hardware logic' in our
definition of what is needed to build applications. Systems/internals is
'under the covers', use what language you like, it's outside of my world view.
> This language I'm semi-seriously designing, is an imperative relational
language.
> It's great for writing applications. It'd suck to write a device driver in,
in a manner
> similar to how much it would suck to write a device driver in Java.
>
> And besides that, why not allow one language to be embedded in another?
> I'd claim that's what regular expressions are: a special purpose
sublanguage.
Maybe we need a 'hierarchy' of languages, each one made more powerful that the
previous by the addition of extra 'features'. The simpler ones are limited,
but can be proved to terminate and are easy to optimise, the higher ones are
more powerful but harder to reason about. The trick of coding then becomes to
use the simplest language sensible for the problem at hand.
> > BTW does anyone have a good defn of 'imperative'. In the footnotes of the
> > TTM, Date (and it would be him) says:
> >
> > "we have recently observed a distressing tendency to confuse
procedural
> > with imperative ... In particular, D - or its relational portion, at any
> > rate - is imperative but not procedural"
>
> I always figured they meant the same thing. FOLDOC calls them synonyms:
>
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?imperative
>
Hum, we appear to be at a lose on this one.
Marshall Spight
> > from Michael Stonebreaker, but I figured it would be about the same
> > thing as taking accounting.
>
> You were probably right.
> Taken by Michael Stonebreaker, I guess it would be all implementation details
> and little theory?
> The class I missed is taken by Hugh Darwen would you believe.
You win! :-)
> I'm no expert on FP, but I agree that side-effects are the real issue. (In
> relational also. Why do folks not see referential actions (and view updates!)
> for what they are - side effect changes to the database value)
Okay, that's an interesting perspective. But without updatable views, how
do you update your schema over time and keep your applications working?
(This is not a rhetorical question; I want to know your thoughts.)
> Functional programs are at a higher level of abstraction. To quote
> http://www.haskell.org/aboutHaskell.html
> "The focus is on what is to be computed, not how it should be computed"
>
> What, not How. Now where have I heard that before...
Heh heh.
> Systems languages? That's almost like including 'hardware logic' in our
> definition of what is needed to build applications. Systems/internals is
> 'under the covers', use what language you like, it's outside of my world view.
Fair enough.
Marshall
Marshall Spight
> >
> > transactions
>
> Dead wrong. Transactions are bad, real bad. In short they are not compatible
> with the 'arrow of time'. They let you freeze time and that is not a good
> model of reality. Start a new thread if you want to discuss the details, I've
> a draft paper on the subject and a could do with some intelligent challenges
> to sharpen up my argument.
Wow. That's a dramatic statement. I'd be interested to have that followup.
I'll start that thread. "Transactions: good or bad?"
> > declarative integrity constraints
>
> Yep, that is a big one, but again for me it is subsumed by application
> independence. To use the terminology, unless all your business rules are
> declared and enforced by the database, then each application will have to
> reimplement your rules and be vetted before being given database access. The
> goal of *strong application independence* is to allow any 'application'
> whatsoever to access and update your database, and still gureantee maintian a
> correct and working system even in a 'hostile' environment like the net.
Yes, this is huge.
>
> } Lately, I've spent some time working with Joe Armstrong's UBF
> } (http://www.sics.se/~joe/ubf/site/home.html).
We have something that sounds almost exactly like this at work.
Everyone is so proud of it. I humor them.
> > I am very fond of saying, to whoever will listen, that Tim Berners-Lee set
> > computing back by decades.
>
> I agree with you below, but man, without TimBL there would be no WWW. Even I
> find it difficult to see how the relational model could have done a better job
> at spreading the networked world than HTML and web browsers.
Imagine a binary, relational version of XML built on the relational model. Imagine
a decent user interface that included rich text with hyperlinks. Imagine a
protocol for exchanging same that didn't suck. There you are: just a small
matter of programming. :-)
Marshall
Paul Vernon
[snip]
> Imagine a binary, relational version of XML built on the relational model.
Ah, but then we would all have to agree on a standardised relational catalog
database model (which implies agreeing on a single defn of 'The Relational
Model' ;-) ...
Paul Vernon
> "Paul Vernon" <paul....@ukk.ibmm.comm> wrote in message
news:b8jpgb$2ote$1...@gazette.almaden.ibm.com...
> > "Marshall Spight" <msp...@dnai.com> wrote in message
> > news:Zp3ra.650860$F1.86675@sccrnsc04...
> > > Ha ha! At my university, I had the opportunity to take database classes
> > > from Michael Stonebreaker, but I figured it would be about the same
> > > thing as taking accounting.
> >
> > You were probably right.
> > Taken by Michael Stonebreaker, I guess it would be all implementation
details
> > and little theory?
> > The class I missed is taken by Hugh Darwen would you believe.
>
> You win! :-)
>
I should just correct myself. The class I missed has Hugh Darwen as a guest
lecturer I don't believe he has taught the whole course.
Marshall Spight
> "Marshall Spight" <msp...@dnai.com> wrote in message
> news:Lmora.661321$3D1.366931@sccrnsc01...
> [snip]
> > Imagine a binary, relational version of XML built on the relational model.
>
> Ah, but then we would all have to agree on a standardised relational catalog
> database model (which implies agreeing on a single defn of 'The Relational
> Model' ;-) ...
Well I think we darn well ought to do that! Without a standard metadata model,
there's a lot of things we can't do.
In general, you can't communicate without a schema. Therefor, unless you
have a metaschema, you can't communicate schema. And you *really*
need to be able to communicate schema.
Marshall
Alfredo Novoa
> "Marshall Spight" <msp...@dnai.com> wrote in message
> news:Lmora.661321$3D1.366931@sccrnsc01...
> [snip]
> > Imagine a binary, relational version of XML built on the relational model.
It would be VERY different from XML.
I can imagine data exchange using a binary Tutorial D version.
> Ah, but then we would all have to agree on a standardised relational catalog
> database model
A standardised catalog would be a good thing, but I don't see the need.
Can you elaborate?
Thanks.
Regards
Alfredo
Marshall Spight
> "Paul Vernon" <paul....@ukk.ibmm.comm> wrote in message news:<b8ljga$383i$2...@gazette.almaden.ibm.com>...
> > "Marshall Spight" <msp...@dnai.com> wrote in message
> > news:Lmora.661321$3D1.366931@sccrnsc01...
> > [snip]
> > > Imagine a binary, relational version of XML built on the relational model.
>
> It would be VERY different from XML.
>
> I can imagine data exchange using a binary Tutorial D version.
Hmmm. I don't recall that Tutorial D has much to say about data exchange
or formatting. But I perhaps you mean D-style (vs. SQL-style) tables?
That's what I was suggesting.
> > Ah, but then we would all have to agree on a standardised relational catalog
> > database model
>
> A standardised catalog would be a good thing, but I don't see the need.
>
> Can you elaborate?
If we are to have stardardized interchange, we have to be able to exchange
semantic data (schema) as well as the base data. For example, if I ship you
some tables, you might want to manipulate them and send them back.
If that happens, you'd probably like to be able to do some validation on
your side before sending them. You can't do that unless you know
the domains, the foreign keys, the constraints, etc.
Marshall
Neo
What is the difference between a mathematical concept and non-mathematical concept?
Neo
> theory to the data management camp.
IMO, Relational Data Model is but one particullar application of
predicate logic and set theory. It is possible to create countless
data models starting with the same set theory. All-in-all, the
Relational Data Model is one of the best at the present time, but it
too has its flaws and limitations. Just as Newton's Theories were
displaced by Quantum Theories, so will the Relational Data Model.
Lauri Pietarinen
>>The Relational Model IS the application of predicate logic and set
>>theory to the data management camp.
>>
>>
>
>IMO, Relational Data Model is but one particullar application of
>predicate logic and set theory. It is possible to create countless
>data models starting with the same set theory.
>
What other models did you have in mind?
> All-in-all, the
>Relational Data Model is one of the best at the present time, but it
>too has its flaws and limitations.
>
What are the flaws and limitations you had in mind?
> Just as Newton's Theories were
>displaced by Quantum Theories, so will the Relational Data Model.
>
It was not exactly displaced, was it? It was just refined...
regards,
Lauri Pietarinen
Marshall Spight
> > Just as Newton's Theories were
> >displaced by Quantum Theories, so will the Relational Data Model.
> >
> It was not exactly displaced, was it? It was just refined...
Not to mention the fact that Newton and Einstein were working
in physics, not math.
Addition as the Greeks knew it centuries ago is still valid.
Marshall
Patrick Schaaf
>> Just as Newton's Theories were
>>displaced by Quantum Theories, so will the Relational Data Model.
>>
>It was not exactly displaced, was it? It was just refined...
Correct. Basically, Newton's Theories are still in use for almost
all things that matter to us in daily life. They have been augmented
for very small distance scales, by Quantum Theory, and for very large
distance scales / relative speeds, by Special and General Relativity.
But in the areas mattering to living on this dirt ball, including most
practical engineering, Newton (and Thermodynamics) still rules.
So, keeping with the analogy, the question would be: where's the
boundary beyond which the RDM does break down, and must/should
be replaced by something else? And: if the RDM corresponds to
Mechanics, what corresponds to Thermodynamics?
best regards
Patrick (neither a physicist, nor a DB person. I do networks.)
Patrick Schaaf
>> > Do Data Models Need to built on a Mathematical Concept?
>What is the difference between a mathematical concept and non-mathematical concept?
One of them will be well-defined, understood, and can be communicated.
The other is what's always found in the real world, within people's heads.
It helps to be able to cope with both. Practically, the non-mathematical
is the more important. It's hardware and people running your software,
not an abstract mathematical machine.
best regards
Patrick
Neo
> > displaced by Quantum Theories, so will the Relational Data Model.
> >
> It was not exactly displaced, was it? It was just refined...
Yes and No. In some applications, Newton's methods provide results
that are "close-enough" and a lot easier to calculate. In other
applications, Newton's methods produces results that are "way-off" and
useless.
Similarly, in some applications (which at the present seems to be the
majority), the relational methods provides results that are
"close-enough" and infact better than most other methods.
But, there are applications (which at the present seem to be a
minority) where the relational methods results are not satisfactory
such as highly variable/complex data structures that could be thought
of as graphs. IMO, the model used by the human brain is some
refinement of the relational model.
Neo
> > What is the difference between a mathematical concept
> > and non-mathematical concept?
>
> One of them will be well-defined, understood, and can be communicated.
> The other is what's always found in the real world, within people's heads.
What constitutes well-defined? Is there a sharp-cut off where
somethings are well defined and others not? Who or what is defining
the cut off?
What constitutes understood? Is there a sharp-cut off where somethings
are understood and other not? Who or what defines when something is
understood.
What can or cannot be communicated? By whose standards.
My point is that I still do not know what is or is not a mathemathical
concept. Maybe something is a mathematical concept if it SEEMS to
produce the correct answers for the application at hand.
> Practically, the non-mathematical is the more important.
Likewise, I think it is irrelevent if something is or is not a
mathematical concept. What matter most is whether a model, which
utimately is of our own making, allow us to produce results that are
acceptable to our application. Why use Quantum, if Newton's answer is
close enough when considering a baseballs trajectory.
Costin Cozianu
I guess you are first of all very confused as to what the relational
model is, therefore you probably are extremely unqualified to assert
with no arguments: that "the relational methods results are not
satisfactory such as highly variable/complex data structures that could
be thought of as graphs" .
You need to learn is that a graph is equivalent to a binary relation,
and incidentally the relational model is very well suited for guess
what: relations.
As to "the model used by the human brain", if you knew that, you'd be a
Nobel prize winner, and you wouldn't waste your time trolling
comp.database.theory :)
Neo
> > at the present time, but it too has its flaws and limitations.
>
> What are the flaws and limitations you had in mind?
1. That all rows of a table have the same number of columns
which leads to the need for NULLs.
2. That all values in a column be of the same type.
Neo
> boundary beyond which the RDM does break down, and must/should
> be replaced by something else?
IMO, that boundary rears its head when we try to match the
capabilities of the human brain with the relational data model.
Neo
> and incidentally the relational model is very well suited for guess
> what: relations.
The reason the relational model is INefficient with highly variable
graphs is that the number of binary relationships can vary but the
relational model self imposes an arbitrary limitation of requiring the
same n in all tuples belonging to a relation (table).
Neo
A graph is not equivalent to a binary relation.
A graph is composed of binary relations.
> and incidentally the relational model
> is very well suited for guess what: relations.
Draw a hundred dots on a piece of paper and arbitrarily connect lines
between them until it looks like a hair ball. Give each dot a name.
Now fit that data in rectangular tables called "relations" and let me
know if it looks very well suited for this type of application.
Neo
> Nobel prize winner, and you wouldn't waste your time trolling
> comp.database.theory :)
I know you believe that the relational data model is the final/ultimate answer.
I know you look down on anyone questioning your wisdom or searching for better.
And I know you are wrong.
Lauri Pietarinen
How about:
create table edges
(start_x int, start_y int,
end_x int, end_y int,
primary key(
start_x int, start_y int,
end_x int, end_y int)
);
insert into edges values( 1,1, 10,10 );
-- meaning that there is a conncetion between points (1,1) and (10,10)
insert into (etc...)
Lauri
>
>
Lauri Pietarinen
Neo wrote:
I don't think anybody is claiming that the Relational Model (as we know
it now) is the final answer.
We will surely get wiser over time. However, what is important to
understand is that
the whole body of modern mathematics is based on the "relational model",
in a sense. And this
understanding developed during the past 2500 years! We are just
"stealing" this understanding
and applying it to data management (and application development).
As for using the human brain as a model: There is a theory called
Bayesian Networks that handles
fuzzy reasoning well (it is actually based on a statistical model).
Maybe the elements of BN can
be merged with RM in due time...?
Lauri
>
>
Patrick Schaaf
Your reply is second guessing the former poster, and formulated in an
aggressive-suggestive 3-form. Abstractly, you say three things:
A) something which a cursory reader may well approve of,
B) something they may lean to approve of after nodding to A)
C) a totally off-base remark "I know you are wrong", which is
to be planted in readers heads. Readers who nodded to A)
and B) are highly likely to nod to C), if only subconsciously.
I do not discuss with people who apply such tactics. So, don't expect
any reply to the two postings you made in reply to mine.
World peace will be reached shortly.
HAND
Patrick
--
I'm not a native speaker, but I play one on Usenet.
Costin Cozianu
In another message you added this other non-sense:
Neo wrote:
>>You need to learn is that a graph is equivalent to a binary relation,
>
>
> A graph is not equivalent to a binary relation.
> A graph is composed of binary relations.
>
You are very confused. Ok, I can see how coming from your other usual
trolling on comp.database.object you consider any two pair of objects
connected by a pointer or 2 pointers for that matter as a "relation".
That is how you can claim that a "graph is composed of binary relations
" and that is of course, non-sense.
Do you have any background about graph theory or any mathematics at all
in your background, or are you just wasting our time ?
Read my lips : any graph can be interpreted as a binary relation, and
any binary relation can be interpreted as a graph.
If you can't get past this elementary point, I will kindly suggest that
you should give up trolling on comp.database.theory. This is not a forum
to spoonfeed elementary mathematics to the ignorant.
Neo
> >between them until it looks like a hair ball. Give each dot a name.
> >Now fit that data in rectangular tables called "relations" and let me
> >know if it looks very well suited for this type of application.
>
> How about:
> create table edges
> (start_x int, start_y int,
> end_x int, end_y int,
> primary key(
> start_x int, start_y int,
> end_x int, end_y int)
> );
Yes, the data can be represented by generic modelling meaning
everything in one table. But consider that each dot may represent
different kinds/types of things (persons, airplanes, colors, jobs,
chairs, etc). IMO, the rdb data model is not well suited for this type
of problem.
Alfredo Novoa
> > I can imagine data exchange using a binary Tutorial D version.
>
> Hmmm. I don't recall that Tutorial D has much to say about data exchange
> or formatting.
No, but It would be better than XML for that.
> But I perhaps you mean D-style (vs. SQL-style) tables?
> That's what I was suggesting.
I mean relational style vs. XML hierarchical style.
> > A standardised catalog would be a good thing, but I don't see the need.
> >
> > Can you elaborate?
>
> If we are to have stardardized interchange, we have to be able to exchange
> semantic data (schema) as well as the base data.
But we don't need a standard catalog, only a standard DDL.
> For example, if I ship you
> some tables, you might want to manipulate them and send them back.
> If that happens, you'd probably like to be able to do some validation on
> your side before sending them. You can't do that unless you know
> the domains, the foreign keys, the constraints, etc.
And we can declare all of that with the DDL.
Regards
Alfredo
Neo
> (as we know it now) is the final answer.
IMO, Mr. Cozianu seems to imply that the final model for representing
data is the current relational data model. Although the relational
data model is sufficient for the majority of applications (currently),
it is not sufficient for all applications. I am certain he is wrong on
this account.
> However, what is important to understand is that the whole body
> of modern mathematics is based on the "relational model", in a sense.
If by "relational model" you simply mean that things can have
relationships, then I would agree.
If by "relational model" you mean Codd's "relational data model" where
each tuple in a relation has to be of the same degree and each value
of a domain has the same type, then I would disagree with the use of
the quantifier "whole body". The arbitrary restrictions in Codd's
"relational data model" prevent it from being the basis for the WHOLE
body of useful mathematics that man can invent. The arbitrary
restrictions make the implmentation easier but also limited its
flexibility.
> As for using the human brain as a model:
> There is a theory called Bayesian Networks that handles
> fuzzy reasoning well (it is actually based on a statistical model).
By the human brain model, I meant only that area related to
representing things. I know for certain that it is not restricted by
data type and the need to have same number of attributes for each
thing.
> Maybe the elements of BN can
> be merged with RM in due time...?
For certain there is great overlap.
For certain they cannot be fully merged without breaking each model
rules (which were invented by us).
Neo
> aggressive-suggestive 3-form.
Why would you be offended at my second guessing and aggression at Mr
Cozianu, if you were not offended by Mr Cozianu's second guessing and
aggresion to me in the first place. I don't attack those who don't
attack me.
Everything is a second guess. Of what are you 100% sure?
> I do not discuss with people who apply such tactics.
What I find most irritating about Mr Cozianu is his pattern of I know
it all, you dont know anything, and you are dumb. What tactic would
you recommend to deal with such a person?
Lauri Pietarinen
>Yes, the data can be represented by generic modelling meaning
>everything in one table. But consider that each dot may represent
>different kinds/types of things (persons, airplanes, colors, jobs,
>chairs, etc). IMO, the rdb data model is not well suited for this type
>of problem.
>
I get your point. Basically you have to make the choice where you want
your application logic and rules
to reside: Do you want them in the schema or do you want it in your
programs. In practice
they are devided between the two.
Putting more intelligence into the schema, i.e. creating the the tables
'persons', 'airplanes', 'colors' etc
and defining the relationships between them with associative tables or
otherwise means that
you will have an easy time making (SQL-) queries against this data
(because there are rules in
the schema), and, if we had updatable views, also updating would be a flash.
In the other end of the spectrum you can have
a completely generic schema, e.g. something like
(very crude example, I hope you get the picture),
create table entities(entity_id)
create table relationships(entity1_id, entity2_id);
create table attributes (entity_id, value)
you can save basically anything you want, but you will lose the ease of
quering.
Your appication (or user) will have to have more rules in it so that it
can make
sense of the data in the schema.
So basically there is no free lunch. If you want to have an automatic
system
you have to have rules *somewhere*. Putting the rules into the database
makes
the rules more transparent and easier to see. It also enables certain kinds
of optimisations that are not possible if the rules are written into
programs.
regards,
Lauri Pietarinen
Neo
> You are very confused.
> I can see how coming from your other usual trolling on comp.database.object
> Do you have any background about graph theory or any mathematics at all
> in your background, or are you just wasting our time ?
> Read my lips :
> you should give up trolling on comp.database.theory. This is not a forum
> to spoonfeed elementary mathematics to the ignorant.
Mr. Schaaf, how you deal with such "second guessing" and "agression"?
Lauri Pietarinen
Neo wrote:
>>I don't think anybody is claiming that the Relational Model
>>(as we know it now) is the final answer.
>>
>>
>
>IMO, Mr. Cozianu seems to imply that the final model for representing
>data is the current relational data model. Although the relational
>data model is sufficient for the majority of applications (currently),
>it is not sufficient for all applications. I am certain he is wrong on
>this account.
>
I meant that I don't think that Mr. Cozianu claims that he can see 200
years into the future
and predict what kinds of database systems (if any!) we will the have at
our disposal. It just
looks currently now like the relational model has the most promise.
Compare it to Newton
and his theory circa 1670: If you had lived then and told Newton that,
well, you know, some
day your theories will be superseded, you would have been correct, sort
of, but your
observation would not have been very usefull at that time.
>>However, what is important to understand is that the whole body
>>of modern mathematics is based on the "relational model", in a sense.
>>
>>
>
>If by "relational model" you simply mean that things can have
>relationships, then I would agree.
>
No, no. *Relations*, or actually set theory.
>If by "relational model" you mean Codd's "relational data model" where
>each tuple in a relation has to be of the same degree and each value
>of a domain has the same type, then I would disagree with the use of
>the quantifier "whole body". The arbitrary restrictions in Codd's
>"relational data model" prevent it from being the basis for the WHOLE
>body of useful mathematics that man can invent. The arbitrary
>restrictions make the implmentation easier but also limited its
>flexibility.
>
This inflexibility is the basis for practically all modern mathematics,
believe it or not.
>>As for using the human brain as a model:
>>There is a theory called Bayesian Networks that handles
>>fuzzy reasoning well (it is actually based on a statistical model).
>>
>>
>
>By the human brain model, I meant only that area related to
>representing things. I know for certain that it is not restricted by
>data type and the need to have same number of attributes for each
>thing.
>
We don't really know very much about how knowledge is represented in the
human brain.
However, getting the data out of it does require quite a lot of
*software* ;-)
regards,
Lauri Pietarinen
Marshall Spight
> "Marshall Spight" <msp...@dnai.com> wrote in message news:<1eSra.148357$Si4.1...@rwcrnsc51.ops.asp.att.net>...
>
> > That's what I was suggesting.
>
> I mean relational style vs. XML hierarchical style.
I think we agree that this would be a good thing.
> > If we are to have stardardized interchange, we have to be able to exchange
> > semantic data (schema) as well as the base data.
>
> But we don't need a standard catalog, only a standard DDL.
Hmmm. I guess that's true. But is having a standard DDL any better
than having a standard catalog? If we have a standard catalog, we can
work with schema updates in exactly the same way we work with
any other data update. OTOH, maybe the only way we can work
with generalized data updates is in some language.
I observe that it's easy to model inserted rows as relational data.
(Trivial, in fact.) But it's harder to model delete and harder still
to model update. Maybe this is an argument for using a language
to do it. For example, some dbms implement replication via
shipping each line of SQL to each replica.
> > For example, if I ship you
> > some tables, you might want to manipulate them and send them back.
> > If that happens, you'd probably like to be able to do some validation on
> > your side before sending them. You can't do that unless you know
> > the domains, the foreign keys, the constraints, etc.
>
> And we can declare all of that with the DDL.
Okay, true enough.
But to do it this way seems an admission of failure to me. After
all, this is data that is *easily* represented as relations, and here
we go, falling back on a textual representation.
I'm conflicted.
Marshall
Marshall Spight
> But consider that each dot may represent
> different kinds/types of things (persons, airplanes, colors, jobs,
> chairs, etc). IMO, the rdb data model is not well suited for this type
> of problem.
Okay, so you're proposing that there's a need to store completely
unrelated things in a graph.
Can you give me an example of what this would be used for?
I am familiar with examples in which different types of things
are connected by different types of relationships. And I'm
familiar with examples in which a single thing has some
relation with others things of the same type. The relation
model handles both of these.
I'm not familiar with an example application that would need
to store *untyped* relations between typed things. In your
example, what does it mean to have edges like this:
person -> airplane -> color -> job -> chair
What is the predicate?
Marshall
Marshall Spight
> it all, you dont know anything, and you are dumb. What tactic would
> you recommend to deal with such a person?
Prove him wrong using sound reasoning and thorough knowledge
of the field in question.
Marshall
Marshall Spight
> > > All-in-all, the Relational Data Model is one of the best
> > > at the present time, but it too has its flaws and limitations.
> >
> > What are the flaws and limitations you had in mind?
>
> 1. That all rows of a table have the same number of columns
> which leads to the need for NULLs.
There is nothing about relations that require nulls.
> 2. That all values in a column be of the same type.
This is not generally regarded as a limitation. It is like
saying that addition is limited because it cannot operate
on dates.
Can you give us an example of some operation you'd like
to perform that can't be handled with relations and relational
operators?
Marshall
Neo
relation,
>> A graph is not equivalent to a binary relation.
>> A graph is composed of binary relations.
It depends on your definition of a graph vs my definition of a binary
relation. I define a binary relation as any two things that have
something in common.
According to http://people.hofstra.edu/geotrans/eng/ch2en/meth2en/ch2m1en.html
A graph is a symbolic representation of a network.
If you say that a graph can consist of as few as 2 nodes and one must
be able to go from one to the other AND vise versa, then they are the
same and you are correct.
What is your definition of a graph?
> you consider any two pair of objects connected by a pointer
> or 2 pointers for that matter as a "relation".
I consider any two things/objects/entities/records "connected" by
pointers/ids/etc to be an implementation of a binary relation.
Do you agree or disagree?
Bob Badour
news:3EB40824...@atbusiness.com...
Why create 'persons', 'airplanes', 'colors' etc. as tables? 'Neo' asked you
to create them as types or domains with a common supertype. The best answer
is simply: One can do that with any relational dbms that supports type
inheritence.
Lauri Pietarinen
>Why create 'persons', 'airplanes', 'colors' etc. as tables? 'Neo' asked you
>to create them as types or domains with a common supertype. The best answer
>is simply: One can do that with any relational dbms that supports type
>inheritence.
>
OK, yes, you could simulate the effects of an OO-system by just putting
the data and intelligence in
the types and saving them in relations. But the same applies: you lose
transparency, optimisability, etc...
... all the advantages of the RM!
regards,
Lauri
Lauri Pietarinen
>>>>You need to learn is that a graph is equivalent to a binary
>>>>
>>>>
>relation,
>
>
>>>A graph is not equivalent to a binary relation.
>>>A graph is composed of binary relations.
>>>
>>>
>>...non-sense..
>>
>>
>
>It depends on your definition of a graph vs my definition of a binary
>relation. I define a binary relation as any two things that have
>something in common.
>
A (binary) relation is a subset of a Cartesian product.
What is a Cartesian product?
A familiar example is the Cartesian plane (the normal XY-plane) defined
as the Cartesian product RxR (R=the set of real numbers).
It contains all possible points (x,y) where x and y belong to R
Now, a nice example of a relation is the unit circle,
the set of points defined by
{(x,y) | x**2 + Y**2 = 1}. Clearly this set of points is
just a subset of all points on the plane.
The interesting thing is that a Cartesian product contains as much
information as a blank piece of paper, i.e. nothing. Only when we restrict
ourselves to a subset of the points on the plane (e.g. by drawing
the unit circle) do we have information.
It was the great insight of Ted Codd in 1970 that this way of thinking
(that is ingrained in modern mathematics) can be applied to database
technology.
regards,
Lauri Pietarinen
Neo
> > A graph is composed of binary relations.
>
> and any binary relation can be interpreted as a graph.
Non-sense.
You are confused.
Now read my lips:
In general, a graph is composed of binary relations.
When a graph consists of only two nodes
it may then be equivalent to a binary relation.
A drawing with 10 interconnected nodes represents a graph
and it is composed of binary relations.
The 10 interconnected nodes as a whole is not A binary relation,
it is composed OF multiple binary relations.
PS.
Do you have any background or are you just wasting my time?
If you can't get past this elementary point,
I suggest that stop trolling.
This is not a forum to spoonfeed elementary mathematics to you.
Costin Cozianu
Yes, I do have a background including reading a few books on Graph
Theory, Set Theory and Abstract Algebra, more advanced books on Database
theory, and apparently a gorup of people made the mistake to grant me a
University diploma in Mathematics and Computer Science, which I know you
don't have because no Math or CS graduate could debitate such non-sense.
You should visit your local public library more and you should follow at
least some summer courses on basic CS topics.
A relation of degree n over the sets A1, A2, ..., An is simply any
subset of the cartesian product A1xA2...xAn.
For a binary relation the notation is usually R <included in> AxB
where we call A the domain of R and B the codomain of R. So we say R is
a binary relation from A to B. When A and B (the domain and codomain
coincide) we call that a *binary relation over A*. So a binary relation
R over A is simply a subset of the cartesian product AxA.
Further more, given a binary relation R over A, A is implied in the
definition of R (otherwise R is not defined), so all is left for you to
do is put them together in the pair (A, R) and you got your directed graph.
For what a graph is I hope you do go and educate yourself, or maybe find
another charitable soul on usenet, to explain to you what a graph is.
Neo
> >
> > 1. That all rows of a table have the same number of columns
> > which leads to the need for NULLs.
>
> There is nothing about relations that require nulls.
Yet they routinely occurs in practice.
Is the model not conforming to reality?
Or is reality not conforming to the model?
IMO, each thing in reality can have different number of attributes
which does not match the model.
Neo
> >
>
> This is not generally regarded as a limitation. It is like
> saying that addition is limited because it cannot operate
> on dates.
Just as in pure set theory, I want the flexibility that the elements
can be anything. But, in the rdb model, that flexibility cannot be
fully realized because the type of values in a domain is restricted to
some hardware dependent type (ie int, long, date, 50 chars, etc). If I
think of a set of arbitrary thing in my mind, I don't think about
their type to decide if they can on cannot be included in that set. If
the things in a set are of different types, I probably would not be
performing operations such as add or average on them.
Marshall Spight
> > > > What are the flaws and limitations you had in mind?
> > >
> > > 1. That all rows of a table have the same number of columns
> > > which leads to the need for NULLs.
> >
> > There is nothing about relations that require nulls.
>
> Yet they routinely occurs in practice.
They occur in SQL. They do not occur in the relational model.
> Is the model not conforming to reality?
> Or is reality not conforming to the model?
Neither is the case. SQL is not conforming to the model.
Implementations often have warts. In Java, an array
of type T' is a subtype of an array of type T (where T'
is a subtype of T) even though it isn't "in reality."
So you can get ArrayStoreException at runtime.
It's a bug in the spec, just like nulls occur in the SQL
spec.
> IMO, each thing in reality can have different number of attributes
> which does not match the model.
You are confusing domains and relations. This is a common error
that is easy to make. It took me a lot of reading and thinking
before I figured out why that doesn't work.
If you want to think about "things in reality" (not the best
idea) then you should think of them as being individual
values in the database. That is, what's in one specific attribute
of one specific row of a relation is a "thing in reality." *Not*
a row.
Marshall
Marshall Spight
> > > > What are the flaws and limitations you had in mind?
> > >
> > > 2. That all values in a column be of the same type.
> >
> > This is not generally regarded as a limitation. It is like
> > saying that addition is limited because it cannot operate
> > on dates.
>
> Just as in pure set theory, I want the flexibility that the elements
> can be anything.
Sure; the model totally allows this.
> But, in the rdb model, that flexibility cannot be
> fully realized because the type of values in a domain is restricted to
> some hardware dependent type (ie int, long, date, 50 chars, etc).
That might be a limitation on, say, Oracle, but it's not a limitation
of the relational model. Domains can be anything; the relational
model doesn't say anything about them at all, other than to say
they are sets of values.
> If I
> think of a set of arbitrary thing in my mind, I don't think about
> their type to decide if they can on cannot be included in that set. If
> the things in a set are of different types, I probably would not be
> performing operations such as add or average on them.
Ah, but the things in a set are *not* different in at least one aspect:
they are all members of the set!
To the extent that you can say things (loosely speaking) about
those members of that set, you can say it within the relational
model.
Marshall
Kunle Odutola
>>> A graph is not equivalent to a binary relation.
>>> A graph is composed of binary relations.
>>
>> Read my lips : any graph can be interpreted as a binary relation,
>> and any binary relation can be interpreted as a graph.
>
> Non-sense.
> You are confused.
> Now read my lips:
>
> In general, a graph is composed of binary relations.
> When a graph consists of only two nodes
> it may then be equivalent to a binary relation.
A binary relation is a set of ordered pairs drawn from a common domain.
A graph G can be viewed as a set of ordered pairs (Vertice, Edge) where Edge
is itself a set of ordered pairs (Vertice, Vertice).
In short, a binary relation can be viewed as a graph (and vice versa).
Similarly for a Matrix.
Cheers,
Kunle
Neo
> > When a graph consists of only two nodes
> > it may then be equivalent to a binary relation.
>
> A binary relation is a set of ordered pairs drawn from a common domain.
My personal definition of a binary relation is
'Two things that have something in common'.
It seems your definition of a binary relation above is quite similar.
I believe mine is simpler and more accurate because it is the more
general form and based on fewer things. In your definition, one would
need to define additional things such as set, order, pair, drawn and
domain.
> A graph G can be viewed as a set of ordered pairs (Vertice, Edge)
> where Edge is itself a set of ordered pairs (Vertice, Vertice).
I will concede, it is true that a human can view a graph as a set of
ordered pair (nodes, links) in his mind, but to do so, he is utilizing
information that is out of the universe of discourse. The universe of
discourse is simply the graph itself and does not include information
being utilized by the human to create the ordered pair (Nodes, Links).
For example, lets say we have 3 nodes linked in a triangle.
Thus you are saying
Graph = (Nodes, Links)
Nodes = (1, 2, 3)
Links = ((1,2), (2,3), (3,1))
Now you point out "Graph = (Nodes, Links)" and say there is the binary
relation.
Yes, that is, but, a human is creating that with additional
information in his brain and that information is not in the graph
itself.
A human views the three nodes and says, hey they all look like balls,
so I can think of them as being similar, but no data is encoded in the
graph itself that shows a commonality between them.
A human views the three links and says, hey they look like lines, so I
can think of them as being similar, but here again, no data is encoded
in the graph itself that shows a commonality between links.
Note, a drawing of the graph does encode info, but that info is not in
the graph itself. Ask yourself, is the graph itself providing the
commonality between things or is it yourself?
As I said before and say again, the graph itself is not A binary
Neo
TSK, TSK, Invalid deduction from argument.
Back to chapter one of Symbolic Logic (ISBN 0-13-060767-3).
> You should visit your local public library more and you should follow at
> least some summer courses on basic CS topics.
TSK, TSK, second-guessing and mild form of agression,
Mr. Schaaf is frowning upon you.
> For what a graph is I hope you do go and educate yourself, or maybe find
> another charitable soul on usenet, to explain to you what a graph is.
TSK, TSK, Invalid presumption and suggestion.
Costin Cozianu
Oh, that's even more funny. You're not only ignorant, you're ignorant in
denial and quite proud of it. You're self delusion is so great that
you even felt called to give a new definition of relation.
Indeed you were right on one thing. I wrongly presumed that public
libraries or summer courses or charitable souls on the internet can
benefit to you.
I appologize unconditionally for having this prolonged discussion with you.
Kunle Odutola
>>> In general, a graph is composed of binary relations.
>>> When a graph consists of only two nodes
>>> it may then be equivalent to a binary relation.
>>
>> A binary relation is a set of ordered pairs drawn from a common
>> domain.
>
> My personal definition of a binary relation is
> 'Two things that have something in common'.
Offering your personal (re-)definition of basic concepts in mathematics (I
snipped your redefinition of the concept of graphs for brevity) is a
counter-productive response. If we all began to re-define common concepts, I
might label you "intelligent" and my personal definition of that term might
be http://c2.com/cgi/wiki?TrollDefinition.
If you're interested in finding out what a "binary relation" really is,
Google is your friend:
http://www.google.com/search?&q=%22binary+relation%22
Cheers,
Kunle
Neo
> is simply any subset of the cartesian product A1xA2...xAn.
Ok, I can accept a well defined operation called cartesian product.
> For a binary relation the notation is usually R <included in> AxB
> where we call A the domain of R and B the codomain of R. So we say R is
> a binary relation from A to B. When A and B (the domain and codomain
> coincide) we call that a *binary relation over A*. So a binary relation
> R over A is simply a subset of the cartesian product AxA.
Your explanation and the three sited below from text books DO NOT
accurately describe the fundamental form of a binary relation.
1. A binary relation on A is a subset of (AxA).
2. A set R is a binary relation if all elements of R are ordered
pairs.
3. Let A and B be sets. A binary relation from A to B is a subset of
AxB.
These definitions involve multiple binary relations, but do not
clearly define a binary relation. The fundamental form of a binary
relation is two things that have something in common.
Anne & Lynn Wheeler
> Just as in pure set theory, I want the flexibility that the elements
> can be anything. But, in the rdb model, that flexibility cannot be
> fully realized because the type of values in a domain is restricted
> to some hardware dependent type (ie int, long, date, 50 chars,
> etc). If I think of a set of arbitrary thing in my mind, I don't
> think about their type to decide if they can on cannot be included
> in that set. If the things in a set are of different types, I
> probably would not be performing operations such as add or average
> on them.
as an aside fips193, sql standard
http://www.itl.nist.gov/fipspubs/193-1.htm
... & from above:
SQL is particularly appropriate for the definition and management of
data that is structured into repeated occurrences having common data
structure definitions. SQL provides a high-level query and update
language for set-at-a-time retrieval and update operations, as well as
required database management functions for schema and view definition,
integrity constraints, schema manipulation, and access control. SQL
provides a data manipulation language that is mathematically sound and
based on a first-order predicate calculus. SQL is self-describing in
the sense that all schema information is queryable through a set of
catalog tables called the Information Schema.
... sql from slightly different view:
http://www.it.bond.edu.au/inft320/003/lectures/Relational%20Data/node6.html
http://www.cis.ohio-state.edu/~gurari/course/cis670/cis670Ch9.html
... & just for kicks, a non-rdb, graph/network model
http://www.jfsowa.com/pubs/semnet.htm
for arbritrary occuring information, including possibly anomolous and
non-regular real-world structures.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Neo
Yes, you are in synch with text books.
Schaum's Outline explains binary relation as follows:
A = (b,c)
B = (j,k,l)
AxB = ((b,j), (b,k), (b,l), (c,j), (c,k), (c,l))
then (b,j), (b,k) ... are binary relations.
This is INCORRECT because it misses the fundamental form of a binary
relation.
(b,j) is NOT a single binary relation.
(b,j) is composed of TWO binary relations.
First, b is related to A, b has a relation to A.
Second, j is related to B, j has a relation to B.
They will have to rewrite the books and take back some diplomas or
more likely they will keep the current inaccurate definitions which
makes my experience on google all the more interesting :)
Neo
I believe I can explain the problem in a general manner which relates
to the capabilities exhibited by the human brain.
Suppose I have n types of things initially.
Thus I will store them in tables T1, T2, ... Tn.
Assume n increases with time.
Suppose I want to be able to relate any two things
and there are x types of relationships initially.
Thus I will store them in tables R1, R2, ... Rx,
each having at minimum two columns Thing1ID and Thing2ID.
Assume x increase with time.
To relate any two things in a relationship,
I will use a GUID for each row in T1 thru Tn.
Problem 1: How do I find any one thing efficiently, taking into
account that the number of tables will change over time.
Problem 2: How to I find all the other things a thing is related to
efficiently, taking into account the number of relationship tables
will change over time.
Problem 3: When inside a relationship table, how can I determine which
table a GUID relates to?
Neo
> > > >
> > > > 1. That all rows of a table have the same number of columns
> > > > which leads to the need for NULLs.
> > >
> > > There is nothing about relations that require nulls.
> >
> > Yet they routinely occurs in practice.
>
> They occur in SQL. They do not occur in the relational model.
In the rdb model, each tuple(row) of a relation(table) must be of the
same degree(number of columns). Thus if we have a column for Social
Security Number, and the person is an illegal immigrant, we will enter
NULL (or some arbitrary code). It is the rdb model which requires each
tuple to have the same degree which does not match reality. In
reality, things need not have the same number of attributes.
Neo
I will explain my understanding so you may correct me.
I see a relation as a set(person).
Each tuple as an element(john, mary,..) of the set.
A tuple's attributes(gender,height) are properties of the
element(john).
The tuple itself represents john and no one attribute of the tuple is
john.
A domain is the set of acceptable values for an attribute of a tuple.
> If you want to think about "things in reality" (not the best
> idea) then you should think of them as being individual
> values in the database. That is, what's in one specific attribute
> of one specific row of a relation is a "thing in reality." *Not*
> a row.
IMO, each tuple(row) can represents a thing in reality.
A row itself in a table named Person represents a person, regardless
of how many attributes it has.
Neo
> > fully realized because the type of values in a domain is restricted to
> > some hardware dependent type (ie int, long, date, 50 chars, etc).
>
> That might be a limitation on, say, Oracle, but it's not a limitation
> of the relational model. Domains can be anything; the relational
> model doesn't say anything about them at all, other than to say
> they are sets of values.
You are correct, in the rdb model itself, a tuple's values are not
associated with any data type. Data types only appear in
implementation of the rdb model.
Neo
> > can be anything.
>
> Sure; the model totally allows this.
I guess, I should say, I want an implementation that allows it, but
you are right, it is not the fault of the model.
Marshall Spight
>
> Yes, you are in synch with text books.
> Schaum's Outline explains binary relation as follows:
> A = (b,c)
> B = (j,k,l)
> AxB = ((b,j), (b,k), (b,l), (c,j), (c,k), (c,l))
> then (b,j), (b,k) ... are binary relations.
That's not the generally accepted definition of the term. Nor is it even
what that specific book says; I checked. What is says is:
"Let A and B be sets. A *binary relation* or, simple, a *relation* from
A to B is a subset of A x B."
So, to fix your example, the cardinality-2 set { (b,j), (b,k) } is
a binary relation.
To expand on the comparison a little:
An example of a binary relation on Z x Z (the integers) is 'less than'.
So the set of all integers a, b where a < b is a binary relation. If your
explanation of the standard definition were correct, (which I do
understand you specifically disagree with) then we would say
'1<2' and '7<123' are binary relations.
> They will have to rewrite the books and take back some diplomas or
> more likely they will keep the current inaccurate definitions which
> makes my experience on google all the more interesting :)
It might be better, if you want to create a new math, to create your
own terms as well, rather than redefine existing terms. That just
confuses people, and causes lots of arguments about definitions.
Marshall
Marshall Spight
>
> I believe I can explain the problem in a general manner which relates
> to the capabilities exhibited by the human brain.
Okay, I read your post, and I believe I understood you, although
I don't particularly know what it means to "relate to the capabilities
exhibited by the human brain."
The thing is, you gave me a good explanation, but you didn't give
me an example. I'll pull one specific phrase out of your explanation
that I had trouble with:
> Suppose I want to be able to relate any two things
Well, I just don't see this happening. When do you *ever*
need to be able to do that? To take an earlier example you
gave:
"persons, airplanes, colors, jobs, chairs, etc."
There are many pairs here that don't make any sense. For example,
what color is this job? How many persons does this chair have?
If you simple say "there is some association between these two things"
then you haven't said anything at all yet. You have to say what the
semantics of the pairing are. You have to say what it *means* for
the two things to be paired. You need a specific predicate. If I
just say (person, job) that might seems like it intrinsically means
something, *but it doesn't.* It could mean what job the person
holds. It could mean what job the person doesn't want. It could
mean what person the job is named after (like a named chair
at a university.) (There's that chair again!)
Marshall
Marshall Spight
>
> In the rdb model, each tuple(row) of a relation(table) must be of the
> same degree(number of columns). Thus if we have a column for Social
> Security Number, and the person is an illegal immigrant, we will enter
> NULL (or some arbitrary code). It is the rdb model which requires each
> tuple to have the same degree which does not match reality. In
> reality, things need not have the same number of attributes.
Again, you are describing SQL, and not the relational model.
In the relational model, if you have an optional attribute, there
are different things you can do besides using null. In fact,
these things are also supported in SQL; you don't even
have to fall back on a pure theoretic argument.
You can use a special value. For example, you could enter 0
as the SSN, because 0 is not a legal SSN. This may sound like
a trivial distinction, but it isn't. Alternatively, you can have a second
table for SSN, and have that table have a column that is both
a primary key and a foreign key to the workers table. Thus for
each row in the workers table you may have no SSN or you
may have one; no other case is possible, and the DBMS can
guarantee this for you.
Marshall
Marshall Spight
> tuple to have the same degree which does not match reality. In
> reality, things need not have the same number of attributes.
Well, I'm not clear on how we decide whether a mathematical
model represents reality or not. Looking out my window I see
a lovely view, but I don't see any "attributes."
When people try to give me examples in programming (especially
OOP) and the classes are called things Cow or Plant or whatever,
(and maybe they even point to their desk plant) I stop them right
there. "That plant is not a class or instance; it's a plant," I say. "Let's
talk about LinkedList or RGBColor or some such."
I don't think programming really has anything interesting to say
about reality. Programming is about math, and most of what's
interesting in math has nothing to do with reality. True, if I
have three oranges and you give me four more, I can use math
to predict that I will then have seven oranges. Or I can figure
out how big a door ought to be with geometry. But if that's
our criteria for deciding what should go into math, well,
we'd better get rid of negative numbers then. I certainly
never had three oranges and had someone take away five
of them. I never encountered anything that had an irrational
number in it. I don't see the Axiom of Choice having any
big impact on my wife's schedule tomorrow.
Marshall
Marshall Spight
>
> I will explain my understanding so you may correct me.
>
> I see a relation as a set(person).
> Each tuple as an element(john, mary,..) of the set.
> A tuple's attributes(gender,height) are properties of the
> element(john).
> The tuple itself represents john and no one attribute of the tuple is
> john.
>
> A domain is the set of acceptable values for an attribute of a tuple.
Well, uh, actually, that's right on.
> > If you want to think about "things in reality" (not the best
> > idea) then you should think of them as being individual
> > values in the database. That is, what's in one specific attribute
> > of one specific row of a relation is a "thing in reality." *Not*
> > a row.
>
> IMO, each tuple(row) can represents a thing in reality.
> A row itself in a table named Person represents a person, regardless
> of how many attributes it has.
Sure. In fact, we can refine that further. A table named Person (Persons
is better) represents a *predicate* along with a (possibly empty) set
of *propositions* that conform to that predicate. Thus:
Table Persons (Name string, heigh int, sex enum('Male', 'Female'))
The predicate is:
There exists a human called *Name* whose heigh in inches is *Height* and
whose sex is *sex.* (Strictly speaking, it's incorrect to say "gender" and I'm
a pedant, so there you are.)
The value of the table could be as follows:
"John Smith", 72, Male
"Mary Jones", 64, Female
Now here's the thing: what kinds of questions can we ask of this table?
We can ask it, how many people are less than ten feet tall? How many
men are there? Are there more men than women? How many people
have a name that starts with "j"?
But we *can't* ask it things like, what kind of gas mileage does a
Saturn get? How many chairs go on that airplane? What is the sound of
one hand clapping?
The questions we can ask are strictly bounded by the predicate.
It is the predicate that enables us to ask questions, not the data itself.
If I just had the data and no predicate, what could I ask? How many times
does the number 72 appear in the second column? How many different
values are there in the first column? Etc. These questions have no value.
You've expressed the desire to be able to work with sets of just anything.
Well, that's okay. You can have a user defined type (UDT) that can hold your
just-anything data and put it in a table. If you want to associate other
data with your just-anythings, you can do that too, with the usual
relational techniques. But what kind of questions can you ask about
just-anything? Only those questions that can be expressed on values
of your user defined type.
The key limitation is that without a predicate, you can't ask useful
questions. This limitation comes from semantics, not from the
relational model.
If I understand what you're trying to do, then to succeed, you'll need
a way to dynamically make new predicates. Just storing arbitrary dynamic
structured data is no big deal; it's not even very hard. But if you can
figure out a way to dynamically create meaning, that would be huge.
Marshall
PS. My best guess is that it's impossible, but I've been wrong before.
Marshall Spight
Fair enough.
There are DBMSs out there that allow you to create your own types.
I believe PostgreSQL has this capability. I haven't used it myself,
but I thought I'd mention it in case you're interested.
Oh, and there's also FirstSQL, which lets you put Java objects in
the db without getting into the whole "object/relational" like of
hooey. Very cool.
Marshall
PS. Some folks consider this feature an essential required feature, which
makes it ironic that so few databases actually support it.
Neo
> > 'Two things that have something in common'.
>
> counter-productive response.
It is mathematics that has inaccurately redefined the meaning of the
word relation, not I. The word was find used to mean "person related
by blood or marriage". Now does this sound like "two things that have
something in common" or does this sound like "a set of ordered pairs"
or "the subset of AxB".
It does not matter much who defined it or when they defined it.
What matters most is that the definition is accurate for the concept.
Lauri Pietarinen
Sadly, you'll just have to live with it. It's like QUERTY and the order
of the pedals in your car.
Anyway, I think the word you are after is RELATIONSHIP, not RELATION.
In some sense, Codd would have done better naming the model "The Logical
Model of Data".
It would have been more impressive.
Lauri
Alfredo Novoa
> > > Do Data Models Need to built on a Mathematical Concept?
>
> What is the difference between a mathematical concept and non-mathematical concept?
"Mathematical, a. [See Mathematic.] Of or pertaining to mathematics;
according to mathematics; hence, theoretically precise; accurate; as,
mathematical geography; mathematical instruments; mathematical
exactness. --"
Source: Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA,
Inc.
Regards
Alfredo Novoa
> > But we don't need a standard catalog, only a standard DDL.
>
> Hmmm. I guess that's true. But is having a standard DDL any better
> than having a standard catalog?
At least is more frequent.
> I observe that it's easy to model inserted rows as relational data.
> (Trivial, in fact.) But it's harder to model delete and harder still
> to model update. Maybe this is an argument for using a language
> to do it.
IMO it is a very strong argument.
> But to do it this way seems an admission of failure to me. After
> all, this is data that is *easily* represented as relations, and here
> we go, falling back on a textual representation.
We can use a binary relational language, or we can transmit the
compiled canonical form relational expressions (in a p-code like
format, for instance).
Regards
Alfredo
Marshall Spight
> neo5...@hotmail.com (Neo) wrote in message news:<4b45d3ad.03050...@posting.google.com>...
> > > > Do Data Models Need to built on a Mathematical Concept?
> >
> > What is the difference between a mathematical concept and non-mathematical concept?
>
> "Mathematical, a. [See Mathematic.] Of or pertaining to mathematics;
> according to mathematics; hence, theoretically precise; accurate; as,
> mathematical geography; mathematical instruments; mathematical
> exactness. --"
If I may, I'd like to pull just a single word from this definition and
highlight it, because I believe that this single word can capture
the essence of the answer to the original question.
That word is "accurate."
Marshall
Neo
> > A = (b,c)
> > B = (j,k,l)
> > AxB = ((b,j), (b,k), (b,l), (c,j), (c,k), (c,l))
> > then (b,j), (b,k) ... are binary relations.
>
> That's not the generally accepted definition of the term. Nor is it even
> what that specific book says; I checked. What is says is:
> "Let A and B be sets. A *binary relation* or, simple,
> a *relation* from A to B is a subset of A x B."
> So, to fix your example, the cardinality-2 set { (b,j), (b,k) } is
> a binary relation.
Ok, let me try to understand:
"A *binary relation* from A to B is a subset of A x B."
Since (NULL) is a subset of AxB, it is a binary relation!!!
Since ((b,j)) is a subset of AxB, it is a binary relation.
Since ((b,j), (b,k)) is a subset of AxB, it is a binary relation.
Since ((b,j), (b,k), (b,l)) is a subset of AxB, it is a binary
relation.
and so on....
If the above is the correct interpretation, I find the definition to
be inaccurate in that it has not defined the fundamental form of a
binary relation.
In any case (b,j) is not A binary relation, it is composed OF two
binary relations: b is directly related to A, and j is directly
related to A, therfore, b and j are indirectly related but via A.
> To expand on the comparison a little:
> An example of a binary relation on Z x Z (the integers) is 'less than'.
> So the set of all integers a, b where a < b is a binary relation. If your
> explanation of the standard definition were correct, (which I do
> understand you specifically disagree with) then we would say
> '1<2' and '7<123' are binary relations.
I would say '1<2' is not A binary relation but composed of TWO direct
binary relations. Most people only see the relationship between 1 and
2. I see it as 1 is related to its set(ie whole numbers) AND 2 is
related to its set(ie whole numbers). The < is an indirect or derived
relationship between 1 and 2.
However, I think I see where my perceptions mismatches or errors from
that of the rest. The rest see three nodes and TWO links as a binary
relation, the rest count relations. I have been calling TWO nodes and
one link a binary relation, I counted things. Is this where my mistake
lies?
Set theory books say X-Y-Z is a binary relation because there are two
link.
I have been saying X-Y is a binary relation because there are two
nodes.
But now my symbolic logic books say "If it connects two elements at a
time it is said to be a dyadic relation, if three, triadic". Here they
count things.
As best as I can determine, the word "binary" before the word
"relation" could be interpretted in two way:
1. indicates the number of relations.
2. a relation between 2 things.
Neo
You maybe right, however etymologically the word relation came before
relationship.
> In some sense, Codd would have done better naming the model
> "The Logical Model of Data".
Actually I think the name is apppropriate but the word relational in
"relational data model" should mean 'that which is common among
things' or similar and not 'a set of tuples'.
Neo
>
> Well, I just don't see this happening.
> When do you *ever* need to be able to do that?
Nearly all humans, in the past, now, and in the future do this
practically every single day of their life: related things, any two
things in various types of relations.
Neo
> what color is this job? How many persons does this chair have?
In order to indicate a meaning more clearly, a node would typically
have to be the intersection of many things, just like a tuple.
Alfredo Novoa
> In some sense, Codd would have done better naming the model "The Logical
> Model of Data".
> It would have been more impressive.
I prefer: "The Logical Theory of Data".
Regards
Alfredo