Re: constraints in algebra instead of calculus

Brian Selzer wrote:

> "paul c" <toledobythesea_at_oohay.ac> wrote in message 
> news:JQ94i.200044$DE1.108062_at_pd7urf2no...
> 

> 
> 
> There is a paper by Mark Levene and Millist W. Vincent, "Justification for 
> Inclusion Dependency Normal Form."  In it they argue that a database schema 
> should be free of circular inclusion dependencies and should only contain 
> key-based inclusion dependencies (which are as far as I can tell from their 
> definition, foreign key constraints)
> ... 

What is their argument?

> An inclusion dependency that is not also a foreign key constraint denotes a > many-to-many relationship, ...

Not necessarily. My attitude is very much from an engine perspective where the feature definitions ought to be as elemental as possible. This shouldn't stop somebody who is using a product that has a hard time with circular dependencies from using a so-called catalog who doesn't want them for stylistic reasons from preventing their definition.

In my view, the candidate key aspect is a second constraint, combining the two in one "foreign key" directive buys nothing since anytime the reference is not to a key, another directive would be needed anyway. When Dave P says the reason is historical, I'm sure he's right, but the biggest lesson of history, if you ask me, is that it as much as not shows why we shouldn't always follow history. Somewhere, Hugh Darwen argued for the deprecation of the term "foreign key" - I think I'm with him. Of course, I would hope an ideal dbms would allow simple macro-ization for users who want to combine features with their own choice of constraint keyword.

Here is a quote from my possibly inaccurate echo of Darwen's example that I sent in a another thread:

(quote)
Student { StudentId, Name } KEY { StudentId } Course { CourseId, Title } KEY { CourseId } Staff { StaffId, Name } KEY { StaffId }

Teaches { StaffId, CourseId } KEY { StaffId }

(note that a teacher may teach only one course, the argument depends on this)

Enrolment { StudentId, CourseId } KEY { StudentId, CourseId }

(note also that a student may take many courses and that a student may enrol in a course before a teacher is assigned to it)

TutorFor { StudentId, StaffId } KEY { StudentId, StaffId }

It's possible to enter a row in TutorFor where StaffID stands for a teacher who doesn't teach any course the student is enrolled in. If I understand the argument it is that it would be simpler/easier for an implementation if the system allowed a foreign key F1 (StudentId,StaffId) for TutorFor referencing the join of Enrolment and TutorFor, eg., the view V={StudentId,StaffId,CourseId} where V is constrained by its own foreign key F2 (StaffId,CourseId) referencing Teaches. If I've got this right, the schema is in BCNF, but neither F1 or F2 references a key.
(end quote)

Sorry for the long post about something so basic, but no apology for talking about basics!

p Received on Tue May 22 2007 - 01:58:11 CEST