Re: Reminder, blatant ad
Date: Fri, 27 Jan 2006 01:05:21 +0100
Message-ID: <43d963a6$0$11063$e4fe514c_at_news.xs4all.nl>
Jan Hidders wrote:
> Since I don't like discussing by means of blog comments I'll post my
> reaction here. As you probably know I'm in the pro-RM and anti-dbdebunk
> camp, so although I'm probably mostly crticial, it is certainly not
> meant as an attack.
>
> 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. Another important aspect is the extent
> to which the definition is *logical*, which implies that the definition
> of constraints and manipulations should be more declarative, whereas in
> programming languages this is often more done in an operational way. Of
> course there are no black and whites here because these things vary in
> different programming languages, but simply equating the concept of
> "data model" as Date and Codd define it and "programming language" is
> cutting a few corners too many.
>
>>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, or at least not in exactly the same way.
Anecdote time:
When I learned about normalisation in 1984 in a post-doc IT curriculum, we were to some extend free to do our own explorations. One nice, enlightening excercise was this one:
From a normalised data model (based on an earlier design case, so "real" - or at least our own - analysis, complete with interviews, prioritisation, integration etcetera - remember James Martins integration bubble charts?) we made, in several workgroups, different implementation plans: one for a purely batch processing (only sequential files) environment, one for ISAM/online, (we skipped RDBMS implementation as being both being trivial and not yet feasible for performance reasons at that time :-), and eventually one hybrid plan.
Some crucial parts of those plans were actually coded and tested later in the course.
One thing I learned was that when you get your data right, you can pretty much build a working system with any tools available. A DBMS just makes the job easier. Database: Find the base for your design in data.
In short: To me the connection between RM and normalisation is mainly historical.
> Are you now telling
> me that most computer science students in the United States massively
> fail to get this when they take their database courses? And those people
> are allowed to build critical information systems? :-)
>
>
>>And, by the way, if you are thinking that the RM need not be obvious >>in a developer's programming language but could be hidden behind the >>scenes, then my work is done. That would mean that no computer >>language would need to use the Information Principle, and neither you >>nor I would need to use the RM as a data model. We can use any >>programming language that does not represent itself as an >>implementation of the RM to employ an alternative data model.
>
>
> Again, I have no idea what you are talking about here. Who on earth has
> ever claimed that the RM would be the best data model for programming
> languages? The claim of the RM is that it is a good data model for a
> DBMS, and even that claim is usually qualified.
>
> -- Jan Hidders
>
> PS. Apologies in advance if I don't reply this week, I'll be mostly
> off-line then.
Received on Fri Jan 27 2006 - 01:05:21 CET