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

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Thu, 14 Apr 2005 11:45:47 GMT
Message-ID: <LJs7e.11339$5F3.9761_at_news-server.bigpond.net.au>


"Alfredo Novoa" <alfredo_novoa_at_hotmail.com> wrote in message news:8his519g1kjtvjiturs93qc31k1uh290kp_at_4ax.com...
> On Thu, 14 Apr 2005 08:53:12 GMT, "mountain man"
> <hobbit_at_southern_seaweed.com.op> wrote:
>
>>Consider an RDBMS supporting a large suite of database
>>application programs created in any programming langauge.
>>What formal relations exist between said suite of program
>>objects and the RM of the data?
>
> 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.

>>>It would be very useful to include
>>> relational extensions in the application programming languages.
>>
>>
>>Yes, that would be nice.
>>but is this happening on any scale at present?
>
> At a tiny scale, and this is sad.
>
>>>>, and thus is restricted in
>>>>issues involving the coordination of both data and program
>>>>objects.
>>>
>>> This is an implementation issue and it has nothing to do with the
>>> Relational Model.
>>
>>
>>This is a chicken and egg straw man. Surely the seeds of
>>the implementation are in the model prior to implementation,
>>just as the model is continually re-invoked to as the data
>>structures evolve over time, well after implementation.
>
> We don't need a new model to coordinate the applications with the
> DBMS, it is rather easy to do that with the existent computational
> models.

Do you have any references in regard to these computational models?

>>As is your traditional insistence to split theory
>>and implementation such that one is not really
>>concerned with the other.
>
> What I mean is that we can integrate both things when we want. There
> is not any theoretical problem.

When you say "we" you are speaking in the capacity of a specific role-type associated with a database system (See my recent post with a list of role-types). I would like to ask you which of these roletypes best summarises your perspective.

If this step is not taken, we might talk passed each other on every thread.

From your perspective of this role-type (yet to be defined by yourself) you perceive no problem, however I would not hesitate to point out that the integration of database and application software is a major problem for many organisations (hence use of external consultants).

>>>We only need to integrate database variables in the
>>> applications.
>>
>>
>>This is an efficient mechanism, and may be
>>milestones ahead of other solutions, but
>>it is not the end of the road to an
>>improvement of the current theory.
>
> But to integrate database objects with programming objects is all we
> need to integrate database objects with programming objects :)

Again, I suspect the "we" perspective here to be related to a specific solution or product related to the RDBMS rather than to the development and extention of database theory.

I will await your response to the above question concerning the formalisation of your POV according to a role from the list (or add one to it) associated with database systems.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Thu Apr 14 2005 - 13:45:47 CEST

Original text of this message