Issues with the logical consistency of The Third Manifesto
Ja Lar
reading of the Third Manifesto' (available at http://www.gits.nl/).
Marshall Spight
> I would like to hear opinions about Maurice Gittens paper 'A critical
> reading of the Third Manifesto' (available at http://www.gits.nl/).
I thought it wasn't very well written; I didn't like the way he
breaks up the article, so that a lot of paragraphs are on a
page by themselves; he uses too many commas.
Oh, you wanted an opinion on the *substance* of the article?
Well, I skimmed it; it was very wordy. Any critique of D&D's
"First Great Bluder" is okay in my book; their whole idea
is weak. It's pretty funny to hear them complain about how there
is no single definition of what an object is, and then conclude
that objects aren't tuple. How did they conclude that without
a definition of what an object is? In any event, it's pretty
clear that D&D don't really understand OOP; look at this
week's dbdebunk, in which a very interesting letter is posted
about some aspects of language design involving objects and
relations, and Date says he pretty much doesn't understand
the interesting parts.
OTOH I think the author really misses the point on his
critique of the Second Great Blunder. (Shall we just
call them 1GB and 2GB?) Pointerless programming is
a big win.
Marshall
Jonathan Leffler
> "Ja Lar" <in...@mail.her> wrote :
>>I would like to hear opinions about Maurice Gittens paper 'A critical
>>reading of the Third Manifesto' (available at http://www.gits.nl/).
>
>
> I thought it wasn't very well written; I didn't like the way he
> breaks up the article, so that a lot of paragraphs are on a
> page by themselves; he uses too many commas.
I didn't see the paragraphs on their own page. The way Gittens uses
commas is not idiomatic in English, but English is (almost certainly)
not his native tongue. Cut him a little slack.
> Oh, you wanted an opinion on the *substance* of the article?
>
> Well, I skimmed it; it was very wordy. Any critique of D&D's
> "First Great Bluder" is okay in my book; their whole idea
> is weak. It's pretty funny to hear them complain about how there
> is no single definition of what an object is, and then conclude
> that objects aren't tuple. How did they conclude that without
> a definition of what an object is? In any event, it's pretty
> clear that D&D don't really understand OOP; look at this
> week's dbdebunk, in which a very interesting letter is posted
> about some aspects of language design involving objects and
> relations, and Date says he pretty much doesn't understand
> the interesting parts.
>
> OTOH I think the author really misses the point on his
> critique of the Second Great Blunder. (Shall we just
> call them 1GB and 2GB?) Pointerless programming is
> a big win.
To quote from the Gittens document - discussing 1GB:
<quote section="2.1" footnotes="omitted">
The reason given [in TTM] to substantiate the claim that object
classes and domains are determined to be the same thing is presented
as the fact that for both, domains and object classes, it holds that
their values are manipulated by operators defined for the type in
question. However, the same argument can be made for relations. Is it
not the case that relations values are manipulated by a set of
operators defined specifically for their types. Yes, relation types
have a set of pre-defined operators, does this make them logically
different from a specific class of domains which have a pre-designated
set of operators? No, it does not! OK, since this argumentation is
said to be informal, the author proceeded to seek out, the formal
arguments presented, for labeling the first great blunder as such.
Apart from reiterations of the alleged rst great blunder, no such
argument has currently been found by the author. Additionally, Date
and Darwen, seem to assume that there is one so-called right way, in
which objects and relations should be integrated. Does not the
discipline of logic dictate that one must prove, that there exists
only one right way, before one could even claim to provide the one
right way? Is it not possible that there are different ways, each with
its own merit, to achieve the integration between objects and relations?
</quote>
That gives a flavour of the text and its verbosity. I've not read the
whole document, but this seems to be the meat of the debunking of the
1GB, and it is not very compelling to me.
Q1: "relation values are manipulated by [...] operators defined
specifically for their types"?
A1: No, relations are manipulated by generic operators, not by
operators defined for a specific relation. That is, the JOIN operator
is not tied to a single pair of relations. The JOIN operator in TTM
works on any pair of relations (subject only fixing up name/type
clashes in the attributes via the RENAME operator). That is *not* an
operation defined specifically for any particular pair of relations.
Q2: "does this make them logically different from a specific class of
domains which have a pre-designated set of operators"?
A2: Assuming that "class of domains" is merely a verbose way of saying
"domains", then I think the answer is: Yes, the relational operators
are quite different from the operators associated with a TTM type.
The generic nature of the JOIN operator is very different from the
type-specific operations associated with a type (such as the 'plus'
operator associated with a numeric type).
A2-b: If the "class of domains" really does mean a grouping of
different domains, then there is no definition of what this means, nor
any explanation of how the domains are similar.
Q3: "Is it not possible that there are different ways [...] to achieve
the integration between objects and relations"?"
A3: Possibly, but you (Gittens) would need to demonstrate what these
alternatives are, and why the alternatives have merits. And that, I
think, Gittens signally fails to do - certainly in the opening four
pages of the thirteen-page document.
So, I disagree with Gittens' claimed demolition of 1GB - I do not
consider that he has proved his point at all.
[Personally, I consider the issue of (paraphrased) "if a relation type
is a domain, then which operators apply to a projection of the
relation" to be very strong support for D&D's claim that the 1GB is
indeed a great blunder. If someone would explain how this question is
resolved, I would reconsider, but in the absence of such an
explanation, I regard that as sufficient to demolish the 'domain =
relvar' equation which is the heart of 1GB. I consider that there are
other strong arguments too (for instance: domains are invariant but
relation variables are not), but we can discuss those after you've
dealt with this one.]
--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
Laconic2
a thing or two.
I think that the issues surrounding 1GB are a great deal less profound than
everyone makes them out to be.
When we start to talk about "operators on a domain", we should start with
the most basic operator of them all: the equality tester. The operator
that is represented in SQL predicates by a single equal sign. (A single
equal sign is also used by SQL to represent assignment, but that's another
topic). Now when you are given "A = B" and you must return TRUE or FALSE,
the question is, how?
The first step is to determine whether you are going to compare the values,
or whether you are going to compare some kind of representation of the
values. Now the theoreticians in this newsgroup will all shout out, in
chorus: "THE VALUES!" Ay, there's the rub!
All we have inside of computers is representations. That's all there is in
there, fellas. There is not a single "value" actually inside the machine.
I don't care whether you follow Codd or Date or Dawn or Neo, it's all
representation. I don't care whether you follow Babbage or Ada Lovelace or
John Von Neumann or Knuth, it's all representation.
So the point is that, if two representations represent the same value, we
have to work things out so that the equality tester can detect that fact,
and return the right result. If we indeed find that two distinct
representations of the "state of a relvar" can represent the same relation,
then we are going to have to find an algorithm for reducing equivalent
representations to a common representation, one that can be used for
comparison.
You might as well call that "normalizing the relation". And there we are,
back to normalizing. This DOESN'T prove that Date is wrong with 1GB. Date
could be right. It may be that there is some OTHER way of normalizing a
relation that isn't the same way that Codd proposed. But until you
NORMALIZE the representations of relations, you can't tell whether two of
them are equal.
Laconic2
"Laconic2" <laco...@comcast.net> wrote in message
news:zdqdneWfr8Q...@comcast.com...
> You might as well call that "normalizing the relation".
Correction: The above is in error, and it's significant in this context.
Here's the corrected version:
You might as well call that "normalizing the form of the relation".
I'm never as careful with language as I wish I were.
Jan Hidders
>
> So, I disagree with Gittens' claimed demolition of 1GB - I do not
> consider that he has proved his point at all.
But demolishing 1GB was not his point. In his own words:
"I think it important to state explicitely, that my claim in this
regard, is not that Date and Darwen are wrong in their opinions. My
claim, in this regard, is that the substantiation they provide as
justication for their statement that the alleged great blunders are
indeed great blunders is rather weak, relative to the high standard they
claim to be central to their work."
-- Jan Hidders
Costin Cozianu
"classes" with relations or with relation variables. Some people still
believe that, although the riguorous proof of the drastic consequences
supposed to follow is completely lacking.
So here's a direct positive refutation, including with inheritance( well
that maybe later, as it is orthogonal).
Say the minimal common entity (in case you don't believe an ERD, a set
of attributes that are grouped together in a base relvar) is a User.
Most systems have an users table:
USERS( user_id, username, password, email )
where user_id is UNIQUE NOT NULL, and the same is USERNAME.
Most of the client programmers, be it in Java, C++, whatever, create a
User class with respective attributes. The reason for that is simply
manageability and economy of expression. You do not want to carry around
4 variables, namely userID, userName, password, email, to do some
processing (even if just displaying on an output device) when you can
simple manipulate just 1 variable and that be user.
if that was a blunder, we'd all be suffering terrible consequences, but
we don't, and even if that wasn't a proof enough in itself, let's
consider how we should do it:
if we have a User(userID,username, password, email) TYPE, than that type
is a domain, and we should store it inside the database only within a
column.
So voila we have a UsersTable( user : User) table. of course the primary
key would be now constructed on the expression user.userID rather than
ona set of direct attributes, and so the other uniqueness constraint
would be on user.username rather than on a set of attributes.
But then since we have the deconstructors/accessors user.userID,
user.userName, user.email, we can regard the table thus defined
perfectly isomorphic/interchangeable (including under the strictest
definition of view updates) with the view
create view UsersView as select user.userID, user.userName, user.email,
user.passwor from UsersTable
Because they are so obviously interchangeable with regards to all
relational operators as well as with regards to updates, if one is a
blunder than the other is a blunder. But one would be a blunder
according to D&D and another would be prescribed according to D&D.
So the pragmatic knowledge that everybody and their grandma programming
systems these days do have a Users table and do have a User class, and
nothing bad happens because of this designed is directly confirmed by
simple logical reasoning.
The same goes if the User information will not make up the whole table
but would be just a column in a larger table. we can create the
equivalent/interchangeable view table by selecting expressions on that
object, as long as we have the accessor/deconstructor for attributes of
the object. For example PointsTable1(x:int, y:int) <=>
PointsTable2(p:Point) where Point = {x:int, y:int} as type.
In my current software system that puts food on my table I have two
types of users (therefore subtyping/type unification and all that)
anonymous_users and registered_users, and guess what, I have two tables
for that. And it works, nevermind it's Oracle, but even if I had the
perfect TutorialD database (which will never happen) my design would
have been the same and would have been 100% isomorphic with a design
that follows strictly D&D prescription for putting object values in one
column (more formally types from OO are domains inside the relational
database).
Best,
Costin
Alfredo Novoa
<c_co...@hotmail.com> wrote:
>In The Third Manifesto, D&D affirm that 'tis a great blunder to equate
>"classes" with relations or with relation variables.
This is rather evident that it is a blunder to confuse types with
variables or values.
> Some people still
>believe that, although the riguorous proof of the drastic consequences
>supposed to follow is completely lacking.
It is hard to prove the practical consequences of a mistake that
almost nobody makes.
I don't know any developer that confuses types with variables or
values.
>Most of the client programmers, be it in Java, C++, whatever, create a
>User class with respective attributes.
This is probably a little mistake, but in almost all cases it does not
have relationship with Date's 1stGB.
Date's 1GB is related to a vanished fad of the 90's called OODBMS. It
has very little relevance today and it was never very relevant IMO.
>if that was a blunder, we'd all be suffering terrible consequences, but
>we don't, and even if that wasn't a proof enough in itself, let's
>consider how we should do it:
Most OO database projects suffer terrible consequences due to other
blunders, but the developers are not aware of it and they think that
the terrible consequences are a part of the job.
>So the pragmatic knowledge that everybody and their grandma programming
>systems these days do have a Users table and do have a User class, and
>nothing bad happens because of this designed is directly confirmed by
>simple logical reasoning.
This is not true. There are many systems that don't have an User class
and they have a DataSet or RecordSet instance that represents an Users
table.
IMO an User class would be superfluous in an application, but it would
not cause big problems necessarily.
Regards
Tony Andrews
> Well, I skimmed it; it was very wordy. Any critique of D&D's
> "First Great Bluder" is okay in my book; their whole idea
> is weak. It's pretty funny to hear them complain about how there
> is no single definition of what an object is, and then conclude
> that objects aren't tuple. How did they conclude that without
> a definition of what an object is?
Well, "everyone" agrees that an object has atributes that you can't
access directly, only via methods; whereas tuples have attributes that
you can access directly, and has no methods. So even without a single,
formal definition of an object it is clear that whatever it is, it is
NOT a tuple!
> In any event, it's pretty
> clear that D&D don't really understand OOP; look at this
> week's dbdebunk, in which a very interesting letter is posted
> about some aspects of language design involving objects and
> relations, and Date says he pretty much doesn't understand
> the interesting parts.
I agree that this is a poor response, but not necessarily that Date
doesn't understand OOP. I think it is another example of the dbdebunk
"signal to noise" issue we have been discussing lately - an answer that
clearly involved less than 2 minutes thought is published as if it
contained something of significance for the public to read.
Josh Hewitt
> So the pragmatic knowledge that everybody and their grandma programming
> systems these days do have a Users table and do have a User class, and
> nothing bad happens because of this designed is directly confirmed by
> simple logical reasoning.
What if you think about your User class as a synonym for the tuple type in
the Third Manifesto? This way you can pass around one variable (a tuple)
and you can store one value (a tuple) in the database. Maybe this is
why nothing bad happens in this simple case.
However, when you add a getOrders() method to your User class
things do get complicated. (I guess the Order class would need a backward
reference to the 'containing' User object too.) This means that you will
have an 'orders' member variable in your User class that stores a set of
references to Order objects. Now, if you want to store your User object
to the database you will face the good ol' O/R mapping cookie monster that
Date and Darwen wanted to get rid of so badly :)
In my opinion, the 'impedance mismatch' between relational DBMSs
and OO languages comes into picture only when we want to map object
graphs to relational tables. Object graphs represent relationships between
entities through one-way references while tuples use common attribute values
for the same purpose, thus making the relationships two-way and explicit.
The larger and more intricate our object graphs are the more we feel the
effects of the mismatch.
This might be the explanation why your example of a simple User class that
maps to a User relation works perfectly in practice. (There is no object
graph so the mismatch is negligible.) Although you still have to do some
(more or less) manual mapping to construct User objects from result set
rows and to store User objects to the relational DBMS.
Regards,
Josh Hewitt
Ph.D. Student
Florida Institute of Technology
Alfredo Novoa
wrote:
>However, when you add a getOrders() method to your User class
>things do get complicated.
Indeed, when you add something like that, you are starting to manage
the database from the application, which is a great blunder that is
not Date's 1GB.
>In my opinion, the 'impedance mismatch' between relational DBMSs
>and OO languages comes into picture only when we want to map object
>graphs to relational tables.
The impedance mismatch is inherent to the languages because they don't
allow relation variables.
You can not match a relational database if you don't have relations.
>This might be the explanation why your example of a simple User class that
>maps to a User relation works perfectly in practice.
An User class can't map to an User relation because it is an absurd to
map types to variables or values (Date's 1stGB).
An unidimensional collection of User objects maps to an User relation.
This is perfectly possible and it is not a great blunder.
> Although you still have to do some
>(more or less) manual mapping to construct User objects from result set
>rows and to store User objects to the relational DBMS.
Indeed, and without any gain.
Regards
Laconic2
"Tony Andrews" <andr...@onetel.com> wrote in message
news:1100525986.8...@z14g2000cwz.googlegroups.com...
> I agree that this is a poor response, but not necessarily that Date
> doesn't understand OOP. I think it is another example of the dbdebunk
> "signal to noise" issue we have been discussing lately - an answer that
> clearly involved less than 2 minutes thought is published as if it
> contained something of significance for the public to read.
>
It used to be "a penny for your thoughts."
Now it's "a sawbuck for my thoughts."
Costin Cozianu
StrawMan removed
>>This might be the explanation why your example of a simple User class that
>>maps to a User relation works perfectly in practice.
>
>
> An User class can't map to an User relation because it is an absurd to
> map types to variables or values (Date's 1stGB).
>
Where by "map" you speak loosey-goosey not mathematics.
But it may very well be that all entities of type user are hosted in the
database as tuple inside a User table.
So for some subset of types X (user, account, order, product) etc, for
each type X_type there's a corresponding X_table in the database. And
there's nothing wrong with that, Date and your unargumented opinion
notwithstanding.
Ja Lar
>>On Sun, 14 Nov 2004 20:45:12 -0800, Costin Cozianu
>>In The Third Manifesto, D&D affirm that 'tis a great blunder to equate
>>"classes" with relations or with relation variables.
> This is rather evident that it is a blunder to confuse types with
> variables or values.
A class may in fact be a value (an instance) of a (meta)class.
A class is (amongst other things) (something like) a type.
A type is (amongst other things) something like a set of values.
A relation is (amongst other things) something like a set of tuples.
An object is (amongst other things) a "record of data", somewhat like a
tuple
A type can be a relation type, and the value of an attribute of a relation
can of a relation type...
So the blunder is perhaps not _that_ evident, but rather understandable
(even if it is a blunder - and it is, but...).
<snip>
> IMO an User class would be superfluous in an application, but it would
> not cause big problems necessarily.
Taking a User class as an _example_ (even if a simple one), it is not
obvious to me that such a class "would be superfluous". OO is not complety
without merits!
Ja Lar
<snip - but may return to it later ...>
> OTOH I think the author really misses the point on his
> critique of the Second Great Blunder. (Shall we just
> call them 1GB and 2GB?) Pointerless programming is
> a big win.
How, more exact, do you find mr. Gittens misses the point in his critique of
2GB?
What, in your opinion, is the connection between OIDs, (surrogate)keys and
pointers?
What do "pointerless programming" mean? Are you referring to eg. Java, where
"nothing is a pointer, but everything is a reference"?
Alfredo Novoa
wrote:
>Well, I skimmed it; it was very wordy. Any critique of D&D's
>"First Great Bluder" is okay in my book; their whole idea
>is weak.
IMO the idea is trivially true: types are types and not variables. But
the First Great Blunder is a rare mistake.
People don't identify classes with relations, people ignore and reject
all modern data management theory. They often design that kind of
classes because they want to manage the data from the applications.
They never think about relations nor they know what relations are.
This is a blunder, but not Date's First Great Blunder.
> It's pretty funny to hear them complain about how there
>is no single definition of what an object is, and then conclude
>that objects aren't tuple.
I don't see that conclusion.
Tuples are objects, relations are objects, classes are objects,
variables are objects, operators are objects, I am an object,
everything is an object.
A good definition of object is this:
Object: Something intelligible or perceptible by the mind.
>a definition of what an object is? In any event, it's pretty
>clear that D&D don't really understand OOP;
I disagree. IMO they understand OOP a lot better than the overwhelming
majority of the OO coders.
The problem is that the principle of incoherence applies to the OOP.
>about some aspects of language design involving objects and
>relations, and Date says he pretty much doesn't understand
>the interesting parts.
What does "the possibility of joining tables and having the proper
'class' materialize to handle it" means?
He does not understand it because it is very bad expressed. There is
nothing valuable or specific to the OO there.
>OTOH I think the author really misses the point on his
>critique of the Second Great Blunder. (Shall we just
>call them 1GB and 2GB?) Pointerless programming is
>a big win.
He also misses the point about the identity of the objects.
Regards
Ja Lar
"Alfredo Novoa" <ano...@ncs.es> ...
<snip>
> Tuples are objects, relations are objects, classes are objects,
> variables are objects, operators are objects, I am an object,
> everything is an object.
>
> A good definition of object is this:
>
> Object: Something intelligible or perceptible by the mind.
With such a definition you exclude yourself from commenting on what OO
means.
For you it obviously means everything, i.e. in fact nothing in particular.
Now, if an OO-addicted mixes relations, tables and classes you bash him. But
he might have another definition of a relation than you do ...
It is certainly true that "relation" is much, much better and more
unambiguous defined than "class" and "object". But quite a few knows a
difference between class, object, operator, relation etc., even if you
apparently don't (accept such a distinction).
> He also misses the point about the identity of the objects.
How? And what do you mean by "objects" here?
Theo Johnson
> Q1: "relation values are manipulated by [...] operators defined
> specifically for their types"?
>
> A1: No, relations are manipulated by generic operators, not by
> operators defined for a specific relation. That is, the JOIN operator
> is not tied to a single pair of relations. The JOIN operator in TTM
> works on any pair of relations (subject only fixing up name/type
> clashes in the attributes via the RENAME operator). That is *not* an
> operation defined specifically for any particular pair of relations.
>
the most specific "type" of relation? (After all its still a
relation.) Taken with the other relational operators, haven't we
defined an algebra over a type? The type being the relation?
Abstractly, if we can take a "type" without regard to its structure,
we can define an algebra over that type. From that 30,000 ft view,
relations and objects have a lot of similarities. At least that's what
it sounds like to me.
Jan Hidders
> In The Third Manifesto, D&D affirm that 'tis a great blunder to equate
> "classes" with relations or with relation variables. Some people still
> believe that, although the riguorous proof of the drastic consequences
> supposed to follow is completely lacking.
>
> So here's a direct positive refutation, including with inheritance( well
> that maybe later, as it is orthogonal).
You are so right that it's almost boring. :-) If there had been any real
logical problems with letting relational variables play the role of
types then it would have not been possible or very difficult to come up
with a decent formal data model for that. It wasn't. QED
But this is all besides the point of course. Because, you see, they have
these books. And these books say that it cannot be so. So it isn't. ;-)
-- Jan Hidders
Ja Lar
"Jan Hidders" <jan.h...@REMOVETHIS.pandora.be> ...
> Costin Cozianu wrote:
>> In The Third Manifesto, D&D affirm that 'tis a great blunder to equate
>> "classes" with relations or with relation variables. Some people still
>> believe that, although the riguorous proof of the drastic consequences
>> supposed to follow is completely lacking.
>>
>> So here's a direct positive refutation, including with inheritance( well
>> that maybe later, as it is orthogonal).
> You are so right that it's almost boring. :-) If there had been any real
> logical problems with letting relational variables play the role of types
> then it would have not been possible or very difficult to come up with a
> decent formal data model for that. It wasn't. QED
Your observation is so profound that some may be uncertain if your are
sarcastic or blunt.
Are you are referring to the model that allows an attribute to be of a
relational type-domain ...
Christopher Browne
> "Alfredo Novoa" <ano...@ncs.es> ...
> <snip>
>
>> Tuples are objects, relations are objects, classes are objects,
>> variables are objects, operators are objects, I am an object,
>> everything is an object.
>>
>> A good definition of object is this:
>>
>> Object: Something intelligible or perceptible by the mind.
>
> With such a definition you exclude yourself from commenting on what
> OO means. For you it obviously means everything, i.e. in fact
> nothing in particular.
Ah, but the problem is that those are all virtually equally legitimate
answers as to what OO "means."
I am only aware of two works that try to put together a theory-based
presentation of what "objects" are:
a) _A Theory of Objects_ by Martin Abadi, Luca Cardelli and
b) _Types and Programming Languages_ by Benjamin C. Pierce
Aside from those fairly obscure references, "OO" generally seems to
mean "whatever programming model they put into my favorite language
that they decided to call 'object oriented.'"
Thus, to some, "OO" means the things you can express using C++
classes.
To others, it represents the things expressible using Java classes.
To still others, it is about creating function methods to allow
Smalltalk objects to invoke the right bits of code in order to pass
messages to other Smalltalk objects.
Those are just three particular sets of dogma; probably the most
flexible object system is in Common Lisp, where CLOS combined aspects
of LOOPS, Flavors, as well as other "object models" of the 1980s.
(And that's not to imply any obsolescence; I can't see that there have
been any honest-to-goodness new developments since then...)
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://linuxfinances.info/info/nonrdbms.html
There are two kinds of pedestrians -- the quick and the dead.
Marshall Spight
> > Well, I skimmed it; it was very wordy. Any critique of D&D's
> > "First Great Bluder" is okay in my book; their whole idea
> > is weak. It's pretty funny to hear them complain about how there
> > is no single definition of what an object is, and then conclude
> > that objects aren't tuple. How did they conclude that without
> > a definition of what an object is?
>
> Well, "everyone" agrees that an object has atributes that you can't
> access directly, only via methods; whereas tuples have attributes that
> you can access directly, and has no methods. So even without a single,
> formal definition of an object it is clear that whatever it is, it is
> NOT a tuple!
I hear you, but I don't find this line of thought convincing. Why
do objects protect fields with accessor methods? Certainly it's
more complicated; what is the benefit that outweighs the complexity
cost? It is that this encapsulation allows one to programmatically
enforce constraints on the values the object can take on. Would
one need encapsulation if one had declarative integrity constraints?
I hypothesize not. In which case the distinction you're drawing
wouldn't apply.
Marshall
Marshall Spight
> On Sat, 13 Nov 2004 15:32:44 GMT, "Marshall Spight" <msp...@dnai.com>
> wrote:
>
> >Well, I skimmed it; it was very wordy. Any critique of D&D's
> >"First Great Bluder" is okay in my book; their whole idea
> >is weak.
>
> IMO the idea is trivially true: types are types and not variables. But
> the First Great Blunder is a rare mistake.
>
> People don't identify classes with relations, people ignore and reject
> all modern data management theory. They often design that kind of
> classes because they want to manage the data from the applications.
> They never think about relations nor they know what relations are.
I tend to agree.
> Tuples are objects, relations are objects, classes are objects,
> variables are objects, operators are objects,
Agreed.
> > In any event, it's pretty
> > clear that D&D don't really understand OOP;
>
> I disagree. IMO they understand OOP a lot better than the overwhelming
> majority of the OO coders.
I've seen no evidence that they understand it in any least way.
> The problem is that the principle of incoherence applies to the OOP.
I disagree here.
> What does "the possibility of joining tables and having the proper
> 'class' materialize to handle it" means?
>
> He does not understand it because it is very bad expressed. There is
> nothing valuable or specific to the OO there.
Really? I thought this was one of the best comments the poster had.
What does it mean? It seems obvious to me; but then, I've done
a lot of application coding that talks to a dbms in OOPLs. It means
that one would like to be able to have a lightweight way of having
a class (alternatively: a set of methods) associated with the rows
of a resultset, even if this resultset came from a join, so that one
could directly go from a query to a set of objects.
Marshall
Marshall Spight
> Martha Stewart called it a Good Thing when "Ja Lar" <in...@mail.her> wrote:
> > "Alfredo Novoa" <ano...@ncs.es> ...
> > <snip>
> >
> >> Tuples are objects, relations are objects, classes are objects,
> >> variables are objects, operators are objects, I am an object,
> >> everything is an object.
> >>
> >> A good definition of object is this:
> >>
> >> Object: Something intelligible or perceptible by the mind.
> >
> > With such a definition you exclude yourself from commenting on what
> > OO means. For you it obviously means everything, i.e. in fact
> > nothing in particular.
>
> Ah, but the problem is that those are all virtually equally legitimate
> answers as to what OO "means."
>
> I am only aware of two works that try to put together a theory-based
> presentation of what "objects" are:
> a) _A Theory of Objects_ by Martin Abadi, Luca Cardelli and
> b) _Types and Programming Languages_ by Benjamin C. Pierce
>
> Aside from those fairly obscure references, "OO" generally seems to
> mean "whatever programming model they put into my favorite language
> that they decided to call 'object oriented.'"
You call those obscure?! Is anyone who pays attention to theory and
to OO unaware of these?
> Thus, to some, "OO" means the things you can express using C++
> classes.
>
> To others, it represents the things expressible using Java classes.
>
> To still others ...
Many people go on about how OO means so many different things,
but I've not had that experience. It is true that there are different
object models used by different OO programming languages, but
the similarities are much greater than the differences. You have
polymorphism, inheritance, and encapsulation. Go to comp.object
and you'll hear lots of hair-splitting over details, but that doesn't
mean there isn't substantial agreement.
Marshall
Marshall Spight
> representation.
This sentence really struck me. It's almost poetry.
"Neo": new
"Dawn": the first instant of sunlight
"Date": a specific day
"In the beginning, there was nothing. And on the first day, there
was light. Then came ..."
What? A fish? The relational model?
Is the relational model somehow piscine?
http://images.google.com/images?q=cod
Marshall
Marshall Spight
> there, fellas. There is not a single "value" actually inside the machine.
> I don't care whether you follow Codd or Date or Dawn or Neo, it's all
> representation. I don't care whether you follow Babbage or Ada Lovelace or
> John Von Neumann or Knuth, it's all representation.
Yes; this is an important point.
> So the point is that, if two representations represent the same value, we
> have to work things out so that the equality tester can detect that fact,
> and return the right result. If we indeed find that two distinct
> representations of the "state of a relvar" can represent the same relation,
> then we are going to have to find an algorithm for reducing equivalent
> representations to a common representation, one that can be used for
> comparison.
Okay, so you're right; if we find ourselves is this situation, then we
have to, as it were, normalize the representation. This is hard. If
we only have one possible representation for a type and it's always
normalized, then this isn't an issue. For example, we can have
a rational type, and normalize the fraction after every operation.
In this case, comparing the representation and comparing the
values is the same.
So let's try to figure out what we buy with all this complexity.
If we're going to allow multiple representations for a type,
then it ought to be for a reason, eh?
So what's the reason? I sure can't think of any. As I've pointed
out before, the canonical TTM example of polar vs. cartesian
point isn't even mathematically sound (horrors!) and immediately
introduces all kinds of complexity around either representing
values algebraically, or else having to deal with approximate values,
a dilemma that TTM doesn't even acknowledge, let alone solve.
Marshall
Ja Lar
Martha Stewart called it a Good Thing when "Ja Lar" <in...@mail.her> wrote:
>>
> > "Alfredo Novoa" <ano...@ncs.es> ...
> > <snip>
> >
> >> Tuples are objects, relations are objects, classes are objects,
> >> variables are objects, operators are objects, I am an object,
> >> everything is an object.
> >>
> >> A good definition of object is this:
> >>
> >> Object: Something intelligible or perceptible by the mind.
> >
> > With such a definition you exclude yourself from commenting on what
> > OO means. For you it obviously means everything, i.e. in fact
> > nothing in particular.
>
> Ah, but the problem is that those are all virtually equally legitimate
> answers as to what OO "means."
Not if you claim to be able to compare eg. classes and relations. That is
one of mr. Gittens main points.
If you state that "class=type" or "class<>relation", you have to pick a
definition and stick to it, or you statement becomes meaningless.
And no, they are not all virtually equally legitimate. In fact, OO has
matured to a level where "class" and "object" is fairly well understood on a
fundamental and agreeable way. Not in the same strict mathematical sense as
relations, but beyond the ridicule that is used when real argument fails.
Paul
> Okay, so you're right; if we find ourselves is this situation, then we
> have to, as it were, normalize the representation. This is hard. If
> we only have one possible representation for a type and it's always
> normalized, then this isn't an issue. For example, we can have
> a rational type, and normalize the fraction after every operation.
> In this case, comparing the representation and comparing the
> values is the same.
It might be more efficient to store it unnormalised and only normalise
before an equality test. Maybe you won't even need to normalise - the
standard example is fractions: to test if a/b and c/d are equal you
might just test if a*d = b*c for example, instead of worrying about
highest common factors.
I guess in theory a type implementation would use some kind of
heuristics to decide what's going to be best in any situation.
I think that standard SQL blurs the line between types and relations a
bit with its equality test. For example:
SELECT * FROM t WHERE a = b
The equals is seen more as part of the relational algebra rather than
the type algebra. Why can't WHERE clauses take boolean values like this?:
SELECT * FROM t WHERE equals(a,b)
Maybe it's because SQL doesn't really have proper support for
user-defined types yet.
Paul.
Paul
> You are so right that it's almost boring. :-) If there had been any real
> logical problems with letting relational variables play the role of
> types then it would have not been possible or very difficult to come up
> with a decent formal data model for that. It wasn't. QED
Isn't Date's "first great blunder" to be seen more as a rule of thumb or
a software engineering principle rather than as a formal mathematical truth?
i.e. although it is possible to map classes from an object-oriented
system onto relations in an RDBMS in certain circumstances, as a general
rule it's best avoided?
Paul
Ja Lar
"Paul" <pa...@test.com> skrev i en meddelelse
news:4199bcb4$0$3990$ed26...@ptn-nntp-reader01.plus.net...
> Jan Hidders wrote:
> > You are so right that it's almost boring. :-) If there had been any real
> > logical problems with letting relational variables play the role of
> > types then it would have not been possible or very difficult to come up
> > with a decent formal data model for that. It wasn't. QED
>
> Isn't Date's "first great blunder" to be seen more as a rule of thumb or
> a software engineering principle rather than as a formal mathematical
truth?
Would be a reasonable conclusion. But mr. Gittens points at the fact that
TTM in general presents itself not as "rules of thumb", but as "science" (as
in dbdebunk).
Citation from mr. Gittens paper:
<citation>
Date and Darwen presented the maxim: All logical difference are big
differences and its corollary All logical mistakes are big mistakes as a
guiding principle in their work on the Third Manifesto. The Third Manifesto
proceeded to identify what it refers to as the Two Great Blunders :
a.. Equating relvars and classes
b.. Mixing pointers and relations (or more specifically allowing database
relvars to contain object IDs)
However, in my humble opinion, the argumentation used to substantiate the
claim that the alleged blunders are truly to be viewed as blunders is
somewhat weak. This opinion is based on the following maxim: logical
conclusions should only be drawn from premises which are both logically
valid and relevant. Put another way, keeping in mind the maxim, All logical
differences are big differences, logically valid conclusions are conclusions
based on premises free of fallacies, including fallacies of relevance.
</citation>
Thus, the main issue is not whether or not eg. "class = relvar" is a bad
rule of thumb, but if or not this is concluded on a logical basis.
From a practical view, it doesn't matter much...
Alfredo Novoa
wrote:
>> > In any event, it's pretty
>> > clear that D&D don't really understand OOP;
>>
>> I disagree. IMO they understand OOP a lot better than the overwhelming
>> majority of the OO coders.
>
>I've seen no evidence that they understand it in any least way.
IMO TTM is an evidence.
They know that object sometimes means value, sometimes means variable,
sometimes means conceptual entity, etc.
The know that methods are operators and that class sometimes means
scalar type and sometimes means entity type.
They know how OO inheritance works and that it is more related to
delegation than to subtyping.
They know that there is not a thing called "The OO Data Model".
They know that to bundle operators with a single type is not a good
idea.
They know that pointer based programming is painful and primitive.
Etc.
>> The problem is that the principle of incoherence applies to the OOP.
>
>I disagree here.
I should say to an important part of the OOP authors like Ambler,
Larman.
>> He does not understand it because it is very bad expressed. There is
>> nothing valuable or specific to the OO there.
>
>Really?
Really, it is horribly expressed.
>What does it mean? It seems obvious to me; but then, I've done
>a lot of application coding that talks to a dbms in OOPLs. It means
>that one would like to be able to have a lightweight way of having
>a class (alternatively: a set of methods) associated with the rows
>of a resultset, even if this resultset came from a join, so that one
>could directly go from a query to a set of objects.
I am using that kind of classes since my first database application.
In Delphi such class is called TDataSet, in VB I think that it was
called RecordSet, in .NET there is a class called DataTable, in
PowerBuilder there is a class called DataWindow, etc.
Regards
Laconic2
"Marshall Spight" <msp...@dnai.com> wrote in message
news:dBhmd.102104$R05.62118@attbi_s53...
> "Laconic2" <laco...@comcast.net> wrote in message
news:zdqdneWfr8Q...@comcast.com...
> >
> > I don't care whether you follow Codd or Date or Dawn or Neo, it's all
> > representation.
>
> This sentence really struck me. It's almost poetry.
Aw shucks!
>
> "Neo": new
> "Dawn": the first instant of sunlight
> "Date": a specific day
>
> "In the beginning, there was nothing. And on the first day, there
> was light. Then came ..."
Actually the Bible passage I was using as a model was I Corinthians 3:4.
Laconic2
> Okay, so you're right; if we find ourselves is this situation, then we
> have to, as it were, normalize the representation. This is hard. If
> we only have one possible representation for a type and it's always
> normalized, then this isn't an issue. For example, we can have
> a rational type, and normalize the fraction after every operation.
> In this case, comparing the representation and comparing the
> values is the same.
OK, now we're getting somewhere. The question I have is: did Codd find
himself in that situation when he was preparing the 1970 paper, and if he
did, was this a great blunder or not?
Codd made the distinction in the paper between what he called arrays, made
up of rows and columns, and relations themselves. He said that we often
use the terminology of arrays when discussing relations, but we should
remember that
arrays are really the representation of relations (meaning, I take it, the
form of relations) and not relations themselves.
I take "Arrays" in the 1970s paper to be the equivalent of "tables" in later
usage.
And now the question is, how do you test two relations for equality? And
the answer is, it depends on how they are represented. If there is more
than one way to represent a relation using arrays, such that the arrays are
not equal, but the relations thus represented are equal, then we have to
normalize at equality testing time.
Now, order of the rows is inherent in an array, but order of the tuples is
irrelevant in a relation. So, if our equality tester
has to check two arrays, to see if they both represent the same relation,
it might have to sort both of them, in order to do a row by row comparison.
This is hell. It's probably cheaper to decompose the relvars out of the
original relations, and then test the foreign keys for equality. It means
more complexity, and more joins, but less sorting.
So if arrays are the "form" of a relation, then "normal form" (later known
as 1st normal form) is what we get when we decompose out all the relvars.
Right?
Laconic2
Marshall Spight
>
> I think that standard SQL blurs the line between types and relations a
> bit with its equality test. For example:
>
> SELECT * FROM t WHERE a = b
>
> The equals is seen more as part of the relational algebra rather than
> the type algebra. Why can't WHERE clauses take boolean values like this?:
>
> SELECT * FROM t WHERE equals(a,b)
>
> Maybe it's because SQL doesn't really have proper support for
> user-defined types yet.
It's long bugged me that the relational algebra has such seemingly
non-algebraic things in it as restrict and project.
Marshall
Marshall Spight
>
> "Marshall Spight" <msp...@dnai.com> wrote in message
> news:SGhmd.102152$R05.26010@attbi_s53...
>
> > Okay, so you're right; if we find ourselves is this situation, then we
> > have to, as it were, normalize the representation. This is hard. If
> > we only have one possible representation for a type and it's always
> > normalized, then this isn't an issue. For example, we can have
> > a rational type, and normalize the fraction after every operation.
> > In this case, comparing the representation and comparing the
> > values is the same.
>
> OK, now we're getting somewhere. The question I have is: did Codd find
> himself in that situation when he was preparing the 1970 paper, and if he
> did, was this a great blunder or not?
>
> Codd made the distinction in the paper between what he called arrays, made
> up of rows and columns, and relations themselves. He said that we often
> use the terminology of arrays when discussing relations, but we should
> remember that
> arrays are really the representation of relations (meaning, I take it, the
> form of relations) and not relations themselves.
I think this is quite important. (Much more important than, say, the
distinction between database and dbms :-)
> And now the question is, how do you test two relations for equality? And
> the answer is, it depends on how they are represented. If there is more
> than one way to represent a relation using arrays, such that the arrays are
> not equal, but the relations thus represented are equal, then we have to
> normalize at equality testing time.
Indeed.
> Now, order of the rows is inherent in an array, but order of the tuples is
> irrelevant in a relation.
Yes! And I draw an important conclusion from this: it's important for
the system to *know* whether a given collection is ordered or not.
That is, the code has to declare it.
> So, if our equality tester
> has to check two arrays, to see if they both represent the same relation,
> it might have to sort both of them, in order to do a row by row comparison.
> This is hell.
Nobody said an equality test would be cheap. Note also that an analogous
issue arises even with the equality test for two tuples. But I don't think
this is really that big an issue; for example, there's nothing in the documentation
for Java's Object.equals() that says it should complete in a hurry.
> It's probably cheaper to decompose the relvars out of the
> original relations, and then test the foreign keys for equality. It means
> more complexity, and more joins, but less sorting.
This is a significant question, but it is implementation merely.
> So if arrays are the "form" of a relation, then "normal form" (later known
> as 1st normal form) is what we get when we decompose out all the relvars.
> Right?
Uh, dunno.
Marshall
Marshall Spight
> On Tue, 16 Nov 2004 02:58:23 GMT, "Marshall Spight" <msp...@dnai.com>
> wrote:
>
> >> > In any event, it's pretty
> >> > clear that D&D don't really understand OOP;
> >>
> >> I disagree. IMO they understand OOP a lot better than the overwhelming
> >> majority of the OO coders.
> >
> >I've seen no evidence that they understand it in any least way.
>
> IMO TTM is an evidence.
>
> They know that object sometimes means value, sometimes means variable,
> sometimes means conceptual entity, etc.
Actually, an object is always a value, and simultaneously always a
variable (assuming it has any mutable fields.) It is also always a
conceptual entity. But this is such triviality that I've never seen
anyone bother to mention it. No one is *confusing* values and
variables; an object is both, and which one we are talking
about is, most of time, immediately obvious.
There *is* an issue with the difference between equality and
identity in OOP, but this is fairly easily mastered by beginners.
> The know that methods are operators and that class sometimes means
> scalar type and sometimes means entity type.
>
> They know how OO inheritance works and that it is more related to
> delegation than to subtyping.
Okay.
> They know that there is not a thing called "The OO Data Model".
Yes, but this doesn't matter. There are specific models associated
with each specific OOPL, and they are quite well documented
down to the last detail. There are also substantial commonalities
among the different models.
> They know that to bundle operators with a single type is not a good
> idea.
The binary method issue? This is again a fairly unimportant issue.
> They know that pointer based programming is painful and primitive.
Here I will agree that they are ahead of the OO crowd, which is
still quite wrapped up in pointers.
> Etc.
>
> >> The problem is that the principle of incoherence applies to the OOP.
> >
> >I disagree here.
>
> I should say to an important part of the OOP authors like Ambler,
> Larman.
Hmmm. I will not disagree. But I will point out that there are
some quite coherent authors on OOP; Fowler for example,
or see also Joshua Bloch's brilliant "Effective Java."
> >> He does not understand it because it is very bad expressed. There is
> >> nothing valuable or specific to the OO there.
> >
> >Really?
>
> Really, it is horribly expressed.
>
> >What does it mean? It seems obvious to me; but then, I've done
> >a lot of application coding that talks to a dbms in OOPLs. It means
> >that one would like to be able to have a lightweight way of having
> >a class (alternatively: a set of methods) associated with the rows
> >of a resultset, even if this resultset came from a join, so that one
> >could directly go from a query to a set of objects.
>
> I am using that kind of classes since my first database application.
>
> In Delphi such class is called TDataSet, in VB I think that it was
> called RecordSet, in .NET there is a class called DataTable, in
> PowerBuilder there is a class called DataWindow, etc.
Does they have methods specific to the specific join? I think
that is what the guy was referring to. Ideally this would be
done dynamically, not via code generation.
Marshall
erk
> What does "the possibility of joining tables and having the proper
> 'class' materialize to handle it" means?
and then Marshall wrote:
> It means that one would like to be able to have a lightweight way
> of having a class (alternatively: a set of methods) associated with
> the rows of a resultset, even if this resultset came from a join, so
> that one could directly go from a query to a set of objects.
This is, in the words of Frank Zappa, the crux of the biscuit. A
relation (derived perhaps via one or more JOINs) has a more specific
type than relation; for this discussion, let's call the type of one of
its tuples the "tuple-type". The tuple-type can be derived from the
relational expression. To define an operator over that tuple-type would
be to define it in terms of its attributes, right? So what value (other
than perhaps namespace) does associating that operation with the
tuple-type have?
I think of this as a potential shortcut, but of far less value than the
encapsulation that can be used with an OO language to define types. It
would be defining an operation "Result foo(Tuppleware)" where
Tuppleware is a shortcut for {t1 a2, t2 a2, ...}. In fact, given that
most operations would be over just a subset of the attributes (e.g. a
tuple with StartingDate and EndingDate both of type Date might have a
Duration "method" which subtracts them), of what value is it to declare
the operator as having a declared domain which is a superset of the
actual domain?
I'm not criticizing, just asking and playing devil's advocate...
- erk
erk
> variable (assuming it has any mutable fields.)
Don't forget references, which are variables on which operations are
invoked. Operations are almost always delegated to the "valuable"
(value/variable) instance to which the reference points, of course.
> It is also always a conceptual entity. But this is such triviality
> that I've never seen anyone bother to mention it. No one is
> *confusing* values and variables; an object is both, and which
> one we are talking about is, most of time, immediately obvious.
I disagree. I think there's more confusion than you'd like to believe,
and furthermore that it's very easy, even for experienced programmers,
to unknowingly attempt to treat instances as both values and variables.
Look for "aliasing" on citeseer - this is a serious problem, and I've
run into it on many projects.
> There *is* an issue with the difference between equality and
> identity in OOP, but this is fairly easily mastered by beginners.
A moment to learn, a lifetime to master - if mastery is possible. This
is an ugly concept, of little value in my opinion. Perhaps caches and
other "manager" services can use this, but I think this is a hack.
> Yes, but this doesn't matter. There are specific models associated
> with each specific OOPL, and they are quite well documented
> down to the last detail. There are also substantial commonalities
> among the different models.
I agree, but I also think the models are weak to have allowed such
aliasing. For example, the Java new keyword makes a hard (and
unnecessary) distinction between value CREATION and value SELECTION (a
la Third Manifesto). Hence the frequent use of static methods to return
new (or shared) instances, factory patterns, etc. Yes, all that may be
admitted by the model, but that don't mean it's a good idea.
> > They know that to bundle operators with a single type is not a good
idea.
> The binary method issue? This is again a fairly unimportant issue.
Perhaps, but it leads to nonsense like double-dispatch and Visitor
patterns - more hacks around language failings. It forces an abritrary
choice that also limits builds, deployment, and configurations.
> Does they have methods specific to the specific join? I think
> that is what the guy was referring to. Ideally this would be
> done dynamically, not via code generation
If you generate proxies or class dynamically, based on the
most-specific type of the relational expression, then how can the
function be assigned to that combination, in the absence of a
predefined class name? I'm a little confused here...
- erk
Marshall Spight
>
> I disagree. I think there's more confusion than you'd like to believe,
> and furthermore that it's very easy, even for experienced programmers,
> to unknowingly attempt to treat instances as both values and variables.
> Look for "aliasing" on citeseer - this is a serious problem, and I've
> run into it on many projects.
I didn't say it didn't happen; I said it wasn't the huge problem it is
sometimes made out to be.
> > There *is* an issue with the difference between equality and
> > identity in OOP, but this is fairly easily mastered by beginners.
>
> A moment to learn, a lifetime to master - if mastery is possible. This
> is an ugly concept, of little value in my opinion. Perhaps caches and
> other "manager" services can use this, but I think this is a hack.
I generally agree that it's not a valuable concept, but this is a minority
opinion; lots of smart people think otherwise.
> > Does they have methods specific to the specific join? I think
> > that is what the guy was referring to. Ideally this would be
> > done dynamically, not via code generation
>
> If you generate proxies or class dynamically, based on the
> most-specific type of the relational expression, then how can the
> function be assigned to that combination, in the absence of a
> predefined class name? I'm a little confused here...
This was not in reference to any existing system; it was more
of an idea for the future.
Marshall
Jan Hidders
> "Jan Hidders" <jan.h...@REMOVETHIS.pandora.be> ...
>>Costin Cozianu wrote:
>>
>>>In The Third Manifesto, D&D affirm that 'tis a great blunder to equate
>>>"classes" with relations or with relation variables. Some people still
>>>believe that, although the riguorous proof of the drastic consequences
>>>supposed to follow is completely lacking.
>>>
>>>So here's a direct positive refutation, including with inheritance( well
>>>that maybe later, as it is orthogonal).
>
>>You are so right that it's almost boring. :-) If there had been any real
>>logical problems with letting relational variables play the role of types
>>then it would have not been possible or very difficult to come up with a
>>decent formal data model for that. It wasn't. QED
>
> Your observation is so profound that some may be uncertain if your are
> sarcastic or blunt.
Actually, I was trying to be both at once. :-) But you are right. I
probably shouldn't.
> Are you are referring to the model that allows an attribute to be of a
> relational type-domain ...
Not exactly. I'm referring to the model where if you have have a
relational variable Person you can then use "Person" as a type for your
columns. That's what it means to use relational variables as types.
-- Jan Hidders
Jan Hidders
> Jan Hidders wrote:
>
>> You are so right that it's almost boring. :-) If there had been any
>> real logical problems with letting relational variables play the role
>> of types then it would have not been possible or very difficult to
>> come up with a decent formal data model for that. It wasn't. QED
>
> Isn't Date's "first great blunder" to be seen more as a rule of thumb or
> a software engineering principle rather than as a formal mathematical
> truth?
Very well said. But (as Ja Lar already said) then Date should not claim
that there are logical problems but that there are engineering problems,
and he should not talk about logical arguments but about engineering
arguments.
> i.e. although it is possible to map classes from an object-oriented
> system onto relations in an RDBMS in certain circumstances, as a general
> rule it's best avoided?
Now you make it sound as a design-rule for designing your relational
schema, but that's not really what it is about. It is about what the
meta-model of the logical model of your DBMS should be, i.e., if you
want to build a new type of DBMS and replace the relational model with
another type of data model then what should that model look like?
Does that make sense to you?
-- Jan Hidders
Jan Hidders
>
> It's long bugged me that the relational algebra has such seemingly
> non-algebraic things in it as restrict and project.
Could you explain that a little? What do you mean by non-algebraic? And
why does that bother you? Do you think we can achieve the same with more
algebraic operators? Did you have any in mind? Could Tarski's
cylindrical algebras be what you are looking for?
-- Jan Hidders
Ja Lar
"Jan Hidders" ...
> Ja Lar wrote:
<snip>
>> Are you are referring to the model that allows an attribute to be of a
>> relational type-domain ...
>
> Not exactly. I'm referring to the model where if you have have a
> relational variable Person you can then use "Person" as a type for your
> columns. That's what it means to use relational variables as types.
In fact, that whas exactly what I ment by "an attribute of a relational type
domain".
(column type = domain)
Ja Lar
"Alfredo Novoa" <alf...@ncs.es> ...
<snip>
Re-reading:
> An User class can't map to an User relation because it is an absurd to
> map types to variables or values (Date's 1stGB).
>
> An unidimensional collection of User objects maps to an User relation.
> This is perfectly possible and it is not a great blunder.
What is the distinction between "User class" and "unidimensional collection
of User objects" that makes the first a blunder, and the second not?
What IS an user class in your definition? What is an unidimensional
collection? - a kind of "set of users", that is objects of the same kind?
Alfredo Novoa
>> An User class can't map to an User relation because it is an absurd to
>> map types to variables or values (Date's 1stGB).
>>
>> An unidimensional collection of User objects maps to an User relation.
>> This is perfectly possible and it is not a great blunder.
>
>What is the distinction between "User class" and "unidimensional collection
>of User objects"
A class is a type, an object's collection is a value or a variable.
> that makes the first a blunder
To mix types with values or variables.
>, and the second not?
To map values to values and variables to variables.
>What IS an user class in your definition?
A type.
> What is an unidimensional
>collection? - a kind of "set of users"
A kind of list of user values.
>, that is objects of the same kind?
Not necessarily. Thy might be of different kinds.
Regards
Ja Lar
<snip - various that might be commented later ...>
> >What is the distinction between "User class" and "unidimensional
collection
> >of User objects" that makes the first a blunder and the second not?
> To mix types with values or variables.
This is a circular argument (or less: just a refrasing, definition - not a
logical conclusion):
"Why is it a great blunder to equate class with relvar"
"Because it is a great blunder to mix type with value or variable". And
"type = class"
Try again: _Why_ is it a great blunder to "mix types with values"? The
answer "that's obvious" is of no (logical) value - that's the hole point in
the paper this thread discusses.
As you know, a type is (amongst other things) a set (or a list, if you like)
of values. Likewise, a class is (amongst other things) a set (or a list, if
you like) of objects.
You allow a set of objects to map (as a non-BG) to a relation.
Why and how can an atrribute of a relation have another relation as its
domain without thus mixing type with values? (type = domain)
Is the clue that "class <> relvar", but "class = relation value"?
If you just are repeating D&D's words from TTM, you add nothing to the
discussion.
Alfredo Novoa
>"Why is it a great blunder to equate class with relvar"
>"Because it is a great blunder to mix type with value or variable". And
>"type = class"
Indeed, the first statement is not clear for many people but
type=variable is an evident blunder for anybody who knows what type
and variable are.
>Try again: _Why_ is it a great blunder to "mix types with values"? The
>answer "that's obvious" is of no (logical) value - that's the hole point in
>the paper this thread discusses.
If you don't know what types, variables and values are, that is your
problem.
Regards
Ja Lar
"Alfredo Novoa" <alf...@ncs.es>...
> On Mon, 22 Nov 2004 15:33:16 +0100, "Ja Lar" <ja...@nomail.com> wrote:
>
> >"Why is it a great blunder to equate class with relvar"
> >"Because it is a great blunder to mix type with value or variable". And
> >"type = class"
>
> Indeed, the first statement is not clear for many people but
> type=variable is an evident blunder for anybody who knows what type
> and variable are.
If you say so.
> >Try again: _Why_ is it a great blunder to "mix types with values"? The
> >answer "that's obvious" is of no (logical) value - that's the hole point
in
> >the paper this thread discusses.
>
> If you don't know what types, variables and values are, that is your
> problem.
You are not very helpful: If I don't know the answer to my question, I
shouldn't ask it?
Once again: On one hand you say that it is a great blunder to "map a class
to a relvar" , and on the other hand you say that it is not a great blunder
to "map a list of values to a relation". Why?
And once again: Why and how can an atrribute of a relation have another
relation as its domain without thus mixing type with values? (type =
domain)?
Btw, the original topic of this thread is not whether there is one or two
great blunders or not, but if Mr. Gittens arguments against D&D's
conclusions are valid, ie. that they give no logical foundation for the
conclusion about 1GB and 2GB.
My wish was (is) that you either identify Mr. Gittens blunder, or identify
the logical foundation for the conclusion.
Costin Cozianu
> "Alfredo Novoa" <alf...@ncs.es>...
>
>>On Mon, 22 Nov 2004 15:33:16 +0100, "Ja Lar" <ja...@nomail.com> wrote:
>>
>>
>>>"Why is it a great blunder to equate class with relvar"
>>>"Because it is a great blunder to mix type with value or variable". And
>>>"type = class"
>>
>>Indeed, the first statement is not clear for many people but
>>type=variable is an evident blunder for anybody who knows what type
>>and variable are.
>
>
> If you say so.
>
>
>>>Try again: _Why_ is it a great blunder to "mix types with values"? The
>>>answer "that's obvious" is of no (logical) value - that's the hole point
>
> in
>
>>>the paper this thread discusses.
>>
>>If you don't know what types, variables and values are, that is your
>>problem.
>
>
> You are not very helpful: If I don't know the answer to my question, I
> shouldn't ask it?
Actually don't ask the trolls. The otherwise knowledgeable Alfredo, when
he goes on the defensive about the one true relational orthodoxy, he's
in the trolling mode.
So don't ask him to provide a summary definition for a variable, because
he has none. Such a definition would require formal (mathematical)
semantics for the model he is defending. And there is none yet.
Only after we established there was some formal model, we can discuss
about the adequacy of approach.
But to answer your question: in Date's sketch of a model called the
third manifesto, a type is a name that denotes a "set of values". The
difference between the type's denoted set of values and the set of
values denoted by a "relvar" (aka table in common speak) is that the
later is time varying while the former is fixed in the abstract. The
next step is to consider the mapping between the name of the type and
the set of all values of that type ( therefore the subset of the fixed
immutable set) that are instantiated within the database (i.e. stored in
a column, in a row, or in a whole table somewhere in the database. And
the later is a time varying set that can just be as easily thought as a
relvar, because maps a name (the name of the type) to a time varying set.
Depending on the circumstances of the design needs, the schema can make
this mapping explicit, like in the example I presented from User type to
the Users table, and there's *absolutely nothing wrong with that*. As
Jan Hidders observed is so obvious that it's boring.
*Presumably* what Date can justifiably criticize is that some OO
designers, some OO book authors and some O/R mapping products, do this
mapping on auto-pilot. That is, for every object-type identified in
their OO analysis (or corresponding loosely to every entity type in an
ERD schema), they automatically make explicit the set of all instances
by consecrating it with a table.
In some cases this auto-pilot relational schema design may result in
less than perfect schema. So if you like the "recipe style" auto-pilot
generation of relational tables from an OO class diagram can be
considered an objectionable approach. Although empirically it has not
been shown to result in the catastrophes associated with a "great
blunder". That does not mean that by applying the transformation (making
the mapping explicit from "object type" to a real table) with on a case
by case basis is to be considered a great bundle.
Hope this clarifies your questions. I could come back if there's
interest and if I have some time, with what can go wrong when going
auto-pilot about this, how likely it is that things can go wrong, and
how wrong is wrong (how bad are the consequences of having a less than
perfect schema).
Costin
Ja Lar
"Costin Cozianu" <c_co...@hotmail.com>...
<snip>
>
<snip troll-warning>
> Only after we established there was some formal model, we can discuss
> about the adequacy of approach.
> But to answer your question...
<answer snipped>
Thank you for your effort to answer my question.
I'm sorry that I posed it in a way that gives the impression that an account
on D&D's position is requested.
I did in fact already know and "understand" what Dates position is (and your
presentation is very good), but my objective was to get Alfredo et al to
give their OWN opinion, as does Mr. Gittens, to D&D's "logical
conclusions" - eg. establish some formel basis for understanding the GB's
(as D&D gives none).
I think I completely share yours and Jan Hidders views on the matter.
Alfredo Novoa
<c_co...@hotmail.com> wrote:
>So don't ask him to provide a summary definition for a variable, because
>he has none.
Of course I have a definition for a variable. I posted it many times:
Variable: a holder or a container for a value. The value placed in
variable may change over the time. To say a variable holds a value
means that an encoded representation of a value is contained in the
variable.
> Such a definition would require formal (mathematical)
>semantics for the model he is defending. And there is none yet.
You always use the same trick to dismiss anything you want, but you
never offer any argument nor any alternative definition.
I checked the books you recomended and I have not found any decent
definition of type, variable, value or operator.
BTW I am not defending any model here. I am only saying that types and
variables are fundamentally different. This should be out of question.
>But to answer your question: in Date's sketch of a model called the
>third manifesto, a type is a name that denotes a "set of values".
Wrong, according to Date a type is a NAMED set of values with their
associate operators.
BTW I disagree with Date about that a type always have a name.
> The
>difference between the type's denoted set of values and the set of
>values denoted by a "relvar" (aka table in common speak) is that the
>later is time varying while the former is fixed in the abstract.
A relvar holds a single relation value, and the type's denoted set of
values might be any set of values: scalars, matrices, vectors, etc, or
even any combination of scalar and non scalar values.
> The
>next step is to consider the mapping between the name of the type
But you said that a type is a name. Another inconsistency.
> and
>the set of all values of that type ( therefore the subset of the fixed
>immutable set)
The relation value holded in the relvar is a subset of the set of all
relation values. Let's see where you want to go with this chain of
incoherences.
> that are instantiated within the database (i.e. stored in
>a column, in a row, or in a whole table somewhere in the database.
Now you are completely lost. This is surrealist, you are interchanging
the relational type of a relvar and the types of the attributes.
> And
>the later is a time varying set that can just be as easily thought as a
>relvar, because maps a name (the name of the type) to a time varying set.
In a short: What you are trying to say is that we can hold all the
values of a type in a relvar.
Of course!
For instance if we define a type constituted by the natural numbers
which are less than 10 and the appliable operators, we can create a
table of integers and to store those numbers on it.
So what?
What a waste of time!
This is of course very different to: types and variables don't have
any fundamental difference, which is the essence of 1GB.
>Depending on the circumstances of the design needs, the schema can make
>this mapping explicit, like in the example I presented from User type to
>the Users table
It that example you were mapping a collection of User typed objects to
an Users table.
>, and there's *absolutely nothing wrong with that*. As
I prefer to map a variable of class RelVar to the Users table.
Regards
Alfredo Novoa
>> Indeed, the first statement is not clear for many people but
>> type=variable is an evident blunder for anybody who knows what type
>> and variable are.
>
>If you say so.
You only have to compare both definitions.
>> >Try again: _Why_ is it a great blunder to "mix types with values"? The
>> >answer "that's obvious" is of no (logical) value - that's the hole point
>in
>> >the paper this thread discusses.
>>
>> If you don't know what types, variables and values are, that is your
>> problem.
>
>You are not very helpful: If I don't know the answer to my question, I
>shouldn't ask it?
You know the answer: because they are fundamentally different.
What you don't know is what types and variables really are, and that's
why you don't see the obvious differences.
I recomend you Date's $$$ article called "On Logical Differences" or
something similar. 72 pages 10$.
And yes you can ask what types, variables and values are.
Type: AKA abstract data type:
http://www.nist.gov/dads/HTML/abstractDataType.html
Variable: a holder or a container for a value. The value placed in
variable may change over the time. To say a variable holds a value
means that an encoded representation of a value is contained in the
variable.
Value: an individual constant, any particular determination. Values
have no location in time or space.
Determination: The ascertaining or fixing of the quantity, quality,
position, or character of something: a determination of the ship's
longitude; a determination of the mass of the universe.
http://dictionary.reference.com/search?q=determination
BTW, thanks to you I have a better definition of value than I had :)
A value is a determination.
>Once again: On one hand you say that it is a great blunder to "map a class
>to a relvar" , and on the other hand you say that it is not a great blunder
>to "map a list of values to a relation". Why?
Once again: because a list of values is a value and a relation is a
value. Both are objects (not in the OO sense) of the same kind. And
because types and variables are fundamentally different: variables are
updateable, types aren't, variables do have location in time and
space, classes don't.
>And once again: Why and how can an atrribute of a relation have another
>relation as its domain without thus mixing type with values? (type =
>domain)?
An attribute of a relation can not have another relation as its
domain. This is an absurd.
>Btw, the original topic of this thread is not whether there is one or two
>great blunders or not, but if Mr. Gittens arguments against D&D's
>conclusions are valid, ie. that they give no logical foundation for the
>conclusion about 1GB and 2GB.
Gittens is wrong because the conclusion is perfectly founded: the
definition of type does not match with the definitions of variable and
value, and the definition of relational domain matches perfectly with
the definition of type, they are the same thing with two different
names, they are synonyms like reply and response.
Regards
Costin Cozianu
> On Tue, 23 Nov 2004 10:40:02 -0800, Costin Cozianu
> <c_co...@hotmail.com> wrote:
>
>
>>So don't ask him to provide a summary definition for a variable, because
>>he has none.
>
>
> Of course I have a definition for a variable. I posted it many times:
>
> Variable: a holder or a container for a value. The value placed in
> variable may change over the time. To say a variable holds a value
> means that an encoded representation of a value is contained in the
> variable.
>
Incorrect definition. It doesn't apply to most programming languages in
existence.
>
>>Such a definition would require formal (mathematical)
>>semantics for the model he is defending. And there is none yet.
>
>
> You always use the same trick to dismiss anything you want, but you
> never offer any argument nor any alternative definition.
>
Just read any formally defined programming language. You'll find it
there, no need to repeat it. For some languages those are called
identifier and they are associated with an
* evaluation context *
Typically such identifiers are not allowed to escape the evaluation
context. But in order to discuss the evaluation context you need some
kind of formal semantics, either operational or denotational or axiomatic.
> I checked the books you recomended and I have not found any decent
> definition of type, variable, value or operator.
>
Well, because an operator is just a fancy name for a function.
Can you tell me in what books you did not find a definition for the above ?
> BTW I am not defending any model here. I am only saying that types and
> variables are fundamentally different. This should be out of question.
>
But that's trivia. And that's not what at stake here.
>
>>But to answer your question: in Date's sketch of a model called the
>>third manifesto, a type is a name that denotes a "set of values".
>
>
> Wrong, according to Date a type is a NAMED set of values with their
> associate operators.
>
I.E. a "name that denotes a set of values" and a "named set of values".
Big difference.
> BTW I disagree with Date about that a type always have a name.
>
If types do not have explicit names provided by the programmer, you can
always assigned them a default name such as
int [] -> "int[]"
or
(int->int) -> "int->int"
big deal.
>
>>The
>>difference between the type's denoted set of values and the set of
>>values denoted by a "relvar" (aka table in common speak) is that the
>>later is time varying while the former is fixed in the abstract.
>
>
> A relvar holds a single relation value, and the type's denoted set of
> values might be any set of values: scalars, matrices, vectors, etc, or
> even any combination of scalar and non scalar values.
>
>
Alfredo, I have news for you: every relation is a set and every set is a
relation. Of course, I am talking here about the unnamed perspective of
relational algebra as documented in the Alice book, and as documented in
all standard mathematical books on set theory and logic.
if you want to further troll this point I'll provide a full mathematical
account for switching between the named and unnamed perspective.
>>The
>>next step is to consider the mapping between the name of the type
>
>
> But you said that a type is a name. Another inconsistency.
>
Every type having an unique name there's no danger of confusion.
>
>>and
>>the set of all values of that type ( therefore the subset of the fixed
>>immutable set)
>
>
> The relation value holded in the relvar is a subset of the set of all
> relation values. Let's see where you want to go with this chain of
> incoherences.
>
>
>>that are instantiated within the database (i.e. stored in
>>a column, in a row, or in a whole table somewhere in the database.
>
>
> Now you are completely lost. This is surrealist, you are interchanging
> the relational type of a relvar and the types of the attributes.
>
No, you have a problem following. According to Date there will be three
distinct "kinds" of values. There will be "atomic" values and obviously
these cannot be stored in a relvar, but each instance can be stored in a
particular attribute of a particular row of a particular relation.
There also tuple values: instances of a tuple type. Those again cannot
be stored in a relvar, but can be seen either as the value of a row in a
particular relvar, or the value iof an attribute in a particular row
(since attributes can store any kind of type -- ioncluding relation itself)
And then there are relation values that can be stored in a relvar, and
can be stored in a particular attribute of a particular row.
>
>>And
>>the later is a time varying set that can just be as easily thought as a
>>relvar, because maps a name (the name of the type) to a time varying set.
>
>
> In a short: What you are trying to say is that we can hold all the
> values of a type in a relvar.
>
> Of course!
>
> For instance if we define a type constituted by the natural numbers
> which are less than 10 and the appliable operators, we can create a
> table of integers and to store those numbers on it.
>
Yes, actually you can do that. If you read Functional Pearls you'll
learn how infinite sets can be represented by generators.
> So what?
>
> What a waste of time!
>
> This is of course very different to: types and variables don't have
> any fundamental difference, which is the essence of 1GB.
>
>
No, that would not be the essence of 1Gb, that would be the essence of a
Red Herring.
Since nobody, not even the authors alluded to by D&D claimed such a
feat, it would be a waste of our time to further discuss red herrings.
>>Depending on the circumstances of the design needs, the schema can make
>>this mapping explicit, like in the example I presented from User type to
>>the Users table
>
>
> It that example you were mapping a collection of User typed objects to
> an Users table.
>
Anything wrong with that ?
You handwaved quite a bit, now can you explain your point ?
>
>>, and there's *absolutely nothing wrong with that*. As
>
>
> I prefer to map a variable of class RelVar to the Users table.
>
A variable which you just do not have.
>
>
> Regards
Cheers,
Costin
Gene Wirchenko
[snip]
>conclusions" - eg. establish some formel basis for understanding the GB's
>(as D&D gives none).
Why not ask him (Date)? You can reach him through the
dbdebunk.com Website.
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Ja Lar
"Gene Wirchenko" <ge...@mail.ocis.net> skrev i en meddelelse
news:lt67q0pokl855h84h...@4ax.com...
> "Ja Lar" <in...@mail.her> wrote:
>
> [snip]
>
> >conclusions" - eg. establish some formel basis for understanding the GB's
> >(as D&D gives none).
>
> Why not ask him (Date)? You can reach him through the
> dbdebunk.com Website.
I'm sure you can imagine the answer you get there. I know it!
Ja Lar
"Alfredo Novoa" <ano...@ncs.es> ...
<snip>
> I recomend you Date's $$$ article called "On Logical Differences" or
> something similar. 72 pages 10$.
Know about already.
<snip>
> An attribute of a relation can not have another relation as its
> domain. This is an absurd.
I recommend you Date's Intro ...(8th ed), Part II/The Relational Model p.
152: Relation-Valued Attributes.
You might want to inform him about the absurdity :-)
Gene Wirchenko
Alfredo Novoa
>> An attribute of a relation can not have another relation as its
>> domain. This is an absurd.
>
>I recommend you Date's Intro ...(8th ed), Part II/The Relational Model p.
>152: Relation-Valued Attributes.
>You might want to inform him about the absurdity :-)
No, you are missing the point. Relation valued attributes don't have a
relation value as their type (domain), they have a relation type as
their type.
For instance:
var CandidateKeys real relation { RelVar Char, Attributes relation {
Attribute Char } } key { RelVar, Attributes };
Here "relation { Attribute Char }" is a relation type generator that
generates a relation type for the "Attributes" attribute.
Regards
Ja Lar
"Alfredo Novoa" <alf...@ncs.es> skrev i en meddelelse
news:41a4bcf4...@news.wanadoo.es...
> On Wed, 24 Nov 2004 16:26:18 +0100, "Ja Lar" <in...@mail.her> wrote:
>
>>> An attribute of a relation can not have another relation as its
>>> domain. This is an absurd.
>>
>>I recommend you Date's Intro ...(8th ed), Part II/The Relational Model p.
>>152: Relation-Valued Attributes.
>>You might want to inform him about the absurdity :-)
>
> No, you are missing the point. Relation valued attributes don't have a
> relation value as their type (domain), they have a relation type as
> their type.
OK, I acknowledge that.
So the set of values specified by the type is (in this case) a set of
relations.
But the set of values that a relation is ("contains") cannot be mapped to
the set of values that a type is ("contains"), ie. "a relation cannot be a
type", if I understand you right ?
Alfredo Novoa
>So the set of values specified by the type is (in this case) a set of
>relations.
Indeed.
>But the set of values that a relation is ("contains") cannot be mapped to
>the set of values that a type is ("contains")
They can be mapped but then you are not mapping a relation to a type,
you are mapping the values contained in the tuples of a relation to
the values of a type. This is a value to value mapping.
>, ie. "a relation cannot be a
>type", if I understand you right ?
This is true, but this is not the same as you said above.
Regards.
Alfredo Novoa
<Rene_de...@hotmail.com> wrote:
>> This is true, but this is not the same as you said above.
>In the relational programming language AP5, a type is simply a relation of
>arity 1.
Then it is a poorly designed language.
Regards
Ja Lar
"Alfredo Novoa" <ano...@ncs.es> skrev i en meddelelse
news:qbv9q0trk6nrno44a...@4ax.com...
We have now reached the realm of good and bad by definition (ie. opinion or
religion), not by argument or deduction.
Isn't that where this thread started?
Jan Hidders
Just out of curiosity, Leandro, are you seriously contending that DBMSs
that treat relational variables as types are making a fundamental
mistake because by definition relational variables and types are
distinct in the sense that something cannot be both at the same time?
I simply cannot believe that you do not see what is problematic about
this type of argument. Seriously.
-- Jan Hidders
Rene de Visser
news:qbv9q0trk6nrno44a...@4ax.com...
Could you expand on why you believe that was a poor design decision?
I haven't noticed any practical or theoritical problems associated with
implementing types as relations of arity 1.
It has the advantage that unified constraint handling can be made over types
and relations.
Subtyping and subcategorization also fits together cleanly with the unified
constraint handling.
Rene.
Alfredo Novoa
>
>"Alfredo Novoa" <alf...@ncs.es> ...
>
>>>But the set of values that a relation is ("contains") cannot be mapped to
>>>the set of values that a type is ("contains")
>>
>> They can be mapped but then you are not mapping a relation to a type,
>> you are mapping the values contained in the tuples of a relation to
>> the values of a type. This is a value to value mapping.
>
>A "value to value mapping" in contrast to ...?
A bacon to velocity mapping.
>By what measure is that not a mapping from the relation (the set of values)
>to the type (the set of values) ?
By all measures. A relation is not a set of values it is a single
value.
To map the values contained in the tuples of a relation to a type
could be something like this:
type dumb possrep {integer} constraint dumb between 0 and 9;
relation {
tuple { a 0, b 1, c 2, d 3, e 4 },
tuple { a 5, b 6, c 7, d 8, e 9 },
tuple { a 5, b 2, c 4, d 4, e 7 },
tuple { a 1, b 2, c 0, d 1, e 9 }
}
There is a correspondence between the values contained in the tuples
of the relation and the values specified by the type, but this is a
completely stupid and useless mapping.
But again, there is not a mapping between the type and the relation.
Regards
Leandro Guimarães Faria Corsetti Dutra
> Just out of curiosity, Leandro, are you seriously contending that
Not me you're replying to.
--
Leandro Guimarães Faria Corcete Dutra <lea...@dutra.fastmail.fm>
Maringá, PR, BRASIL +55 (44) 3025 6253
http://br.geocities.com./lgcdutra/ +55 (44) 8803 1729
Soli Deo Gloria! +55 (11) 9406 7191
Ja Lar
"Alfredo Novoa" <ano...@ncs.es> ...
> A relation is not a set of values ...
You can have it that way. Meanwhile, I'll move on to more meaningful issues
...
Rene de Visser
news:41a4e1b0...@news.wanadoo.es...
>>, ie. "a relation cannot be a
>>type", if I understand you right ?
>
> This is true, but this is not the same as you said above.
arity 1.
Rene.
Ja Lar
"Alfredo Novoa" <alf...@ncs.es> ...
>>But the set of values that a relation is ("contains") cannot be mapped to
>>the set of values that a type is ("contains")
>
> They can be mapped but then you are not mapping a relation to a type,
> you are mapping the values contained in the tuples of a relation to
> the values of a type. This is a value to value mapping.
A "value to value mapping" in contrast to ...?
By what measure is that not a mapping from the relation (the set of values)
to the type (the set of values) ?
I presume that we agree that a relation is a subset of the product set of
the domains, and that the tuples are the elements in this set.
>>, ie. "a relation cannot be a
>>type", if I understand you right ?
>
> This is true, but this is not the same as you said above.
By what measure does this equivalence not follow from the mapping?
Jan Hidders
>
> Just out of curiosity, Leandro, are you seriously contending that DBMSs
> that treat relational variables as types are making a fundamental
> mistake because by definition relational variables and types are
> distinct in the sense that something cannot be both at the same time?
Ahem. I meant Alfredo of course. Sorry about that.
-- Jan Hidders
Alfredo Novoa
>> Then it is a poorly designed language.
>
>We have now reached the realm of good and bad by definition
Rene shooted first.
Regards
Alfredo Novoa
Good idea.
Regards
Alfredo Novoa
<jan.h...@REMOVETHIS.pandora.be> wrote:
>are you seriously contending that DBMSs
>that treat relational variables as types are making a fundamental
>mistake because by definition relational variables and types are
>distinct in the sense that something cannot be both at the same time?
Indeed, well expressed.
Date and Darven cover the problems of such fundamental mistake in
chapter 2 of TTM (page 22).
>I simply cannot believe that you do not see what is problematic about
>this type of argument. Seriously.
So what is problematic?
It's well known that the DBMSs that tried to treat relational
variables as types were a fiasco. The problems derived from such
fundamental mistake helped a lot.
Regards
Rene de Visser
news:41a5e2e4...@news.wanadoo.es...
> It's well known that the DBMSs that tried to treat relational
> variables as types were a fiasco. The problems derived from such
> fundamental mistake helped a lot.
>
Otherwise this would lead directly to algebraic types,
which would break the required uniformity of tuples within a relation.
I also presume that such DBMS languages only supported global relational
variables?
In fact I don't see how this could work for n-ary relations (where n <> 1)
in the presence of contraints as this would again could lead to the type
being algebraic.
(algebraic types in the sense of types defined by an algebraic constraint
of more than one variable).
Rene.
Alfredo Novoa
<Rene_de...@hotmail.de> wrote:
>> It's well known that the DBMSs that tried to treat relational
>> variables as types were a fiasco. The problems derived from such
>> fundamental mistake helped a lot.
>>
>I presume though, not for algebraically defined n-ary relations (n <> 1)?
I don't understand you. What do you mean with algebraically defined
relations?
Something like this?:
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?discriminated+union
>Otherwise this would lead directly to algebraic types,
>which would break the required uniformity of tuples within a relation.
I don't understand you, but if we treat to use relvars as types then
we would break the Relational Model and we would not have relations at
all.
See TTM page 28.
>I also presume that such DBMS languages only supported global relational
>variables?
I don't see the reason for such presumption.
Regards
Rene de Visser
> On Thu, 25 Nov 2004 16:43:49 +0100, "Rene de Visser"
> <Rene_de...@hotmail.de> wrote:
>
> >> It's well known that the DBMSs that tried to treat relational
> >> variables as types were a fiasco. The problems derived from such
> >> fundamental mistake helped a lot.
> >>
> >I presume though, not for algebraically defined n-ary relations (n <> 1)?
>
> I don't understand you. What do you mean with algebraically defined
> relations?
>
> Something like this?:
>
> http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?discriminated+union
No. I mean for example the relation integer-binary-plus
defined by the set of tuples
(x y z) s.t. x + y = z for all x, y, z that are integers.
i.e. this is a relation with an infinite number of tuples.
i.e. the tuples of the relation are defined algebracially as opposed to
being stored.
As such the example is a constant relation. The tuples do not change with
time.
a very simple example of an algebraically defined relation is 'Integer'
consisting of the tuples (1-tuples in this case)
(x) s.t. x is an integer.
>
> >Otherwise this would lead directly to algebraic types,
> >which would break the required uniformity of tuples within a relation.
>
> I don't understand you, but if we treat to use relvars as types then
> we would break the Relational Model and we would not have relations at
> all.
>
> See TTM page 28.
>
> >I also presume that such DBMS languages only supported global relational
> >variables?
>
> I don't see the reason for such presumption.
>
If we base types on relational variables in a language that supports lexical
relation variables, then this leads to lexical types.
i.e. type that would only be valid in the lexical closure of the variable.
This doesn't seem very usefull in a 'normal' relational
language which generally works with global constraints.
Over the previous few years there has been however work with langauges that
support 1st class relations, and then I guess 1st class types would make
sense as well. But as you were talking about previous DBMS systems, I guess
these were before the idea of 1st class relations.
Rene.
Alfredo Novoa
<Rene_de...@hotmail.com> wrote:
>"Alfredo Novoa" <ano...@ncs.es> schrieb im Newsbeitrag
>news:qbv9q0trk6nrno44a...@4ax.com...
>> On Wed, 24 Nov 2004 21:32:58 +0100, "Rene de Visser"
>> <Rene_de...@hotmail.com> wrote:
>>>> This is true, but this is not the same as you said above.
>>>In the relational programming language AP5, a type is simply a relation of
>>>arity 1.
>>
>> Then it is a poorly designed language.
>
>Could you expand on why you believe that was a poor design decision?
Well, I shooted too fast.
I supose that in AP5 a type is DESCRIBED by a 1-ary relation value
(but not a relation variable).
The problem is how to describe such relation value and how to define
the operators of the type.
A relation is not a type but the set of values of a type can be viewed
as a 1-ary relation value.
Regards
Rene de Visser
> On Wed, 24 Nov 2004 23:03:50 +0100, "Rene de Visser"
> <Rene_de...@hotmail.com> wrote:
>
>>"Alfredo Novoa" <ano...@ncs.es> schrieb im Newsbeitrag
>>news:qbv9q0trk6nrno44a...@4ax.com...
>>> On Wed, 24 Nov 2004 21:32:58 +0100, "Rene de Visser"
>>> <Rene_de...@hotmail.com> wrote:
>>>>> This is true, but this is not the same as you said above.
>>>>In the relational programming language AP5, a type is simply a relation
>>>>of
>>>>arity 1.
>>>
>>> Then it is a poorly designed language.
>>
>>Could you expand on why you believe that was a poor design decision?
>
> Well, I shooted too fast.
>
> I supose that in AP5 a type is DESCRIBED by a 1-ary relation value
> (but not a relation variable).
paper), and not by name as in his second paper. i.e. there are no globally
valid relational variables. All relational variables are local to form that
uses them.
>
> The problem is how to describe such relation value and how to define
> the operators of the type.
The relation value is often described algebraically using a modal logic
extended with quanfiers and relations.
(Relations are of two basic types in AP5, defined or stored).
In AP5 operaters are also relations.
See my other posting for how a plus operator can be defined relationally.
AP5 is mainly declarative with add and delete to add and remove tuples from
stored relations.
The rest is done with triggers and relations, and functions when the
relationally defined ones aren't enough.
>
> A relation is not a type but the set of values of a type can be viewed
> as a 1-ary relation value.
i.e.
values of a type <=> 1-ary relation value
type <=> relation / relation definition / relation name
in AP5 relations are second class objects. i.e. there is a 1-1 relationship
between relation / relation defintion and relation name.
Jan Hidders
> On Wed, 24 Nov 2004 21:06:40 GMT, Jan Hidders
> <jan.h...@REMOVETHIS.pandora.be> wrote:
>
>
>>are you seriously contending that DBMSs
>>that treat relational variables as types are making a fundamental
>>mistake because by definition relational variables and types are
>>distinct in the sense that something cannot be both at the same time?
>
> Indeed, well expressed.
Thank you.
>>I simply cannot believe that you do not see what is problematic about
>>this type of argument. Seriously.
>
> So what is problematic?
It's irrelevant. The question that must be answered is whether there are
any practical problems if you redefine the notion of type such that it
does include relational variables. That the original definition didn't
is neither here nor there.
> It's well known that the DBMSs that tried to treat relational
> variables as types were a fiasco.
It is also well known that these were not technical problems.
-- Jan Hidders
Alfredo Novoa
<jan.h...@REMOVETHIS.pandora.be> wrote:
>>>I simply cannot believe that you do not see what is problematic about
>>>this type of argument. Seriously.
>>
>> So what is problematic?
>
>It's irrelevant.
Then I can continue to think the same without worry :)
>The question that must be answered is whether there are
>any practical problems if you redefine the notion of type such that it
>does include relational variables.
The practical problems exist. I supose that you have readen the
section of TTM that describes some of these practical problems, like a
return to chasing pointers.
>> It's well known that the DBMSs that tried to treat relational
>> variables as types were a fiasco.
>
>It is also well known that these were not technical problems.
Indeed, these were model problems :)
Although most OO coders think that the OODBMS technology is immature
(technical problems).
BTW, currently we can say that XML-DBMSs were the next big fiasco.
Even M$ is following (more or less) the equation class=domain in the
new SQL Server.
Regards
Jan Hidders
> On Thu, 25 Nov 2004 21:32:50 GMT, Jan Hidders
> <jan.h...@REMOVETHIS.pandora.be> wrote:
>
>
>>>>I simply cannot believe that you do not see what is problematic about
>>>>this type of argument. Seriously.
>>>
>>>So what is problematic?
>>
>>It's irrelevant.
>
> Then I can continue to think the same without worry :)
Sure. If you are not worried by incorrect arguments....
>>The question that must be answered is whether there are
>>any practical problems if you redefine the notion of type such that it
>>does include relational variables.
>
> The practical problems exist. I supose that you have readen the
> section of TTM that describes some of these practical problems, like a
> return to chasing pointers.
Yes, and as anybody who has actually done some research on OODBMSs knows
that is blatant nonsense.
>>>It's well known that the DBMSs that tried to treat relational
>>>variables as types were a fiasco.
>>
>>It is also well known that these were not technical problems.
>
> Indeed, these were model problems :)
Nope. There were also no model problems.
-- Jan Hidders
Leandro Guimarães Faria Corsetti Dutra
> Even M$ is following (more or less) the equation class=domain in the new
> SQL Server.
Really? Do you have any details?
I have interestingly found that currently MS SQL Server
practitioners I've had contact with are more conceptually sound than
Oracle ones. Would like to know why, your information may point to
MS's approach being at least slightly saner than Oracle's.
Leandro Guimarães Faria Corsetti Dutra
> Jan Hidders wrote:
>>
>> Just out of curiosity, Leandro, are you seriously contending that DBMSs
>
> Ahem. I meant Alfredo of course. Sorry about that.
I feel honoured by your confusion, just hope Alfredo didn't
feel too diminished by it!
Dawn M. Wolthuis
news:AJ6pd.34550$0d1.1...@phobos.telenet-ops.be...
I'm trying to catch up and thought perhaps someone could answer these two
questions --
1) Has anyone provided any better logic related to the 1GB than that
provided by Date? If not, I would think we could talk about this as
intuition or hypothesis that there is a mistake rather than anything
resembling a proof, right?
2) Has anyone given a good refutation that there is no Great Blunder other
than to attack the lack of logic in the defense of the 1GB?
Thanks in advance for helping me catch up. Cheers! --dawn
Jan Hidders
>
> I'm trying to catch up and thought perhaps someone could answer these two
> questions --
>
> 1) Has anyone provided any better logic related to the 1GB than that
> provided by Date? If not, I would think we could talk about this as
> intuition or hypothesis that there is a mistake rather than anything
> resembling a proof, right?
Not that I know of.
> 2) Has anyone given a good refutation that there is no Great Blunder other
> than to attack the lack of logic in the defense of the 1GB?
From a scientific point the situation is actually very simple. The
hypothetis predicts that you run into certain problems when you build
DBMSs that are based on this principle. However, such databases have
been built and the problems weren't there. Hypothesis falsified. End of
story.
-- Jan Hidders
Ja Lar
"Dawn M. Wolthuis" <dw...@tincat-group.comREMOVE> ...
<snip>
>
> I'm trying to catch up and thought perhaps someone could answer these two
> questions --
>
> 1) Has anyone provided any better logic related to the 1GB than that
> provided by Date? If not, I would think we could talk about this as
> intuition or hypothesis that there is a mistake rather than anything
> resembling a proof, right?
Right! The term "Great blunder" is in it self a sign of "opinion",
"feeling", "intuition" more than of a scientific fact.
It would be careless to use the terms "wrong" or "right", and D&D probably
knows that.
The "proof" follows to some extend a logical deduction; however the premises
are uncertain at best, and probably even wrong.
D&D _defines_ the terms in such a way that their conclusions thereby are
given a priori, IMO.
The conclusion cannot be better than the premises, regardles of the logical
deduction.
I think this is Mr. Gittens main point.
> 2) Has anyone given a good refutation that there is no Great Blunder other
> than to attack the lack of logic in the defense of the 1GB?
It is a fact that systems with 1GB is in use without any problems related to
1GB.
But we must remember that D&Ds TTM really is about an "extension" to RDBMS,
and does not apply to RDBMS's as known.
So any real system has no alternative to committing 1GB anyway (perhaps
except Alphora...).
Alfredo Novoa
<jan.h...@REMOVETHIS.pandora.be> wrote:
> From a scientific point the situation is actually very simple. The
>hypothetis predicts that you run into certain problems when you build
>DBMSs that are based on this principle. However, such databases have
>been built and the problems weren't there.
The problems were terrible, those DBMSs were abandoned and the venture
capitals were lost.
Regards
Alfredo Novoa
<Rene_de...@hotmail.com> wrote:
>> The problem is how to describe such relation value and how to define
>> the operators of the type.
>
>The relation value is often described algebraically using a modal logic
>extended with quanfiers and relations.
Interesting.
>(Relations are of two basic types in AP5, defined or stored).
>In AP5 operaters are also relations.
>See my other posting for how a plus operator can be defined relationally.
Also interesting.
>values of a type <=> 1-ary relation value
>type <=> relation / relation definition / relation name
and operators.
IMHO when we are defining the set of values of a type in a statement
like this:
type Lenght possrep { Integer constraint Lenght > 0 };
This is a domain definition and not a complete type definition because
we still have not defined the operators.
>in AP5 relations are second class objects. i.e. there is a 1-1 relationship
>between relation / relation defintion and relation name.
Ok, but that relationship does not mean that the three things are the
same thing.
Regards
Alfredo Novoa
<jan.h...@REMOVETHIS.pandora.be> wrote:
>>>>>I simply cannot believe that you do not see what is problematic about
>>>>>this type of argument. Seriously.
>>>>
>>>>So what is problematic?
>>>
>>>It's irrelevant.
>>
>> Then I can continue to think the same without worry :)
>
>Sure. If you are not worried by incorrect arguments....
But it seems that you are not able to show any incorrection.
>Yes, and as anybody who has actually done some research on OODBMSs knows
>that is blatant nonsense.
What is nonsense are OODBMS and XMLDBMS research.
It is clear that Date's arguments are dangerous for the OODBMS retro
"researchers", and they don't seem to have any decent
counter-argument, so they try to discredit Date's works with general
and ad-hominem disqualifications.
Regards
Alfredo Novoa
<dw...@tincat-group.comREMOVE> wrote:
>1) Has anyone provided any better logic related to the 1GB than that
>provided by Date?
Logic is correct or incorrect.
> If not, I would think we could talk about this as
>intuition or hypothesis that there is a mistake rather than anything
>resembling a proof, right?
This is tautology:
If types are not variables, it is wrong to equate types and variables.
A <> B => ~ ( A = B )
There is no intuition or hypothesis here.
Regards
Rene de Visser
> >in AP5 relations are second class objects. i.e. there is a 1-1
relationship
> >between relation / relation defintion and relation name.
>
> Ok, but that relationship does not mean that the three things are the
> same thing.
>
Maybe I am mixing the terms too freely (also in my mind) and therefore
making some logical errors.
But I guess you will point these out if you see them?
I am also wondering if there is some important difference between domain and
type that I am missing?
Rene.
Ja Lar
"Alfredo Novoa" <alf...@ncs.es> skrev i en meddelelse
news:41adec79...@news.wanadoo.es...
There is fact nothing here.
Alfredo Novoa
=?iso-8859-1?q?Leandro_Guimar=E3es_Faria_Corsetti_Dutra?=
<lea...@dutra.fastmail.fm> wrote:
> Really? Do you have any details?
Google for "SQL Server 2005" and custom data types
or Yukon and custom data types.
http://www.code-magazine.com/focus/Article.aspx?quickid=0303052
> I have interestingly found that currently MS SQL Server
>practitioners I've had contact with are more conceptually sound than
>Oracle ones.
What I have found is that Delphi and Visual Studio practitioners tend
to use the DBMSs better than Java practitioners.
> Would like to know why, your information may point to
>MS's approach being at least slightly saner than Oracle's.
IMO the advantage of M$'s approach is that we can create custom types
that don't need to work with pointers.
We can create custom types that are not reference types, using the
Java jargon.
Regards
Jan Hidders
Those are not the "certain problems" that the claim predicts.
-- Jan Hidders
Jan Hidders
> On Fri, 26 Nov 2004 17:18:11 GMT, Jan Hidders <jan.h...@REMOVETHIS.pandora.be> wrote:
>>Alfredo Novoa wrote:
>>>Then I can continue to think the same without worry :)
>>
>>Sure. If you are not worried by incorrect arguments....
>
> But it seems that you are not able to show any incorrection.
I already did that in this thread and you chose to ignore it.
>>Yes, and as anybody who has actually done some research on OODBMSs knows
>>that is blatant nonsense.
>
> What is nonsense are OODBMS and XMLDBMS research.
Just repeating a claim is not very interesting. Actually supplying some
evidence for it would really help the discussion.
> It is clear that Date's arguments are dangerous for the OODBMS retro
> "researchers", and they don't seem to have any decent
> counter-argument, so they try to discredit Date's works with general
> and ad-hominem disqualifications.
Again, some evidence would be nice.
-- Jan Hidders
Dawn M. Wolthuis
> On Mon, 29 Nov 2004 16:44:44 -0600, "Dawn M. Wolthuis"
> <dw...@tincat-group.comREMOVE> wrote:
>
> >1) Has anyone provided any better logic related to the 1GB than that
> >provided by Date?
>
> Logic is correct or incorrect.
LOL. Of course, you are correct, sir.
> > If not, I would think we could talk about this as
> >intuition or hypothesis that there is a mistake rather than anything
> >resembling a proof, right?
>
> This is tautology:
>
> If types are not variables, it is wrong to equate types and variables.
OK, this is the point I really don't get. It sounds like the 1GB is
concerned with using an OO Class to specify a Relation type. Then we get
into the further issue that in relational theory we used to use the word
"relation" for both a "relation" and a "relational variable" but we are now
more sophisticated and we (sometimes) remember to use the coined term
"relvar" instead. Is the issue that in OO there is no new coined term to
distinquish between a Relation specified as a type and a Relational
variable? If so, the issue is semantics and not logic, right? Or am I
confused on where the confusion lies? --dawn
Alfredo Novoa
<dw...@tincat-group.comREMOVE> wrote:
>> If types are not variables, it is wrong to equate types and variables.
>
>OK, this is the point I really don't get. It sounds like the 1GB is
>concerned with using an OO Class to specify a Relation type.
A relation variable, not a relation type.
> Is the issue that in OO there is no new coined term to
>distinquish between a Relation specified as a type and a Relational
>variable?
No, but the complete mess in the OO terminology is the cause of many
confusions.
Regards
Dawn M. Wolthuis
> On Sat, 4 Dec 2004 13:10:27 -0600, "Dawn M. Wolthuis"
> <dw...@tincat-group.comREMOVE> wrote:
>
>>> If types are not variables, it is wrong to equate types and variables.
>>
>>OK, this is the point I really don't get. It sounds like the 1GB is
>>concerned with using an OO Class to specify a Relation type.
>
> A relation variable, not a relation type.
So, the 1GB has nothing at all to do with using a class to define a Relation
type, such as "Person" -- is that correct? Then if a variable is declared
to be of the type Person, does the 1GB refer to that situation? I guess I'm
asking for more precision in stating what practical is being identified with
the 1GB. It seems like it is a flap about how one person says, for example
"relation" when they really mean "relation variable" (translated to OO
terms).
>> Is the issue that in OO there is no new coined term to
>>distinquish between a Relation specified as a type and a Relational
>>variable?
>
> No, but the complete mess in the OO terminology is the cause of many
> confusions.
I definitely understand that saying "I love my brother" could be confusing
to someone who has two different terms for love -- one for romantic love and
one for other non-romantic love, for example. So, the terminology could be
the "cause of many confusions". My question is where the blunder really is.
I think I posted a question on this a year or so ago too and I still don't
see a practical blunder -- just some sloppiness in terminology. However,
Date seems to argue that there is a practical problem in this mix. Do you
think there is? Thanks. --dawn
>
> Regards
Ja Lar
"Alfredo Novoa" <alf...@ncs.es> ...
> "Dawn M. Wolthuis"...
>> Is the issue that in OO there is no new coined term to
>>distinquish between a Relation specified as a type and a Relational
>>variable?
>
> No, but the complete mess in the OO terminology is the cause of many
> confusions.
A myth, apparently based on an early view on OO not in sync with present
understanding of the field. On the same footing as many OOists
misunderstanding of relational databases: "If you don't quite know the
subject, dislike it, or better: coin it useless and without real value".
But the value of a (academic) subject should not be measured on how it is
understood or represented by those who has lesser knowledge on the subject.
A class is (also) equivalent with an Entity (as in ER-modelling). Now, make
the usual mapping from ER to relational model....