On 3/29/07, Jochen Theodorou <blackdrag / uni.de> wrote: >> 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. The Relational Model of Data is about how to organise the data in such a way that relational algebra is able to work. So your statement isn't really correct. Relational algebra doesn't work without the organisation of the data into sets of tuples and attributes. >> 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? Are you not understanding what I'm saying? I'm making an analogy here, not a direct correspondence. What people call an "object model" is similar to a relational schema. When I do my object models, I *start* with how I need to model my data; then and only then do I start considering my operations. (I will, of course, have considered the "pipeline" for processing the data related to the purpose of the program I'm working on.) >> 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. They're not orthogonal, really. A database schema and an object model are orthogonal, but one deals with a higher level concept than the other. >>>> 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 I'd be considered an object apostate by some of the more vehement OOists out there, mostly because I think that data is far more important than operations involved and that I consider it a refinement of procedural programming. Encapsulation is the only thing that seems to be *common* among the various OO systems I've seen, but I've seen C code that I would consider programmed in an OO-style even though there's no encapsulation (as such) in C. >> 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. I can't parse this; encapsulation is, as I understand it, combining data and operations. >>>> 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 ;) Not at all. I think I've explained it above, but if you still don't understand, please ask. >> 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? This is basic relational theory; please read more on it. >>>> 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. Not at all. Performance is about implementations, not about concepts. > [...] >>>> 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. OO database vendors *as a class* make specious claims, usually about being "post-relational" and not having coherent explanations for why abandoning first normal form is a good idea. They can't explain it, so they have to hype up things to distract others. > [...] >>> 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. No, it's "returning." I read it thoroughly enough to see that they were trying to add some level of relational algebra *back* to object databases because what was happening in object databases was simply not good enough. The authors weren't quite clear enough on the concepts (despite having clearly read C.J. Date, as referenced in the paper) to admit this, though. >> 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. They don't condemn this; first normal form is something that really makes a lot of sense in data and object modelling. They have to *synthesize* a first-normal form for their relational algebra to even *work*! >> 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? They added relational algebra to an object database model by synthesizing a tuple for relational operations. That's an utter failure to provide an object algebra. Read the paper again: they *clearly* say they synthesize tuples to layer relational algebra on top of object databases. It's not a matter of disagreeing with the authors, it's a matter of recognising that the paper doesn't really do what you think it does. >>>> 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. All of these will benefit more from relational databases than object databases. If they're *that* small, just use a plain-old object store (like PStore or Madeleine, if you must); don't bother with an object database -- because you'll spend almost as much time in the short term, and much more time in the long term, with that as you would with a good ORM and a good SQL database. -austin -- Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/ * austin / halostatue.ca * http://www.halostatue.ca/feed/ * austin / zieglers.ca