Re: Microsoft and the two great blunders
Date: Fri, 26 Dec 2003 00:04:03 -0800
Message-ID: <bsgq38$cmb87$1_at_ID-152540.news.uni-berlin.de>
Alfredo Novoa wrote:
> Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<bsdbmu$c7iot$1@ID-152540.news.uni-berlin.de>...
>
>
>>Table. Everybody and their grandmo know what a table is. Fore you, it is >>a relvar.But grandmo doesn't know what a relvar is.
>
>
> My grandmother knows what a relation is, and it would be easy to
> explain her what a variable is. And of course she knows that a table
> is a board supported by several legs on which food is served :)
>
Then your mother may not speak English very well,
> Relation is a common term out of the crazy IT world. Biz guys don't
> say: give me a table of customers.
>
They don't say give me a relation of customers either.
> But my main complaint is about using a single word for table value and
> table variable. They are fundamentally different concepts.
>
Who's using that ?
> Table is more appropiate for the SQL bags, and relation is more
> appropiate if you are talking about a relational database.
>
Ahem, you mean relvar ?
>>A >>relation is a set of tuples. Therefore a table may store all the >>values of a certain tuple type.
>
> A relation is more than a set of tuples.
>
> I have never seen a table containing all the values of a tuple type at
> practice. In many cases it would be physically impossible.
>
All the values in the domain of interest that are of a certain type. For
example all the value of Employee type.
>
>>So then the great blunder, it's not such a big deal, or is it ?
>
> It does not have relationship with the great blunder.
>
Oh, but that is allegedly one of the great blunder. Read TTM appendix.
>
>>>>Quite nice. But according to D&D types are sets of values. Well, then a >>>>relation is a set of value. >>> >>>According to D&D and many other people, types can be viewed as sets of >>>values associated to sets of operators. >> >>Not unless they've written one more edition of The Third Manifesto where >>they corrected their mistakes. >> >>Here's a reference for you: >>http://www.hughdarwen.freeola.com/TheThirdManifesto.web/D.GRM >> >>As you may see, the user who declares a type has no mean to properly >>express a set of operators as integral part of the type definition.
>
>
> Any operator may be a part of several types, and you can express that
> without problems with that template (and flawed) grammar.
>
So if an operator is part of several types, you've got a problem. Are operators part of the type definiton or not ?
> (BTW is anybody interested on the mistakes of that grammar?)
>
> Here is an appropiate quote:
>
> -
> A type is a defined finite set of values and associated
> operators. The associated operators consist of those defined to
> operate on values or variables of that type and those that,
> when invoked, return values of that type.
> -
>
> http://www.hughdarwen.freeola.com/TheThirdManifesto.web/taamoti.paper.pdf
>
That quote doesn;t solve anything, at best it is a declaration of intention, plus it does not clarify if operators are part of type definition or not.
>>Your definition "sets of values associated to sets of operators" is >>equally unsatisfactory. Does it mean that the definition of operators is >>integral part of type definition ?
>
>
> Yes.
>
>
>>Or to make it easier for you to express, here's an example from TTM: >> >>TYPE PLANE_FIGURE ... ; >> >>TYPE ELLIPSE >> IS PLANE_FIGURE >> POSSREP { A LENGTH, B LENGTH, CTR POINT };
>
>
> It is not a complete type definition.
>
So what would be the complete type definition ?
>
>>Now, I wonder what you or anyone would replace those dots with, within >>the framework established by D&D, so that it makes any sense whatsoever.
>
>
> Something like:
>
> type Plane_Figure union;
>
> I don't remember the syntax, my copy is 600 km far. It should be the
> equivalent of an "abstract" type.
>
Oh. But
type Plane_Figure union;
Is void of content. A proper abstract data type is something entirely
different, and we already have proper mathematical formalisms to define
What *is* Plane_Figure , and what's the purpose of that declaration ?
>
>>But if the framework is so weak that it can't even deal with this much >>it should be either reformed or discarded altogether.
>
>
> IMHO what is a bit weak is your knowledge of the model.
>
IMHO your knowledge of the entire subject of type theory is weak.
>
>>>On the other hand, a relation >>>is an individual constant. But the "great blunder" is to confuse types >>>with relation variables, not whith relations (values). >> >>Nobody is confusing anything.
>
>
> Then we live in different worlds.
>
> Have you readed this:
>
> http://www.ambysoft.com/persistenceLayer.pdf
>
> It is the inspiration of dozens of SourceForge and comercial projects.
>
So what ? People are free to waste their time however they wish.
>
>>And this is no blunder. Most people *map* entity-types to tables. I.E.
>
>
> Entity-types are virtually meaningless. Is the E/R "model" your idea
> of a formal framework? }:)
>
Yes, it is. A little bit of reading on the subject wouldn't hurt you.
Try Thalheim "Entity Relationship Modelling - Fundations of Database Technology" Springer Verlag 2000
> Most people "map" entity types to classes and classes to table
> variables.
>
>
>>for every entity type found during analysis, they typically create a >>table in the relational schema to store values of that type.
>
>
> That was before the persistence framework fad. Now they typically
> create a Java or C# class and they "map" the class to a table or
> several tables using a "persistence layer".
>
> It is clear on the slides.
>
So you still haven't shown any problem.
Cheers,
Costin
Received on Fri Dec 26 2003 - 09:04:03 CET