Re: Reminder, blatant ad

Jan Hidders wrote:
> Hi Dawn,
>
> Since I don't like discussing by means of blog comments I'll post my
> reaction here.

I have never been a blog-comment person either, but since there are some students reading my blog, it is good for them to see comments with it too, so I'm encouraging that. I'm happy to get feedback from you in this forum too, however.

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

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

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

I suppose that is the intent, but I see nothing in Codd's definition of a data model that would lead me to believe that a data model must be implemented in a declarative language.

> whereas in
> programming languages this is often more done in an operational way.

OK-ish.

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

I did not intend to equate them but to claim that a data model is implemented via a programming language. That language could be declarative, functional, set-based, procedural, OO, ...

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

> or at least not in exactly the same way. 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?

I cannot speak for most students, but when looking at text books (rather than listening to professors) and to employees entering a space where they need not employ the RM, it is my guess that the bulk of the college grads in CS in the US think that the RM is the way one should model data, period.

> And those people
> are allowed to build critical information systems? :-)

Not until we have beat the theory out of them and introduced them to the real world :-) [P.S. Don't quote me on that -- this is a private conversation, right?]

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

I didn't intend to suggest that. 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.

> 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. I don't think many will contest the claim that is it not sufficient either. But (I think) I'm going to claim that there other data models that are sufficient for developing software and then ask if it is important enough to use the RM that we want to suffer the mismatch with whatever other data models we use.

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

No problem. --dawn Received on Thu Jan 26 2006 - 22:15:42 CET