Re: In an RDBMS, what does "Data" mean?

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:o6Qd1REvhApAFwUO_at_thewolery.demon.co.uk...

...[trim sci.physics thread] ...

> Okay. So what is "data". Because if we can't anchor that in the real
> world, we have no way of knowing if, or how strongly, relational theory
> is relevant (and usable) in the real world.

Relational theory is useful and relevant. For the people who are database academics, database technical, indeed anything database-centric, the theory is generally all they need and require to do what they do (within E2 below)

There are 3 software environments:

E1 = Operating system and network os layer
E2 = RDBMS layer
E3 = application layer

The "data" is bound within E2, and although is operated on within E2 (hopefully in accordance with the RM), the ultimate control for these operations are from the end user within an organisation, via the app layer (E3). (GIGO)

However in the real world the data within the RDBMS is in fact owned by an organisation, not by the RDBMS vendor, nor the application vendor/developer, nor the RM, and in reality only has meaningful context for that organisation, at that instant in space & time. (production data backup)

[An aside: now I can see where the physics thread may have become self-emergent ;-]

The RM does not reflect the actuality of the above, nor make any provision for the management of the E3 layer because it is not yet completely evolved.

The catch-cry "the RM is just as applicable to database systems today, as it was in the early 1980's" should be taken as an indication that something is wrong with it as a pedagogic device for 2004.

The reason for this is that E2 and E3 have changed alot since 1980, particularly E2, the RDBMS software. Due to the emergence of addressable stored procedures in the RDBMS, there has been an effective "migration" of intelligence (code) from E3 to E2.

The boundaries between E2 and E3 are now probably best described as fractal, whereas in the past they were heavily demarked.

Back to your question on the "data". It is physically anchored by a backup, and theoretically anchored by the database schema, constraints, etc. from the perspective of the (incomplete) RM.

However in practice, it is a dynamic fluid element that must be managed, with the assistance of, but also outside the realm of the present applicability of the RM.

Change management is the name given to the bag that holds together everything that falls through the cracks of theory and out into the world of practice.

Pete Brown
Falls Creek
Oz Received on Sat May 15 2004 - 18:43:43 CEST