Re: Reminder, blatant ad

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. Similarly an oject data model can be implemented by both Java and C++ in different ways, with varying degress of purity.

> SQL
> and the relational model are at the same abstraction level,

An instance of the SQL programming language (e.g. SQL as implemented in Oracle 8i) is an implementation, an actual language that I can use to perform a query against a database.

> so it
> doesn't make much sense to me to say that one would be an implementation
> of the other. In the same way I don't see what the data model of, say,
> Java would be, and what it would abstract from i.e. what it leaves out.
> If I take the definitions of the objects, operators and everything that
> makes up the abstract machine that the user / programmer of Java
> interacts with, (not to be confuseed with the JVM) that *is* the
> definition of Java. To me it seems absurd to say that a data model is an
> abstraction of a programming language.

Multiple programming languages, each with a different syntax, can each implement the same data model, wouldn't you say? Maybe "implement" is too strong. SQL, QUEL, and Tutorial-D can all be based on the RM. The RM is the abstraction and each of these others has a different syntax.

> >>>My beef with the RM is related both to normalization theory as taught
> >>>in colleges and universities, discussed in the Is Codd Dead? blog
> >>>and to the way the RM, or parts thereof, are used in the practice of
> >>>software development and maintenance today. It shapes the thinking of
> >>>software developers in ways that are often not the most effective.
> >>
> >>I have really no idea where this comes from. When I teach normalization
> >>I do that in the context of the relational model. It is part of the
> >>theory that you should know if you have to deal with an RDBMS.
> >>Obviously, if you have to deal with another type of DBMS you should not
> >>apply it,
> >
> > and that is obvious to your students? If so, three cheers.
>
> Might have to do with the fact that we also teach some stuff on other
> types of databases, object-oriented and object-relational in the past,
> now mostly XML databases. And, of course, Belgian students are
> incredibly smart. :-)

I knew that. They are close to those Dutch folks.

> > [...] 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.

> 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?

> 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.

> >>The claim of the RM is that it is a good data model for a
> >>DBMS,
> >
> > Yes, that is the claim. I'm claiming in this blog that it isn't
> > necessary, a point that no one contests (I suspect) since we know we
> > can build software systems without it.
>
> Sure, bathing regularly is also not necessary. It's still a good idea
> though. :-)

Yup. So, that is what we are left with -- decisions on whether it is obvious to bathe regularly or not, or maybe it is more like curling your hair with a curling iron. It might make complete sense to a whole group of women, but it has never made sense to me and I get ready much faster ignoring it altogether. cheers! --dawn Received on Fri Jan 27 2006 - 04:21:29 CET