Q
Problem solve Get help with specific problems with your technologies, process and projects.

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.

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


Dig Deeper on Oracle database design and architecture

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide.com

SearchDataCenter

SearchContentManagement

SearchHRSoftware

Close