The connection between objects and databases seems to be a recurring
theme here on c.d.t, so I'd like to contribute one observation.
Consider a Substring relation:

Substring
=======
data | fragment
-------------------
abab | ab
abc | ab
abc | bc
.....

This is pretty unintersting relation until we add more attributes: the
"from" and "to" indicating the position of the fragment inside the
data, and "#" -- the occurence number. (All numbers are 0-based,
intervals boudaries are including-excluding). The example becomes:

Substring
=======
data | fragment | from | to | #
------------------------------------
abab | ab | 0 | 2 | 0
abab | ab | 2 | 4 | 1
abc | ab | 0 | 2 | 0
abc | bc | 1 | 3 | 0
.....

There are at least 3 functional dependencies:
fragment, from -> to
data, fragment, # -> from
data, from, to -> fragment

Informally these FDs correspond to the length(), instr(), and substr()
functions. So instead of talking about the class String with the
length(), instr(), and substr() member functions, we can focus on a
relation and functional dependencies....

Tegiri Nenashi wrote:

[...]

Certainly. But we can't describe the full semantics of strings
in that way. How do you represent concatenation?

Another difference is that database tables are finite and variable,
while the set of strings is infinite and fixed. But your idea is used
in theoretical papers, where concrete domains are sometimes introduced
in terms of fixed infinite tables.

--
Reinier Post
TU Eindhoven

On Dec 6, 9:40 am, rp... (AT) pcwin518 (DOT) campus.tue.nl (rpost) wrote:
That was not the right representation, consider the relation:

str | prefix | suffix | pos
-----------------------------
abcd | ab | cd | 2
abac | ab | ac | 2
.....

Functional dependencies:
prefix & suffix -> str (corresponds to concatenation)
prefix -> pos (length)
str, pos -> prefix (prefix substring operation)
str, pos -> suffix (suffix substring operation)

The combination of the latter two (first extract suffix, and then
extract prefix) is the usual substring operation: substring(str, pos,
length).

Question: how do we represent the "instr" operator?

Oh, relations in database world are certainly not restricted by finite
cardinality.

Tegiri Nenashi wrote:
I thought that computers are finite, so the relations containable in
them are too - even if damn large. There's a big difference between
very large and infinite.

One ultimate limitation is the uniqueness requirement. Suppose you have
a table with two integer columns. Since the range of the integer types
are finite (even if your DBMS handles multi-precision integers), then
the maximum number of distinct rows in the relation is also finite.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/

publictimestamp.org/ptb/PTB-1963 whirlpool 2007-12-06 21:00:03
7275FCF2EDF20725F56D081C5528272FCD717970FCEE5D43ED E454007D35AD3E246B5C
FA6134D8AD5E2A60C6F43508ADFAE3E632D92807ED38395BFD 14DA3EA

On Dec 6, 2:38 pm, Jonathan Leffler <jleff... (AT) earthlink (DOT) net> wrote:
This doesn't really matter. You can still reason about infinite
relations with finite resources available on you computer platform.

All computer algebra systems work with numbers which are not
restricted by a whim of hardware architects. 16/32/64 bit integer
numbers (let alone floats)? give me a break!

On Dec 6, 10:15 am, Tegiri Nenashi <TegiriNena... (AT) gmail (DOT) com> wrote:
Neither is it restricted to variables--not only in papers and in
theory
but in practical terms.


Marshall

On Dec 6, 4:24 pm, Tegiri Nenashi <TegiriNena... (AT) gmail (DOT) com> wrote:
In fact, it is quite possible to treat n-bit "integers" in an
algebraically pleasant way: as the ring of integers mod 2^n.


Marshall

On Dec 6, 7:54 pm, paul c <toledobythe... (AT) ooyah (DOT) ac> wrote:
Well, if nothing else, we can certainly consider relation constants.
DUM and DEE are certainly useful, and of course those are constants,
not variables.

I also don't see anything wrong with considering, say, addition on
arbitrary sized integers as an infinite relation, and reasoning about
it accordingly. Yes, there are machine resource limits, but that
doesn't have to limit our reasoning.

Also, I am working right now on the idea of a relational logic, so
I spend a certain amount of time thinking about equations with
table variables that I don't know much about. Sometimes not
even the predicate.

I guess drifting the theme is something I do a lot. :-)


Marshall

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in
news:cd2ad8bd-78ca-433d-bc0f-3e7ef0c0fe2a (AT) e6g2000prf (DOT) googlegroups.com:

You can do that with your brain...

with finite resources available on you computer platform.

but not with that. The computer is an intrinsically finite gadget.
Therefore, you'd better use the finite model apparatus to reason about
things like the impossibility of expessing transitive closure in the
relational algebra. A lot of stuff like the compactness theorem does
not work with finite models which makes infinite model proofs
inapplicable in the finite case.


Jonathan is of course right, the set of 'floats' is clearly finite that
somewhat clumsily approximates real numbers !

On Dec 8, 8:05 pm, "V.J. Kumar" <vjkm... (AT) gmail (DOT) com> wrote:
You fail.


Marshall