Re: Functional Dependencies > Uniqueness Constraints

Jan Hidders wrote:
> Marshall wrote:
> > Geeze, it's deader than a dotcom startup in here.
> >
> > Okay, fine. I propose that a good relational DBMS should
> > not have any special feature for enforcing uniqueness constraints.
> > Instead, it should be able to record and enforce functional
> > dependencies.
>
> Obviously a DBMS that can express general FDs can express more than one
> that can just express CKs, except if you alway normalize to BCNF. But
> that doesn't mean there shouldn't be a special notion of CK.

Special notion or special notation?

Further, we have also to consider views and even just query results. So even if we *require* base tables to be in BCNF, we're still going to see relations in which CKs are not sufficiently expressive.

> Determining if a set of fields is a CK on the basis of the known FDs is
> actually an NP-complete problem, so if the user is so kind to indicate
> them explicitly that is useful. :-)

Hmmm. That doesn't seem right to me. (Although in an issue like this, were I a betting man, my money would be on you.)

Wait, isn't it the case that all we really care about is *whether* we have a candidate key? At least logically I don't see why we'd need any more. And at the physical level, it seems to me that what you really want is the FDs themselves. Am I missing something?

It would be my expectation that I could take a user-supplied set of FDs and reduce it to an irreducible set fairly easily. Once I have that, I can determine *whether* I have at least one key again fairly easily. Further, the number of FDs and the number of attributes are typically going to be pretty small numbers, wouldn't you think?

Perhaps I'm missing something, but I don't see the hard in here. Maybe I should try to code it up.

I must be missing something.

Marshall Received on Wed Aug 30 2006 - 16:37:05 CEST