Re: the relational model of data objects *and* program objects

"erk" <eric.kaun_at_gmail.com> wrote in message news:1113487340.597674.91730_at_z14g2000cwz.googlegroups.com...
> mountain man wrote:
>> "Alfredo Novoa" <alfredo_novoa_at_hotmail.com> wrote in message
>> news:8his519g1kjtvjiturs93qc31k1uh290kp_at_4ax.com...
>> > The inexistence of relationships between the RM and the
> applications
>> > does not mean that the RM is useless for developing applications.
> It
>> > only means that it is not being used.
>>
>> I think that you would agree that it obviously should be used,
>> because of the downstream benefits, but it is not. Does this not
>> tell you something? It tells me that the model - as it is currently
>> promulgated - is not viewed as being applicable to the task by
>> the people involved in conducting the task.
>
> That's a big leap. Your argument assumes that people research and
> examine existing models prior to implementation, and that all models
> are examined closely and then adhered to. In reality, models are
> abandoned too quickly, and the model morphs, implicitly, in the minds
> of implementers (resulting in such things as SQL). There's no reason to
> assume that people conducting the task have adequately surveyed and
> evaluated underlying theory. And that's sad, because in our business,
> we have a better chance than any other at actually executing theory
> as-is, given that computers can become any machine described
> adequately.

Of course it is a sad state of affairs, and the only way to extricate progress from this state is to examine whether or not is is feasible that database systems theory can be made far more amenable to both organisations and any related consultants.

That the RM of the data is at the central focus of database systems theory has an historical perspective due to the emergence of DBMS software. However (R)DBMS software has undergone great change since 1979 (Oracle).

It is now quite conspicuous that database systems theory should encompass other aspects of management, admin and operational control of data. Examples of this would be the additional services supported by modern (R)DBMS software:

• automated task scheduling queue
• data import and export processes
• replication, publication and subscription services
• email backbone and services
• alerts and error message schemas
• SQL (progress since 1979)
• addressable stored procedure objects

The last two items directly relate to the increased ability of modern database systems (in contrast with 1979 (R)DBMS) to essentially "house program code".

If you were to examine the location of database application layer software over the last 30 years you would observe that in the last few years there has been an increased tendancy for application level code to be literally stored within the RDBMS as stored procedure objects.

These changes in the technological environment must be met with revitalisation of theory associated with the management of this change as it applies to database systems.

Others in this forum have commented to the effect that "Date et al are not at all interested in application software". This negation is clearly reflected in the RM of the data.

However every single RDBMS site on the planet w/o exception must manage the union of two software systems: 1) RDBMS software
2) some form of database application software

To the extent that the atomic elements of (2) are today clearly found within (1), a model of database systems based on cognition of (1) alone cannot adequately be expected to portray the "reality of current technology".

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Fri Apr 15 2005 - 07:27:28 CEST