Re: Principle of Orthogonal Design
Date: Fri, 18 Jan 2008 15:23:38 +0100
Jan Hidders wrote:
> JOG wrote:
>> Jan Hidders wrote: >>> Brian Selzer wrote: >>>> This calls into question the idea that it should >>>> be possible to determine which relation an inserted tuple is destined for. >>> Apologies for being lazy, but could someone explain to me in a >>> nutshell why this should be possible at all? At first sight this looks >>> like complete nonsense to me. >> Well, as far as I gather, being able to determine a unique predicate >> for any proposition being inserted into the database is desirable in >> order to allow view updates to be more easily be translated to changes >> in underlying base relations. >> >> I cannot claim to fully understand the reasoning behind this, but view >> updating hence appears to have been POOD's underlying motivation. >> There is a relatively old draft paper by Date and McGoveran at living >> athttp://www.dbdebunk.com/page/page/622331.htmwhich might be more >> illuminating.
> It mentions the view update problem but doesn't really explain how it
> is connected.
> Anyway, the stronger POOD that requires that headers are distinct
> sounds like nonsense to me. Why would R(A, B) be a worse design than
> R(R_A, R_B)?
> The weaker POOD looks more interesting to me. I even found a published
> paper about it:
Unfortunately the link times out.
> What's interesting is that it seems to address the problem of
> normalization at the schema level, so not just restricted to one
> relation, as is usual in normalization theory. You might even
> formulate a new normal form at that level:
> A schema is said to be in HNF if all database dependencies follow
> logically from the dependencies at relation level (so domain, tuple
> and relation constraints) and the inclusion dependencies.
> So basically it says that inclusion dependencies are the only needed
> dependencies at database level. Note the similarity with 5NF (all join
> dependencies logically follow from the key dependencies) which says
> that the key constraints are the only needed constraints at relation
> level. That similarity is not a coincidence. In both cases we are
> eliminating redundancy. To get to a real normalization theory you
> would have to identify more concretely the type of database
> constraints / dependencies we are talking about.
> What POOD has to do with HNF is left to the reader as an exercise. ;-)
-- What you see depends on where you stand.Received on Fri Jan 18 2008 - 15:23:38 CET