Re: What does this NULL mean?

>Source code change management is one consideration, while
>another is the corresponding schema changes, which may or
>may not imply a sequence of physical data conversions and/or
>the loading of new data sets. There may be other considerations.

You are confusing the physical and logical levels.

>While the data changes may so be logged, neither
>the source code changes, or the coordination between the two are
>yet provided for by services within the database system.

Again nothing related with data management theory.

>The only reason you do not classify it as a theoretical problem
>is because the model you use for database systems is the 30 y/o
>relational model which has not evolved in all that time, and
>which does not address the issue of either the database
>application software environment, or change management.

The intrepretation Relational Model is continously evolving, and it does not address the application software enviroment because it is completely independent to it. This is like to criticize the Relational Model because it is mute about how to cultivate melons.

>As I have been saying for some time, the relational model
>of the data is incomplete as a database systems theory for
>this century because essentially, things have changed. See:
>http://www.mountainman.com.au/software/history/relational_model_incom...

This is plenty of incoherences, and the possibility of creating stored procedures is in the definition of the Relational Model. It is an essential part of the RM since the first day, although it was not present in some of the first fatally flawed implementations.

>No I want to see a properly extended theoretical relational model
>of both the data and the programs (because they are inextricably
>linked and optimally need to be managed, coordinated and change-
>managed together).

Applications are external to the data models, but there is little to theorize about the coordination between databases and applications: if you change the logical view of the database then you have to adapt the applications. That's all. You can create a tools that makes this adaptations automatically, but it has nothing to do with data management theory.

>The only confusion that exists as a result of my posting
>appears to be with certain parties who are unable to
>rationally discuss the evolution of theory of the RM
>of data (as it was 30 years ago) into a far more
>powerful theory that addresses a greater spectrum
>of contemporary database systems issues.

What you want is a theory for information systems development. Something broader than the Relational Model. The Relational Model is a part of that, and it does very well its specific job.

Regards
  Alfredo Received on Tue Dec 20 2005 - 12:28:51 CET