Re: constraints in algebra instead of calculus

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.

(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.

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 - 03:01:07 CEST