Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Possible bridges between OO programming proponents and relational model
If I am not mistaken, the undelying idea behind *adjacency* you are
refering to is not at logical level but at physical level. set theory
(logical) is location independent but naturally it seems you are
considering it at physical level of implementation. My guess, is that
set theory is not a sufficient math tool for responding to question of
resource use and mutualization at physical level.
On such perpective, the notion of *distance* come handy because it may help solve resources issues onto representing economically relvars and allowing a better support of operations performed. Using vectorial representation for expressing relvars through multidimensional coordinate referentials may help optimize computing effort required to represent multidimensionnal variables because vectors are a mathematical tool that is particularily adapted to make a link between algebric set theory and spatial math that applies to implementation requirement.
JXStern wrote:
> On Mon, 05 Jun 2006 23:59:46 GMT, Bob Badour
> <bbadour_at_pei.sympatico.ca> wrote:
> >> So, what is the alternative to an "adjacency-only" RM?
> >
> >I once again object to the silly idea that the RM depends on location.
>
> RM depends on algebra if you like, set theory if you prefer.
>
> My comments about "adjacency" aren't meant to imply physical location,
> just an untyped (because supposedly universal) association. But
> "association" has too many connotations to use as the term, either.
>
> I might make the same protest against set theory itself, if set theory
> made the same pretense at domain representation that RM does. But
> everyone knows set theory is a low-level, if powerful (maybe even
> universal) tool. If that's all you see in RM, then fine. But I look
> at the idea of a normalized data model, and see an attempt to do
> something above and beyond a raw set theory, and in this attempt, it
> could use some new thinking, features, enhancements, extensibility,
> whatever.
>
> J.
Received on Tue Jun 06 2006 - 01:23:10 CDT