Re: Constraints and Functional Dependencies
From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 24 Feb 2007 19:02:00 GMT
Message-ID: <IY%Dh.1124177$5R2.524029_at_pd7urf3no>
>> <Anyone have any alternate formulas for functional dependencies or
>> candidate keys? >
>>
>> My primary objection to using FOL to define constraints is that it
>> would require our theory of data to have two different but similar
>> languages, one for defining constraints in the FOL language and then a
>> second language for manipulating relations.
>>
>> I will first give some definitions and then show why FOL is not
>> needed.
>>
>> Definitions:
>> Relational Manipulation Language consists of the Basic Relational
>> Operators and Relational Assignment.
>>
>> Basic Relational Operators (BRO) are Project, Extend, Restrict,
>> Product, Minus, Union and Aggregation. It is also usefull to be able
>> to define and name additional relational operators derived from the
>> BRO such as join and divide, but these are not mandatory.
Date: Sat, 24 Feb 2007 19:02:00 GMT
Message-ID: <IY%Dh.1124177$5R2.524029_at_pd7urf3no>
Bob Badour wrote:
> Carl Federl wrote: >
>> <Anyone have any alternate formulas for functional dependencies or
>> candidate keys? >
>>
>> My primary objection to using FOL to define constraints is that it
>> would require our theory of data to have two different but similar
>> languages, one for defining constraints in the FOL language and then a
>> second language for manipulating relations.
>>
>> I will first give some definitions and then show why FOL is not
>> needed.
>>
>> Definitions:
>> Relational Manipulation Language consists of the Basic Relational
>> Operators and Relational Assignment.
>>
>> Basic Relational Operators (BRO) are Project, Extend, Restrict,
>> Product, Minus, Union and Aggregation. It is also usefull to be able
>> to define and name additional relational operators derived from the
>> BRO such as join and divide, but these are not mandatory.
> > > I suggest you check out Codd's 1972 paper. The above are the algebra > operations. If one has the calculus, one does not need them, and the > calculus is FOL.
My primary argument FOR using FOL (including set operators) at some level is that if we can test any syntax we write down by comparing it to FOL, we are assured that we haven't created an illogical-hybrid-monster-non-theory "theory of data" implementation. Not to say that a language should read like FOL.
p Received on Sat Feb 24 2007 - 20:02:00 CET