Re: Principle of Orthogonal Design



On 28 jan, 15:29, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> wrote:
"Jan Hidders" <hidd...@xxxxxxxxx> wrote in message

news:0a872b75-448e-4131-ba5b-6bcee88da815@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On 28 jan, 02:12, mAsterdam <mAster...@xxxxxxxxxxx> wrote:
Jan Hidders wrote:
mAsterdam wrote something very much like:
Pragmatical redefinitions must be temporary and tracked.
Sure, we agree on that.

<unsnip>

Wether the relation between heading and tuples goes
via names or ordering is relevant or not.

If it is not I want it out of scope.

</unsnip>

I don't think that it is possible to get it out of scope. If you think
it is, then by all means provide an equivalent and complete definition
where it is. I'm also not sure what your problem exactly is. We have a
definition that works for the named perspective, which is arguably the
most appropriate for the relational model anyway, so can we now
please, please, please, pretty please, move on with the discussion?

I don't think the definition is sufficient even for the named perspective:

Certainly. I think I already said earlier that there is a stronger
version that removes even more redundancy. But I wanted to wait a
little until mAsterdam had gotten his head around the current one.

consider

R1 {J, K}
    KEY {J}
    KEY {K}

R2 {J, A}
    KEY {J}
    FOREIGN KEY {J} REFERENCES R1

R3 {K, A}
    KEY {K}
    FOREIGN KEY {K} REFERENCES R1

Supposing that J, K and A have different types and discounting any meaning
attributed by relation names, there is overlap between R2 and R3.

J and K are both keys for R1, so J --> K and K --> J.

And due to the foreign keys between R2 and R1 and R3 and R1:

from J --> K and K --> A, J --> A can be inferred;
from K --> J and J --> A, K --> A can be inferred.

You can reason like that about FDs in the context of a single
relation, but you seem to do it here at schema level. What exactly
does it mean that J --> K holds at schema level? The only way I can
make sense of your statements is if you are working under the
universal relation assumption. Are you? Or are you perhaps assuming a
few extra dependencies you haven't told us about? Dependencies like
(R1 NJN R2)[K,A] = R3?

So, if there are tuples {j1, k1} in R1, {j1, a1} in R2, and {k1, a2} in R3,
the database is inconsistent due in my opinion to a POOD violation.

I think, therefore, that you need to adjust your definitions to reflect the
interactions between inclusion dependencies and functional dependencies.  I
think the closure of F union I is applicable here, where F is the set of all
functional dependencies and I is the set of all inclusion dependencies.

That was actually already implicit in my definitions. If I say "there
is a dependency" it means that either it is specified explicitly or
logically follows from those that are. But that doesn't really solve
the problem you identified. For that you need the following
redefinition of the POOD rule:

DEFINITION: A schema is said to violate POOD if there is a query Q
over that schema resulting in a relation with header H and in the
schema a relation R with a minimal join dependency with component C
such that there is a non-trivial ID Q[H] --> R[C].

To keep this practical Q should probably be restricted to conjunctive
queries, but in theory it could be any query.

-- Jan Hidders
.



Relevant Pages

  • Re: Apache2 & PHP5.0 Problems on Solaris 10
    ... PHP has lots of dependencies, ... Solaris bundled Apache, all current patch revisions, has ...   been compiled with largefile support (necessary to ...
    (comp.unix.solaris)
  • Re: cups and ghostscript recursive dependency problem
    ... tweaked its dependencies in the last 2-3 commits. ...
    (freebsd-questions)
  • Re: Sixth normal form
    ... if two projections are independent, as is the case when moving from ... cyclic pair of nclusion dependencies if you want the new schema to be ... And if you only want the new schema to ... {Whse, Item, TranId, RcvdDate, QtyRcvd, QtySold, Cost} ...
    (comp.databases.theory)
  • Re: Principle of Orthogonal Design
    ... FOREIGN KEY REFERENCES R1 ... but you seem to do it here at schema level. ... few extra dependencies you haven't told us about? ... interactions between inclusion dependencies and functional dependencies. ...
    (comp.databases.theory)
  • RE: Having trouble validating an existing XSD schema.
    ... this off with my current knowledge of the schema ... Identify all schema dependencies, because you will ... Biztalk copies the added schema into the current ... >> Here are the XSD schema source documents below. ...
    (microsoft.public.biztalk.general)

Quantcast