Re: What does this NULL mean?

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Wed, 21 Dec 2005 08:14:26 GMT
Message-ID: <C98qf.72848$V7.1218_at_news-server.bigpond.net.au>


"Alfredo Novoa" <alfredo_novoa_at_hotmail.com> wrote in message news:1135078131.827701.184510_at_g49g2000cwa.googlegroups.com...
> >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.

That might be your claim, but I certainly do not support it.

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

Data management is only a part of the picture, except in the case of those who subscribe to the relational model of data, in which case the management of data is considered as a holy island in the middle of an ocean of application code, only accessible by a map drawn 30 years ago.

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

The only place the RM is evolving is in Date's head, and therefrom in the heads of his party of hangers on. However from an external and independent perspective, the RM has not changed since relational systems started selling oracle.

> does not address the application software enviroment because it is
> completely independent to it.

The code and the data are two sides of the one coin. They are like ying and yang. You and Date might like to think they are separate entities with different theoretical basis, but then you and Date have not given the matter enough thought IMO.

> This is like to criticize the Relational
> Model because it is mute about how to cultivate melons

That's clearly impossible. The Relational Model is perfect and any criticism of it must be wrong.

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

Application software may be reduced to stored procedures. Stored procedures are database objects, written in the SQL of the host vendor RDBMS software. They cannot be separated from the database.

Thus you shoot yourself in the foot.

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

Data management theory and stored procedure management theory are subsumed by the theory of database systems. This is why the relational model of data is only half the story wrt a complete theory of database systems.

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

What it does, yes, it does do well in its data centric world view. But so what? Why rest on its laurels like Date has been doing for 30 years?

-- 
Pete Brown
Falls Creek
OZ
www.mountainman.com.au 
Received on Wed Dec 21 2005 - 09:14:26 CET

Original text of this message