If AB->C is an FD for a database then does that imply A->C

normalization

From below link on Functional Dependencies under FD Axioms(Armstrong's)

I came to know that
ab→ c does NOT imply a → c and b → c

But, when I was reading the book "An Introduction to Database Systems" by C.J.Date, on page 279, there is an example that tells about reduction of following set of FDs:

A -> BC
B -> C
A -> B
AB -> C
AC -> D

and under point number 3 of the reduction process it further mentions:
Next, we observe that the FD AB -> C can be eliminated, because again we have A -> C, so AB -> CB by augmentation, so AB -> C by decomposition.

So, that means that if A -> C, then we can imply AB -> C.

Assuming we are given the FD AB -> C in a separate case, then let us assume that A -> C, so AB -> C by above deduction, thus our assumption is true. Then, it proves the data in above link false! Is this mathematical approach not correct or I am wrong in a different way? Please throw some light on each perspective!

Best Answer

I came to know that ab → c does NOT imply a → c and b → c

Correct. It does not imply either.

....
So, that means that if A -> C, then we can imply AB -> C.

Yes, correct. but the following:

Assuming ... Is this mathematical approach not correct or I am wrong in a different way?

No, A -> C is deducted from A -> BC, not from AB -> C.

A -> BC is just a shorthand notation for A -> B and A -> C

Related Solutions

Ms-access – Does this database table violate normalization rules

#1. It took me a minute or two to find the problem. In it's current form, your WallContacts table requires one record per person per wall. So, if Joe is the owner of a building with 2 walls, he will need 2 records in WallContacts (one for each wall). This is because you're storing the WallID in that table.

Try this: Remove the WallID from WallContacts. Create a new table:

Table: Walls_vs_Contacts (I can't think of a better name)
ContactID (FK)
WallID (FK)

This table will serve as the go between between WallContacts and WallsMaster. So when creating queries, you join WallsMaster to Walls_vs_Contacts to WallContacts.

#2. A less important issue is that your WallInteraction doesn't include ContactID. Also, WallInteraction table can't properly record interactions between the staffmember and 2+ people. If this is an issue worth fixing (that's up to you to decide), you'd have to make an additional many-to-many table like in #1:

Table: Walls_vs_Contacts (I can't think of a better name)
ContactID (FK)
InteractionID (FK)

#3. Depending on how many staff members you have, you might want to make a table with a StaffID and StaffName fields. Otherwise, WallInteractions.Staffname will fill up with "Sheryl","Sherri","Sherryl LastName","S. Lastname", etc. making it impossible to search for all interactions involving her.

Otherwise, you're off to a solid start. I like how you identified and properly named the unique keys in advance. (Oh, and if you think I'm wrong, I probably am.)

Database Schema for an address book with different mailing lists

I would leave the data in a single table. Actually, the data is normalized now in the sense that you have a single Person table. That person is identified by a name, and the remaining columns are data about that Person. Each column depends on the name and varies with the name, which means it is already in 3NF. If you were building a large application, say a corporate application, then it might make sense to create tables for email, phone, address, etc. But since this is just a simple mailing list I would keep it one table. I don't think you have value in having a table for addresses or churches, for example, when neither of these have meaning to you other than as they relate to the current person.

Now if you had do have a lot of data about that address, or about that church, for example, then these "entities" would need to become tables to store the data about each address or church. Say your mailing list has the church name, church address, pastor, and average attendance. Now you have a reason to create a church table. You have columns - address, pastor, average attendence - that depend only on church name, not person name. But if all you have is church name there is really no benefit in this case of creating a church table that has just an id and a name.

One area where you might normalize would be to remove the repeating groups - the email(s) and phones(s) - into child tables. But you could also create multiple columns - say 3 for each - and I'm sure that would be plenty for this application. While not normalized, the only downside in doing this is if you need to store 4 (unlikely, and this is just a mailing list) you are out of luck. It also makes the query more complicated in that if you want to return all the phone numbers you have to select each column instead of joining to the child email table.

Bottom line is that normalization is about removing redundancy. It sounds like you have very little redundancy in the mailing list to begin with and breaking individual columns in the current mailing list into their own tables, if there is are no columns for those tables other than an id and a name, would be overkill.

Best Answer

Related Solutions

Ms-access – Does this database table violate normalization rules

Database Schema for an address book with different mailing lists

Related Question