Re: Reminder, blatant ad

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.

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). SQL and the relational model are at the same abstraction level, 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.

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

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

> [...] 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. 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. It would also make the theory more complex, which in the long term usually also translates into practical problems.

>>The claim of the RM is that it is a good data model for a
>>DBMS,

Sure, bathing regularly is also not necessary. It's still a good idea though. :-)

• Jan Hidders