Re: Understanding candidate key and super key

From: <joe_celko_at_my-deja.com>
Date: 2000/03/05
Message-ID: <89sk1p$8hn$1_at_nnrp1.deja.com>#1/1


>>

 The table will be as follows:

     Lecturer    Subject    Telephone
         x                a                1
         y                a                1
         y                b                2
         z                b                1
<<

Given this data, yes, it looks like these are keys. However, if you were to add the row (x, a, 2) which is legal under your functional dependencies, and (lecturer, subject) is not a key. Likewise, add thwe row (y, b, 1) and (lecturer, telephone) is not a key. All three columns will always be a super key becuase it is made up up of all the rows in the table.

However, subjects and telephones have no relationship to each other, so you should normalized the schema as two tables. A better exmapel of what you are trying to do is an example I had in my book SQL FOR SMARTIES, whichwas made up of (teacher, classroom, period, subject); any three columns determined the other one.

--CELKO-- Sent via Deja.com http://www.deja.com/
Before you buy. Received on Sun Mar 05 2000 - 00:00:00 CET

Original text of this message