Re: Tree structure in Relational DB design

"--CELKO--" <71062.1056_at_compuserve.com> wrote in message news:c0d87ec0.0206110927.730e2ecd_at_posting.google.com...
> >> Wrong. The foreign key constraint declared in the create table will
> prevent
> any anomaly [updating 'Chuck' in multiple places].... The fact that a
> foreign key constraint, rather than a more complex general constraint,
> suffices to enforce integrity is a good indication that the design IS
> normalized. <<
>
> I agree that you can use declarative referential actions or triggers

Foreign key constraints are not triggers. They are constraints. Simple RI constraints.

> >> The redundancy is necessary for the foreign key and causes no
> update
> anomalies. <<
>
> Glad to see that you admit it is a redundancy <g> ...

Of course it is. Some redundancy is necessary and is inherent in the problem.

> >> One man's entity (employment_contract, for instance) is another
> man's
> relationship (employs / is employed by). The distinction is arbitrary
> and
> essentially meaningless. <<
>
> Having a contract and doing the work are two different things. The
> inability to tell the difference between an entity and a relationship

Actually, the inability to see that any difference is arbitrary and illusory will lead to bad design choices.

> >> Huh? A unique parent is the defining characteristic of a hierarchy.
> General
> inheritance graphs are DAGs, I believe. <<
>
> No, that's a tree, not a hierarchy. A hierarchy is a special case of
> a tree with some extra rules -- inheritance.

I disagree. Inheritance graphs are DAGs and not hierarchies. Damming a river deletes an entire sub-hierarchy while killing a sargent deletes a single node from a hierarchy that has deletion rules for how to adjust the graph back into a hierarchy. Received on Wed Jun 12 2002 - 02:54:31 CEST