Re: constraints in algebra instead of calculus

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:nnM4i.206459$DE1.56863_at_pd7urf2no...
> Brian Selzer wrote:
>> ...
>> V is not in BCNF: since StaffId --> CourseId in Teaches, StaffId -->
>> CourseId in V.
>> ...
>
> I'll think about your other points, it could be that I misunderstood his
> point - meanwhile, I must say I'm not too concerned about V's 'form' as I
> think he used it just to make his exposition clearer - in a suitable
> language, I would guess, one would not be forced to define a view in order
> to express the constraint.
>

Sometimes it makes them more succinct. There is danger, however. I don't think it's decidable how a constraint defined on an arbitrary view affects the closure of the set of constraints on the database schema. Can a constraint defined on a view always be a logical consequence of a set of constraints defined on the underlying base relations? I don't think so.

> (I must also admit that I've never been much bothered with problems that
> have to do with making views 'the same' as base tables,
>
> eg., 1) normalizing them, because it is the base tables that all else
> springs from and it is and redundancy in the base tables that I care
> about, not ones in an arbitrary view, and I don't see why FD's matter when
> it comes to views and when it comes to base tables/relvars, I don't
> believe that update 'anomalies' are possible, unless the base is
> mis-stated in the first place.
>

I agree, for the most part. I would only add that redundancy can occur across relation boundaries. That's what the Principle of Orthogonal Design is all about. In addition, redundancy can occur between relations. In the example you provided, F2 references a superkey. Now, granted, V is a view, but in general, if an inclusion dependency, A[S] in B[S], references a superkey that is not also a key, then there is at least one nontrivial functional dependency contained within the set of attributes that binds the two relations. As a result, the schema {A', B | A'[K] in B[K]} where K a superkey for B that is a proper subset of S and A' = A[ALL BUT (S - K)] is equivalent to (can contain the same information as) the original schema {A, B | A[S] in B[S]}; therefore, the original schema is redundant.

> eg., 2) when it comes to updating, I'm happy to distribute the 'or' or
> 'and' over the expression that defines the view. If these attitudes mean
> that some users must be aware that they are operating on a 'view', ie.,
> expression that involves several relations, so be it.)
>
> p
Received on Wed May 23 2007 - 07:52:34 CEST