On Sun, 21 May 2000, Chris Bitmead wrote:
> Hannu Krosing wrote:
>
> > Chris, what is your position on having a single primary key for all
> > inherited columns ?
>
> What is the significance of a primary key compared to any old unique
> key?
For referential integrity, the REFERENCES or FOREIGN KEY clauses specify a
table name. That table is expected to have one and only one PRIMARY KEY. You
can't select which unque column you want to reference within a table - it must
be the one and only PRIMARY KEY.
I hope this is answering the question. :)
Multiple inheritance and referential integrity are a complex mix. It becomes
hard for the database to maintain data integrity and uphold the relational
model that is based on functional dependency where one set of atomic values
are determined by a key or composite key containing attributes that are not
functionally dependent on each other. With multiple inheritance, it is easy to
end up with two separate keys determining the same data, which is a conflict if
they are not a composite key. Something like that.
The EXTENDS type of inheritance is single-inheritance compatible. This is what
I think SQL3 is allowing. It allows you to make a hierarchy tree out of
tables. Only one primary key can possibly be inherited. A subtable is
forbidden from specifying its own primary key - it must inherit one.
The CLONES and ASSIMILATES stuff that I mentioned before, would require some
restrictions to ensure they don't break the relational model data intergrity
enforcement infrastructure (primary keys/foreign keys etc). For example, to
multiple inherit, it would maybe be required that the inherited table have an
inherited primary key consisting of the composite of all inherited keys. If it
inherits no primary key, then it is free to specify one for itself. But
remember, that CLONE just branches off from its parents,
who are not connected to child so that eases things a litte for that case.
ASSIMILATES is more complicated, and is not possible to compare it even with
anything you can do in a programming language since a child can exist after a
parent class has been dropped. I'd have to think about CLONES and ASSIMILATES
more since they multiple inherit.
I looks like SQL3 has taken care of the EXTENDS type for us.
Attached is a diagram of the way UNDER appears to work in SQL3. The second
gif is a rough idea of how I think INHERITS/CLONES might work. The 3rd pic is
about the assimilate inheritance idea, which is half baked but maybe somwhat
interesting.
--
Robert B. Easter
reaster@comptechnews.com
