Results 1 to 2 of 2
  1. #1
    Join Date
    Dec 2012
    Posts
    1

    Functional Dependencies

    I'm currently learning about functional dependencies and am struggling to get my head around the concept behind them.

    Say I have the table:

    Customer

    Code:
    |-----------|--------------|------------|------------------|------------------|
    |Cust-ID    | Cust-FName   |Cust-LName  |Cust-Email        |Cust-Pw           |
    |-----------|--------------|------------|------------------|------------------|
    |1          |John          |Smith       |jsmith@email.com  |srt6564sdgjhy55y  |
    |2          |Adam          |Borneo      |adb@hotmail.com   |45657ythjdfgqAfd  |
    -------------------------------------------------------------------------------
    There are two candidate keys: cust-ID and cust-Email (only one email address may belong to one customer). Electing cust-ID as the P.K, would the only functional dependency be:

    Code:
    {Cust-ID} -> {Cust-FName, Cust-LName, Cust-Email, Cust-Pw}
    ?

    Or, would I draw/represent both candidate keys:

    Code:
    {Cust-ID} -> {Cust-FName, Cust-LName, Cust-Email, Cust-Pw}
    Code:
    {Cust-Email} -> {Cust-ID, Cust-FName, Cust-LName, Cust-Pw}
    ?

    Instincts tell me the former, but given this is a completely new topic I'd appreciate any help!

  2. #2
    Join Date
    Jan 2013
    Location
    Woodland Hills, CA
    Posts
    18
    functional dependency simply means when one attribute in a relation can be used to UNIQUELY determines another attribute. For example, assume that we have a customer entity with the following attributes:

    CUSTID
    LAST_NAME
    FIRST_NAME
    MIDDLE_INIT
    ADDR1
    ADDR2
    CITY
    STATE
    ZIP
    EMAIL_ADDR

    We can state the following:
    CUSTID -> LAST_NAME, FIRST_NAME, MIDDLE_INIT, ADDR1, ADDR2, CITY, STATE, ZIP, EMAIL_ADDR

    That is; given a CUSTID, we can uniquely determine the other attributes. In other words, given the CUSTID we can find the LAST_NAME attribute that belongs with this CUSTID along with the other attributes. Now take the example below:

    LAST_NAME -> CUSTID, FIRST_NAME, MIDDLE_INIT, ADDR1, ADDR2, CITY, STATE, ZIP, EMAIL_ADDR

    This is not valid functional dependency. The reason is that more than one customer can have the same last name but different CUSTID, FIRST_NAME, etc. For example, suppose you have "Jones" as the last name. There might be more than customer whose last name has the value "Jones". Since "Jones" cannot be used to uniquely identify a unique value for CUSTID in the relation (because which CUSTID would you be referring to?) it cannot be said that CUSTID or any of the other attributes for that matter are functionally dependent on LAST_NAME.

    Hope this clarifies things a little bit for you.

    YesAgile

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •