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
- Dozens more answers to tough database design questions from Pat Phelan are available here.
- The Best Database Design Web Links: tips, tutorials, scripts, and more.
- Have an Oracle or SQL tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize. Submit your tip today!
- Ask your database design -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our SQL, database design, Oracle, SQL Server, DB2, metadata, object-oriented and data warehousing gurus are waiting to answer your toughest questions.
Dig Deeper on Oracle database design and architecture
Related Q&A from Pat Phelan
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.