Re: Reminder, blatant ad
Date: 27 Jan 2006 06:57:15 -0800
Message-ID: <1138373835.368733.291150_at_g47g2000cwa.googlegroups.com>
Jan Hidders wrote:
> dawn schreef:
> > Jan Hidders wrote:
> > > dawn wrote:
> > > > Jan Hidders wrote:
> > > >>
> > > >>Dawn Wolthuis wrote in her blog on
> > > >>http://www.tincat-group.com/mewsings/2006/01/naked-model.html
> > > >>the following:
> > > >>
> > > >>>[...] If we were to implement a data model what would we have? Let's
> > > >>>take a look at a recent definition of data model from Date.
> > > >>>
> > > >>>A data model is an abstract, self-contained, logical definition of
> > > >>>the objects, operators, and so forth, that together constitute the
> > > >>>abstract machine with which users interact. The objects allow us to
> > > >>>model the structure of data. The operators allow us to model its
> > > >>>behavior. (C. J. Date, An Introduction to Database Systems, Addison
> > > >>>Wesley, 8e, 2003, p 15-16)
> > > >>>
> > > >>>I conclude from this that the implementation of a data model is a
> > > >>>programming language, whether a general purpose programming language
> > > >>>or not.
> > > >>
> > > >>While I don't think that what you say here is strictly speaking
> > > >>incorrect, I do believe that it is misleading. In programming languages
> > > >>one is often rather more concrete about how the data is stored and how
> > > >>the operators do their work, in fact that is often the whole purpose fo
> > > >>the programming language, whereas Date stresses rightly here that it has
> > > >>to be an *abstract* definition.
> > > >
> > > > I definitely think that a data model is abstract. That is why I said
> > > > that an implementation of the data model (for our purposes of
> > > > developing software) is a programming language. That is why when
> > > > countering SQL, claiming it not to be a good implementation of the RM,
> > > > Date introduces Tutorial-D, another language. I am stating that a data
> > > > model is the abstraction of a programming language (or sublanguage).
> > >
> > > That's not how I would formulate it. SQL is not an implementation of a
> > > data model, it *is* a data model (as defined above by Chris Date).
> >
> > Both SQL and QUEL were implementations based (however loosely) on the
> > Relational Model. So, a single data model can have multiple
> > implementations.
>
> Not in that sense. Your example is not a really good one because the RM
> is strictly speaking not a data model (using Date's definition) but
> rather a description of a class of data models. It lists some
> requirements, and sketches a few things, but doesn't exactly define how
> the abstract machine looks and what the complete set of operations is.
>
> > Similarly an oject data model can be implemented by
> > both Java and C++ in different ways, with varying degress of purity.
>
> Not in the definition of data model that we are using at the moment.
> The semantics of Java and C++ describe different state machines and
> different operations, so they define different data models.
Because I was making an effort to get a handle on the term "data model" as found in the phrase "Relational Data Model" I'm working with a different "data model" than you are. Mine is more abstract (or as you stated, it is a description of a class of data models). Using the term the way I am using it, you can have a "Relational Data Model" and an "Object Data Model," for example. Can you name a bunch of data models using your definition?
> Of course
> there are some comonalities and things they share, but that is
> different from saying they represent the same data model.
>> > Oracle 8i) is an implementation, an actual language that I can use to
> > > SQL
> > > and the relational model are at the same abstraction level,
> >
> > An instance of the SQL programming language (e.g. SQL as implemented in
> > perform a query against a database.
>
> Yes, but a particular implementation is yet again at another lower
> abstraction level.
And a data model is at a higher level of abstraction. Again, recall that I was trying to get a handle on the meaning of "Relational Data Model." What is this "data model" when you remove the adjective? It is more abstract that what you are referring to.
> Perhaps there is a small lesson here. Saying that A is an abstraction
> of B, or that A is abstract is meaningless until you have explain in
> what way exactly you are abstracting or what it is that you are
> abstracting from.
It isn't meaningless, but it isn't very helpful simply to state that something is an abstraction of something else. It is a bit more concrete to state that something is an implementation of something else. So if you take Relational Data Model and want to get a handle on this data model, you can at least see that if you were to implement it, you would have a programming language (or sublanguage).
> > > > [...] Whenever I mention that I want to
> > > > work with such data structures as ordered lists with associated insert
> > > > and delete functions, I am informed that I am talking about
> > > > representation and that what I want is possible with the data modeled
> > > > via the RM and then handled with another product in front of that. I'm
> > > > showing that the RM is all about representation. As soon as you decide
> > > > to use another representation, you are moving away from the RM.
> > >
> > > I don't know who told you that lists are somehow only representation
> > > while sets are not, but that is nonsense.
> >
> > Agreed.
>
> I currently do some research in bioinformatics. Lists of nucleotides
> and proteins all over the place, and measurement series are also very
> often much more naturally represented as lists.
Perhaps you are beyond me on that one. I've read Bioinformatics for Dummies ;-)
> > > The reason to avoid lists is
> > > far more mundane and practical; it would make the DBMS more complex and
> > > make tasks such as query optimization, concurrency control and integrity
> > > maintenance harder.
> >
> > Harder for whom?
>
> The implementors of the DBMS.
BINGO! Having been on the applications side of the house, I am aware that choices are made on user interface design decisions are sometimes made due to the cost of implementation or support for the developers. But for an entire industry to fix on that strategy when the user is a programmer is really dreadful. It seems someone could look at how to make the end-user (in this case a software developer) as productive as possible.
> And if their job gets hard that leads to
> more missed opportunities for the query optimizer so slower
> performance,
That would make more sense to me if I did not work with a non-1NF (non-relational) product that provides good performance.
> more difficult algorithms for concurrency control that
> allows less concurrency, and more overhead for more complex integrity
> constraints.
That one I agree with.
> > > It would also make the theory more complex, which in
> > > the long term usually also translates into practical problems.
> >
> > The language I speak also has a very complicated theory behind it, if
> > any at all (IIRC Chomsky or others have worked on a mathematical theory
> > behind languages). But it still might make sense for me to speak it.
>
> That's because you don't have to build the Language Management System
> as they already exist. But if you were faced with the task of designing
> such language processing systems from scratch then you would probably
> try to design this language as simple as possible, but, to paraphrase
> Einstein, not simpeler.
Then there is that philosophy of making products easy for users. The RM isn't getting us there it seems. Cheers! --dawn
> -- Jan Hidders
>
> PS. I'm really signing off now as my train leaves within a few hours.
> Expect a reply after a week or so.
Have a good trip. (Or, rather, I hope you had a good trip and enjoyed your time away from the screen and keyboard.) Received on Fri Jan 27 2006 - 15:57:15 CET