Re: functional dependencies

Rohan Hathiwala wrote:

> Dear Larry Coon,
> I already know what a FD is my original question was
> something else,

That wasn't clear (to me at least) from your original question. Better to make sure the basics are understood, don't you think?

> however coming to the person table example that
> you have given me, I am not satisfied by it. The reason being that
> when you include the date of birth attribute the age becomes a
> derived arttribute and it is considerd bad practice to include
> derived attributes in a relation refer to Database System Concepts.

Correct, because it is a FD that in this case exists between non-key attributes, which violates 3NF. Granted I could have provided an example of an FD that was not also an example of a normalization violation, but since your question was about FDs and not normalization, I figured it didn't matter whether my example was normalized or not.

> Now I will give you an example that I think would illustrate
> FD's well.
> Consider a University where a Prof. is involved in several
> different projects and so he is able to take only one course per
> semester. Now for a pirticular sem if we make the following table
>
> create table Prof_activity{
> project_name varchar(20) primary key,
> prof_name varchar(20) NOT NULL,
> course_taught varchar(20) NOT NULL
> }
>
> In the above example we automatically have an FD i.e.
> prof_name -> course_taught and the prof_name can repeate itself
> across various tuples in the relation since he can be associated
> with various projects. I donot know why anyone would want to make
> the above table but it serves as a good example to explain a
> functional dependency as in the above case the course_taught
> attribute depends soley on the prof's personal interest and cannot
> be derived from a mathematical function. I would like to have your
> feedback on this.

Ah, now I see what you're saying. I didn't mean to imply that FDs exist ONLY in the mathematical or algorithmic sense, and I'm sorry if I gave that impression. That's the problem with Usenet posting -- a pointed response will necessarily leave out a lot of information.

We don't even need a transitive dependency (like you & I both used in our examples) to illustrate a FD. Consider the following:

create table person (
  social_security_no numeric(9) not null,   last_name varchar(20),
  primary key (social_security_number)
)

Here a FD exists (social_security_number -> last_name) which is not mathematical, not algebraic, not transitive, and not violating normalization rules.

Larry Coon
University of California
larry_at_assist.org
and lmcoon_at_home.com Received on Tue Jun 10 2003 - 22:20:54 CEST