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

"erk" <eric.kaun_at_gmail.com> wrote in message news:1113399979.268750.316550_at_l41g2000cwc.googlegroups.com...
> mountain man wrote:
>> Central constraint enforcement should be in the database
>> and not in the traditional program objects, this is a "given".
>
> Agreed.
>
>> Assume this practice is adhered to, what other relationships
>> exist between the relational model of the data and those
>> program objects which routinely manipulate this data?
>
> I would infer that the languages used for the program objects would
> benefit from relations as first-class entities.

Such as that found within SQL?

>> Common physical storage of data and program "objects"
>> hints that there exists potential to define some form of
>> common logical storage.
>
> I disagree. Common physical storage hints at nothing that I can imagine
> useful - surely there are "models" of file systems already, and other
> storage types as well? How physical do you mean - magnetic fields,
> bits, bytes, files?

What I mean is that the physical database file written by the modern (R)DBMS software now includes both the data and all stored procedures associated with the data.

>> The model would address this
>> commonality of logic, rather than restrict itself to the logic
>> of the data objects alone.
>
> Data objects have no logic, though logic can be used to manipulate
> them.
>
>> > It's not an assertion, it's true by definition (modulo the original
> use
>> > of relation in mathematics).
>>
>> A truth-definition is a simply another form of assertion
>> in which the degree of confidence is set at a max.
>>
>> However you care to dress it up,
>> it is still an assertion.
>
> So by earlier saying "I don't share the assertion [that SQL DBMSs
> aren't relational]" you mean to redefine "relational"? Why?

SQL DBMS's can be made automatically optimally "relational" by that application of common sense management. Codd's 12 Rules can be met on the ground of implementation, although this may be a foreign concept to many theorists.

So I dont need to redefine "relational".

However I do mean to redefine the scope of the "model of data" such that it has the ability to encompass not just the data, but also the processes associated with that data, which are already being stored by modern database management systems as stored procedures.

>> > Given that this is a theory group, I think
>> > definitions are important. Not that they're not important outside
>> > theory...
>>
>> Theory evolves, hopefully in pace with the technology.
>> Also, no discipline is insular - an island unto itself.
>
> Agreed, but technological (implementation) advances don't necessarily
> have any impact on theory. Some do, but usually when the technology
> advance is the result of a possibly implicit theoretical change.

You might argue that before database management system software was available, there existed a theory for it. The question might be then put to you as to whether advances in those DBMS s/w, and large advances in services provided - including internal SQL and the appearance of separately addressable stored procedures are appropriate advances to incorporate into DBMS theory - in general terms.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Sat Apr 16 2005 - 14:19:38 CEST