Re: algebra equations for Reference and FD constraints

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:F366l.5463$Ou7.4752_at_newsfe24.iad...
> Brian Selzer wrote:
> ...
>> is the case. That is the essence of database updates, which are
>> definitely outside the scope of the algebra and the calculus.
>> ...
>
>> Database updates are indeed a relational model concept even though
>> neither the algebra nor the calculus are sufficient to express them..
>> ...
>
> Taken together, those two sentences amount to a very familiar mysticism,
> trying to have it both ways. The RM is a model for a machine.
> Self-evident that it's not a model for people. For a db to be useful,
> obviously people must interpret the results of the model, ie., they agree
> to interpret its results the same way (in a given setting).
> An example - obviously Codd expected that the practical purpose his
> audience had in mind was that some results would persist on some medium.
> But his model doesn't require that. Persistence is often mistaken as
> being essential to Codd's model, but it's not, the model stands up quite
> well without any notion of persistence. Do the same with any other
> concept, remove it from the picture and then ask is there a practical
> interpretation of the results of the calculus or algebra as applied to
> some formal definition of relation. Don't worry about whether everybody
> in the world prefers that interpretation, just ask whether some people do.
> As the posts from many people on various c.d.t. threads over the years
> show, there are many interpretations and yet very few concepts needed.
> This is became most concepts people talk about are interpretive concepts.
> Such concepts can be excised from all talk about the formal model without
> harm.
>

It's not clear to me what you mean by "Codd's model". In the footnotes to Codd's early work, it's clear that the relational model of data predates Codd's initial work. It also seems clear, at least to me, that Codd's early work dealt not with the relational model of data as such, but with the application of the relational model of data to the task of database organization and interface, and therefore to the task of database management system design. If I'm right about this, then the notion of persistence is central to what Codd was discussing, regardless of whether or not the notion of persistence is essential to the relational model of data.

Throughout the history of c.d.t. there has been an ongoing ambiguity about whether the relational model is being proposed as the framework for a theory of databases or whether it's being proposed as the framework for a theory of computing in general. Not that it couldn't be proposed for both. Just that the discussion at each point remains clear only if the writer and the reader both know which proposal is being discussed.

In the context of databases, Brian's term "database update" is crystal clear. There is a state of the database (out of all the possible states of that database) before the update. There is likewise a state of the database (out of all the possible states of the database) after the update. The database update is the difference between those two states, regardless what imperative form resulted in the updates taking place. In particular, it doesn't matter what combination of SQL UPDATE, DELETE or INSERT imperatives were performed, or in what sequence, or whether some other imperative language was used, as long as the difference remains the same. No confusion need exist between "database update" and "SQL update". Either that, or I'm misreading Brian's comments.

What's not clear to me is whether or not the concept of "assignment" is inherently an imperative concept, and not reducible to purely declarative expression. I lean towards the view that assignment is inherently imperative. Received on Tue Dec 30 2008 - 08:08:04 CET