Austin Ziegler schrieb:
> On 3/29/07, Jochen Theodorou <blackdrag / uni.de> wrote:
>> Austin Ziegler schrieb:
>> [...]
>> > Please, please, *please* read more about relational theory before you
>> > make statements like this, because it's technical nonsense. There *is*
>> > no "object model."
>> of course there is none as you define it. Who said I am using the same
>> definition? Is your definition a common definition for "model" in
>> general? If so please point me to a reference. I don't know all the
>> correct UK/US terms used for this.
> 
> Like I said, "model" is a vague word. When you say "relational model",
> the *meaning* is the "Relational Model of Data" (e.g., the theory). At
> this point, there's nothing related for an "Object Model of Data".

but the relational algebra is about queries not data in the first place.

> When one says "object model", one usually means "the hierarchy or
> graph of objects that I am using to represent the data and operations
> in my implementation." In relational terms, that is a schema.

the operations are part of the schema?

> So, "relational model" and "object model" are two *totally* different
> things as they are typically understood as one deals with a concept
> and the other deals with a single implementation.

sorry I don't agree with you here. not with the word implementation. I 
see them as orthogonal.

>> >   That's an important point, too:
>> >   object orientation is about *programming*. It is not about data and
>> >   the storage of data.
>> I agree partially. It is a data structure, it is not more about
>> programming as a binary tree is. So it is about structuring your data to
>> fit your needs of computation... but that fits so much that is a useless
>> statement
> 
> The classic definition of an object is data and the operations that
> apply to that data encapsulated in one. I am sure that there are
> definitions of OO out there where encapsulation isn't part of it,

from the view of data the operations are not relevant, or not? I mean 
unless you make them part of the algebra... I think I have seen that 
somewhere.. ah, not sure where, sorry

> but
> I consider encapsulation probably the defining feature of OO (even
> more than inheritance, because there are strong arguments for
> composition instead).

encapsulation in terms of grouping data together? hat is not more a 
definition as a table is.

> That's a whole different argument, though, and
> most OO systems these days accept encapsulation, inheritance,
> polymorphism, and (often) access control (information hiding).

right.

>> > 2. When *implementing* something, you will model the data. This can be
>> >   your data model that can be extended into an object model for
>> >   programming purposes. These "models" are better considered "schema";
>> >   they describe the layout of the data.
>> What you want to say is, that a schema is no model? Or at last not all
>> schemata are models. I think.. I am not sure yet ;)
> 
> Just the opposite. An object model is closely related to a data model
> (or a database schema, if you prefer).  There's no overarching theory
> of object modelling (at least not yet, as Ed pointed out), whereas
> there *is* an overarching theory of data and relations.

data *and* relations, yes. A theory about data only would be useless, or 
not?

>> > Just because one *can* create something that works without a
>> > mathematical theory behind it does not mean that one *should* do so.
>> or should not do so.
> 
> Fair enough, but if one chooses to step away from something that has
> theoretical underpinnings, one should at least be prepared to make a
> coherent explanation as to why it's better.

coherent? "My tests are showing my application is faster with it" or "I 
am faster in prototyping" is for some cases coherent enough.

[...]
>> > One
>> > certainly shouldn't claim that the thing without a mathematical theory
>> > behind it is superior to the thing with -- because that's something you
>> > should be able to demonstrate with, well, another theory. Performance
>> > metrics are not evidence of superiority of concept; just of
>> > implementation.
>> I have never done that. So I guess you don't mean me, because I am well
>> aware of the problems of OODBs
> 
> I wasn't referring to you specifically; I was more referring to the
> OODB vendors, who have no excuse for their specious claims.

and you are not referring to a specific OODB vendor either... just to a 
blurred mass of unknown people. Don't mix the vendor with salesman. Some 
are, but not all.

[...]
>> ok, see "A Query Algebra for Object-Oriented Databases (1989)" on
>> citeseer http://citeseer.ist.psu.edu/shaw89query.html
> 
> I skimmed through this; reading it, it's an attempt to *return* some
> level of relational algebra to object databases ... all the way back
> in 1989.

please read it again. there is no such thing as "returning" there is 
only a thing of mapping one concept to another. Something like a morphism.

> Sadly, the authors still think that first normal form is an
> unnecessary restriction on the logical formation of the data -- and
> they have to synthesize first normal form tuples to obtain relational
> algebra capabilities in object databases.

where?

I have read: "One research direction in the modeling of object-oriented 
is the extension of the relational model to build complex types. Early 
extensions relaxed the first normal form requirement of the relational 
model to allow set valued attributes.

> 
> I haven't looked further, but it's not quite a positive refutation of
> my statement.

you claimed there is no algebra, I proved you wrong. I myself said there 
is much space for nonsense and that without constraints there will never 
be a "solution". So either we talk about such constraints or we end the 
topic. It makes no use to give more and more new papers just that you 
can say that you don't like the opinion of the author."

I guess you mean a different part?

>> > Sure, an object store can be set up to allow for smart loading and 
>> such,
>> > but that *doesn't* mean that it's a good idea. It might be the "right
>> > now" idea, but it is something you'll have to pay the piper for 
>> using at
>> > some point in the future.
>> depends on my goals, or not?
> 
> I've said as much. Right now solutions usually meet one's immediate
> goals, but rarely meet long-term goals and often result in increased
> costs in the long-term.

might be true, but if your boss says that he needs to save money in the 
short term it is a different thing. For example for prototypes, for 
example for small applications, for example for applications that don't 
share data, for example for applications without the need to do reporting.

bye blackdrag