Functional dependencies, part 2
Thank you, sir, for your answer to my question related to functional dependencies that I had put in the database design section on May 9, 2002. I highly appreciate your support. I am satisfied with the answer to some extent. Actually my question was to find a relation (table) that satisfies a--->b and c--->b, but does not satisfy a--->c, where a, b & c are some columns of the relation. I would be obliged if you please answer the same.

    Requires Free Membership to View

    Login

    By submitting your registration information to SearchOracle.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchOracle.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Many kinds of functional dependencies that can create the chain of relationships you have described, but the easiest to understand is functional decomposition.

As an example of function decomposition, consider the proposed schema for an insurance company. Every policy has certain common information, such as the face amount, the insured, and optional related parties (such as lenders), etc. An automobile policy would have an insurance "symbol", VIN, make, model, etc. A real estate policy would have an insurance type (home, unimproved, commercial), a property descriptor (address, plat, or something like it), etc. From a logical perspective, each policy should have the basic information, but there is not any logical reason for real estate to have a VIN or real estate to have a make and model.

One way to deal with these logical requirements is to use functional decomposition to split the policy information into multiple tables, something like:

CREATE TABLE tPolicies (
   policyId INT NOT NULL
   PRIMARY KEY (policyId)
,  faceAmount MONEY NOT NULL
,  insured VARCHAR(100) NOT NULL)

CREATE TABLE tVehiclePolicies (
   policyId INT NOT NULL
   PRIMARY KEY (policyId)
   FOREIGN KEY (policyId) REFERENCES tPolicies (policyId)
,  VIN VARCHAR(50) NOT NULL
,  maker VARCHAR(50) NOT NULL
,  model VARCHAR(50) NOT NULL
,  year DATETIME NOT NULL)

CREATE TABLE tRealEstatePolicies (
   policyId INT NOT NULL
   PRIMARY KEY (policyId)
   FOREIGN KEY (policyId) REFERENCES tPolicies (policyId)
,  descriptor VARCHAR(100) NOT NULL
   )
A row in tVehiclePolicies represents your assertion A, a row in tPolicies represents your assertion B, and a row in tRealEstatePolicies represents your assertion C. Having an auto policy implies having a generic policy, and having a real estate policy also implies having a generic policy, but having a generic policy does not imply anything about having either an auto policy or a real estate policy.

For More Information


This was first published in May 2002

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top