RE: The Third Manefesto
- From: "Lex de Haan" <lex.de.haan@xxxxxxxxxxxxxx>
- To: <lex.de.haan@xxxxxxxxxxxxxx>, <henry@xxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 20 Jul 2005 10:02:49 +0200
sorry Henri,
when reading my own reply and your original question, I now see I was
incomplete. undskyld.
foreign keys. well, there is no such simple concept anymore in your case --
because indeed, which attribute should the foreign key refer to? this means
that this foreign key constraint must be expressed as an assertion. as we
probably all agree, not a good idea -- so having a "good old" employees relvar
with separate attributes (empno, ename, sal, ...) is not that stupid after all
:-)
kind regards,
Lex.
------------------------------------------------------------------
Steve Adams Seminar http://www.naturaljoin.nl/events/seminars.html
------------------------------------------------------------------
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Lex de Haan
Sent: Wednesday, July 20, 2005 09:55
To: henry@xxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: The Third Manefesto
Hi Henri,
I think the two issues are orthogonal. every relvar is based on a set of
attributes, and every attribute is associated with a type. that is, a type of
arbitrary complexity. so indeed, you can "hide" or encapsulate several employee
properties into a single attribute if you like.
regardless how complicated you choose your relvar attributes, once that exercise
is done you must assign (candidate) keys for that relvar. a candidate key is
just a subset of the relvar heading (and the heading is the set of attributes)
with the property that it uniquely identifies every tuple. well, a trivial key
is the heading itself -- and if your relvar only has one attribute, that
attribute *must* be the key ...
hope this helps,
kind regards,
Lex.
------------------------------------------------------------------
Steve Adams Seminar http://www.naturaljoin.nl/events/seminars.html
------------------------------------------------------------------
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Henry Poras
Sent: Wednesday, July 20, 2005 08:17
To: oracle-l@xxxxxxxxxxxxx
Subject: The Third Manefesto
I'm almost done reading Date's book. I have a bunch of questions and need to
reread and think about a number of sections. There is one basic question,
though, where I am convinced I must be missing something.
How do you apply Foreign Keys if relations are defined using relational types?
One example given by Date is logically representing employee data either in a
relation variable (EMP) with attributes empno, ename, deptno, ...
OR by defining a type emp(empno, ename, deptno, ...). This type is then the data
type (domain) of an EMP relvar. The second relation is thus effectively a set of
employee objects.
I see how joins can be done in the second case (use a built-in funtion
THE_DEPTNO(emp) which will extract the deptno value from each tuple), but what
about a foreign key on DEPTNO?
If I read this in the morning and the question is as unclear as I suppose it is,
I'll expound on this.
Henry
--
//www.freelists.org/webpage/oracle-l
BEGIN:VCARD
VERSION:2.1
N:de Haan;Lex
FN:Lex de Haan
ORG:Natural Join B.V.
TEL;WORK;VOICE:+31.30.2515022
TEL;HOME;VOICE:+31.30.2518795
TEL;CELL;VOICE:+31.62.2955714
TEL;WORK;FAX:+31.30.2523366
ADR;WORK:;;Pieter Breughelstraat 10;Utrecht;;3583 SK;Netherlands
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Pieter Breughelstraat 10=0D=0AUtrecht 3583
SK=0D=0ANetherlands
URL;WORK:http://www.naturaljoin.nl
EMAIL;PREF;INTERNET:lex.de.haan@xxxxxxxxxxxxxx
REV:20040224T160439Z
END:VCARD
Other related posts:
