Home/ Questions/Q 3627688
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T23:55:12+00:00

someone told me the following table isn’t fit for the second database normalization. but

  • 0

someone told me the following table isn’t fit for the second database normalization. but i don’t know why? i am a newbie of database design, i have read some tutorials of the 3NF. but to the 2NF and 3NF, i can’t understand them well. expect someone can explain it for me. thank you, 

    +------------+-----------+-------------------+
    pk                pk             row
  +------------+-----------+-------------------+
      A                  B                  C
   +------------+-----------+-------------------+
        A                  D                  C
 +------------+-----------+-------------------+
          A                  E                  C
  +------------+-----------+-------------------+
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    About your example: that table doesn’t fit the second database normalization (with your sample data, I presume that the C depends only on A). The second normalization form requires that:

    No non-prime attribute in the table is functionally dependent on a

    proper subset of a candidate key
    (Wikipedia)

    So the C depends on “A”, which is a subset of your primary key. Your primary key is a special superkey. (dportas point out the fact that it can’t be called candidate key, since it’s not minimal).

    Let’s say more about the second normalization form. Transform your example a little for easy understanding, presume that there’s a table CUSTOMER(customer_id, customer_name, address). A super key is a sub-set of your properties which uniquely determine a tube. In this case, there are 3 super key: (customer_id) ; (customer_id, customer_name) ; (customer_id, customer_name, address). (Customer name may be the same for 2 people)

    In your case, you have determined (customer_id, customer_name) be the Primary Key. It violated the second form rules; since it only needs customer_id to determine uniquely a tube in your database. For the sake of theory accuration, the problem here raised from the choice of primary key(it’s not a candidate key), though the same argument can be applied to show the redundance. You may find some useful example here.

    The third normal form states that:

    Every non-prime attribute is
    non-transitively dependent on every
    candidate key in the table

    Let give it an example. Changing the previous table to fit the second form, now we have the table CUSTOMER(customer_id,customer_name, city, postal_code), with customer_id is primary key.

    Clearly enough, “postal_code” depends on the “city” of customer. This is where it violated the third rule: postal_code depends on city, city depends on customer_id. That means postal_code transitively depends on customer_id, so that table doesn’t fit the third normal form.

    To correct it, we need to eliminate the transitive dependence. So we split the table into 2 table: CUSTOMER(customer_id, customer_name, city) and CITY(city, postal_code). This prevent the redundance of having too many tubes with the same city & postal_code.

    • 0