RE: The Third Manefesto
- From: "Henry Poras" <henry@xxxxxxxxxxxxxxx>
- To: <lex.de.haan@xxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 21 Jul 2005 10:49:31 -0400
Thanks Lex,
That's what I was thinking. Taking a few more tentative steps (as I
mentioned, I plan to add detail and confidence as I give myself more
pondering time), let me start by correcting the spelling of the book title
:) (I meant The Third Manifesto).
Rough picture with a bit of handwaving (it took me years to be able to type
and handwave simultaneously). There are a number of ways to model data. It
can be modeled relationally (and given a reasonably complex system the
logical representation is not unique. I can come up with more than one
relational model). It can be modeled with an Object Oriented representation.
Relational databases and database management systems have the nice features
of transactions, ad hoc queries, and a certain amount of data integrity
built in through normalization. A lot of developers and development tools
use the object representation.
There has always been a struggle mapping from an object oriented
representation to a relational representation. One thing Date has shown is
that objects can be accomodated naturally within a relational model by
representing the object class as a type/domain. (Don't map object classes to
relvars). This should make the mapping between the object world and the
relational world much cleaner and easier.
However, (and this is where more of the handwaving comes in), it appears
that doing so removes some of the nice features typically inherent in a
relational model. We have already mentioned Referential Integrity
constraints. That level of data integrity enforcement seems to be gone.
There also seems to be a conflict between 1st and 3rd normal form. Say you
have an employee type which contains an attribute (I don't think this is the
right word, but I'm not sure what is) of address. Address contains city and
zip which are dependent on one another. You woudn't have a relational table
of empno, ename, city, zip. But since the employee type (object) is atomic,
you don't worry about the city/zip redundancies (it's atomic, not
encapsulated. You can still see the granularity of the data within the
type).
Wait a second. You can nest types in types, so [city, zip] can be of a
PostOfficeCode type which is a domain containing all valid city, zip
combinations. That still doesn't solve the FK issue, however.
Henry
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Lex de Haan
Sent: Wednesday, July 20, 2005 4:03 AM
To: lex.de.haan@xxxxxxxxxxxxxx; henry@xxxxxxxxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: RE: The Third Manefesto
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
