Re: Why not many2one with pk array type

From: x <x_at_not-exists.org>
Date: Mon, 30 Jan 2006 16:04:04 +0200
Message-ID: <drl6cr$2il$1_at_domitilla.aioe.org>

How about many to many ?

r1(a pk,b)
r2(c pk,d)
r3(a,c)

Would you design this as
r1(a pk,b, set(c))
r2(c pk,d)
or as
r1(a pk,b)
r2(c pk,d, set(a)) ?
What if the relation r3 has some other attributes, say e,f,g ?

The many to one design is:

r1(a pk ,b )
r2(c pk, d )
r3(a pk, c)

You can look at r3 as r3(a, c) or as r3(c,a). It doesn't matter. If some constraints are in place, one can join r1 and r3 in r13 and use it as a base relation:
r13(a pk, b , c)
r2(c pk,d)
Again you are free to look at r13(a,c) or at r13(c,a). If you want to look at all the information from the parent and the child node, you are free to look at r123(a,b,c,d)=r13 join r2 on c.

Are you talking about data in a DBMS or about the mismatch of data structure when interfacing with other software components ? In the latter case no one is stopping you to use the same model for the other software components or/and to write a translator between the two models.
Using the relational model, all your data become explicit and you gain a vocabulary for talking about it from which you can start building.

You may argue that the relational model is too powerful for building GUI interfaces and you don't want to build a translator :-) Received on Mon Jan 30 2006 - 15:04:04 CET