Re: A different definition of MINUS, part 4
From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 31 Dec 2008 12:55:26 -0800
Message-ID: <MZQ6l.82404$X05.41903_at_newsfe03.iad>
>
> I assumed the square brackets are project and the braces are set
> notation for the set of attributes in each tuple. Obviously, the
> notation is ill-defined and incomplete so one has to make all sorts of
> suppositions to pretend to see anything meaningful in the example. See
> Date's _Principle of Incoherence_.
>
> The key constraints are just additional constraints. If something else
> were used as the key, one would have different example schemas.
>
> The constraint equation in scheme 2 is a necessary constraint for
> equivalence between the two schemas. Without that constraint, the two
> schemas are logically different schemas. And: "Logical differences are
> ___ differences." Come on, everyone! Join in!
>
> Are you familiar with Fabian's observations regarding 'denormalization
> for performance' ? He observes that such 'denormalized' schemas are
> slower if one actually declares the constraints; thereby suggesting any
> performance difference comes at the cost of integrity.
>
> By the same token, without the constraint equation in scheme 2, the two
> schemas are logically different, and I doubt anyone is silly enough to
> suggest logical data independence requires logically different things to
> be the same in any way.
Date: Wed, 31 Dec 2008 12:55:26 -0800
Message-ID: <MZQ6l.82404$X05.41903_at_newsfe03.iad>
Bob Badour wrote:
> paul c wrote:
>
>> Bob Badour wrote: >> >>> paul c wrote: >>> >>>> Brian Selzer wrote: >> >> ... >> >>>>> equivalent. What that means is that for a view to be >>>>> uncontingently updatable, there has to be an equivalent database >>>>> scheme in which the heading of a base relation matches the heading >>>>> of the view. For example, suppose you have two database schemes >>>>> >>>>> scheme 1: >>>>> >>>>> EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID} >>> >>> >>> Scheme 1 is incomplete. >>> >>> scheme 1: >>> >>> EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID} >>> EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE] >>> EMP2 = EMPLOYEE[EMPID, SSAN] >>> >>> >>>>> scheme 2: >>>>> >>>>> EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and >>>>> EMP2 {EMPID, SSAN} KEY{EMPID} such that >>>>> EMP1[EMPID] = EMP2[EMPID] >>>>> EMPLOYEE = EMP1 JOIN EMP2 >>>>> >>>>> Here the circular inclusion dependency guarantees that any update >>>>> through the EMPLOYEE view can be transformed into a legal set of >>>>> updates against EMP1 and EMP2. >>>>> >>>>> I don't see how anything short of schema equivalence could be >>>>> permitted--for instance, relaxing the circular inclusion >>>>> dependency--without changing the information content of the database. >> >> ... >> >>> In scheme 1 above, we have our base relation declaration(s) and two >>> view equations. In scheme 2 above, we have our base relation >>> declaration(s) and two equations: one constraint equation and one >>> view equation. >>> >>> I agree logical independence demands we be able to use either scheme >>> equally without having any concern for which sheme we actually have. >> >> My question would be why is there any mention of 'KEY' and why the >> constraint equation in scheme 2? How do they change the presumably >> desired 'equivalence' of being able to update either through EMP1 and >> EMP2 or through EMPLOYEE? >> >> (unless there is some difference between the braces and square >> brackets that eludes me). >> >> I don't say there is anything 'wrong' here that results from including >> keys, I would like to know why that is presumably necessary. If that >> is necessary, does it mean that some other key than EMPID, say {EMPID, >> SSAN} is somehow wrong or unnecessary?
>
> I assumed the square brackets are project and the braces are set
> notation for the set of attributes in each tuple. Obviously, the
> notation is ill-defined and incomplete so one has to make all sorts of
> suppositions to pretend to see anything meaningful in the example. See
> Date's _Principle of Incoherence_.
>
> The key constraints are just additional constraints. If something else
> were used as the key, one would have different example schemas.
>
> The constraint equation in scheme 2 is a necessary constraint for
> equivalence between the two schemas. Without that constraint, the two
> schemas are logically different schemas. And: "Logical differences are
> ___ differences." Come on, everyone! Join in!
>
> Are you familiar with Fabian's observations regarding 'denormalization
> for performance' ? He observes that such 'denormalized' schemas are
> slower if one actually declares the constraints; thereby suggesting any
> performance difference comes at the cost of integrity.
>
> By the same token, without the constraint equation in scheme 2, the two
> schemas are logically different, and I doubt anyone is silly enough to
> suggest logical data independence requires logically different things to
> be the same in any way.
Okay, let's take a step back. Start with EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN}. Tell the dbms it's 'base' (or 'green' for all I care, ha, ha). Right off the bat, we know that:
EMPLOYEE {EMPID} = EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} JOIN EMPLOYEE {EMPID} We don't need to assert this, the algebraic rules imply it. It is about as fundamental a constraint as they come. The dbms should obey it.
We don't need keys to make this point: now tell the dbms that the projection, EMPLOYEE {EMPID}, is 'base'. Give a prize to the dbms designer whose product doesn't discard the constraint when it hasn't been 'told' to. Received on Wed Dec 31 2008 - 21:55:26 CET