Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Mon, 4 Jul 2005 22:06:56 -0400
Message-ID: <Spidna6MyaymdlTfRVn-3g_at_comcast.com>
"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
news:T_hye.137324$JD6.7251058_at_phobos.telenet-ops.be...
> VC wrote:
>> "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message >> news:SiSxe.136301$no5.7264319_at_phobos.telenet-ops.be... >> >>>VC wrote: >>> >>>>"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message >>>>news:I4Cxe.135796$Bh7.7066690_at_phobos.telenet-ops.be... >>>> >>>> >>>>>Jon Heggland wrote: >>>> >>>>[...] >>>> >>>> >>>>>>Not personally, but what more do you need than definitions of value, >>>>>>domain, tuple and relation, and a minimal set of algebra operators? >>>>> >>>>>The notions of database schema, database constraints, database >>>>>instances and how they are exactly related. >>>> >>>> A constraint (in the RM) is just a predicate [required to evaluate to >>>> true]. >>> >>>A predicate over what? Before you can define a predicate you have to >>>define the domains it applies to. >> >> With the RM, sort of obvious, no ? >
> In a formal defintion in set theory nothing can be assumed to be obvious,
> except set theory. :-)
>
>> Let's assume we have a relational variable :
>>
>> var PERSON relation {ssn# in ssn_type, name in name_type, age in integer,
>> salary in integer} key{ssn#};
>>
>> We can define a predicate (constraint): forAll ssn#, name, age,salary:
>> {ssn#, name, age,salary} in PERSON & (age < 14) -> salary = 0
>>
>> that says that everyone described by the PERSON relational variable
>> (which may be a view btw) and younger than 14 earns 0.
>> This would be an example of a relation constraint (applicable to one
>> relational variable only).
>
> Ok. Good example. So what is now the formal definition of the set of
> predicates?
Since you are familiar with the notion of "set" and presumably the notion of predicate as defined in the FOL, I do not see much point in reproducing either.
> >> Additionally, the relational variable definition itself includes >> attribute constraints (name in name_type, age in integer and so on). >
> Great. So what does the complete formal definition look like?
[attribute constraints are] a set of sentences of the FOL stating that the attribute value is an element of its datatype (V set). E.g. "name is_a_member of name_type".
>>>>A relation schema is a schema name R and a set of attributes A: R(A) >>> >>>You forgot to model the domains. The attributes have to be associated >>>with a domain. >> >> That is correct. A domain, or a data type, is pair (V, O) where V is a >> set of values and O is a set of operations closed over V [I believe Codd >> did not require O so that (V, O) can be collapsed to just V. 'O' is an >> attempt to accomodate user defined data types (or 'objects') in the RM]. >
> How do you define the set of operations over a set V? And are you sure it
> has to be closed? I cannot have an equality operation that maps two values
> to a boolean, or an operations that maps a string to its length?
>
> Of course I'm nitpicking here, but that is the whole point of formal
> definitions.
It's not nitpicking. It's a silly error on my part. Please remove the word "closed".
> >>>>A database schema is a pair (RR, C) where RR is a set of relation >>>>schemata and C is a set of constraints on RR. >>> >>>You forgot to model that relations must have a unique name. And what is >>>exaclty a "set of constraints on RR"? You didn't define that properly. >> >> I did not. See above: "a relation schema is a schema *name* ...". >
> That doesn't say it is unique. You allow in a database schema two relation
> schemas with the same name.
Right.
> >> C is a collection of database constraints, relation constraints, >> attribute constraints and, if one admits user defined types or >> 'objects', type constraints. >
> Ow! Now you have to define also what "relation constraints" and "attribute
> constraints" are.
I did. See above -- the relvar example mentions the "relation constraint", I also talked about the attribute constraints when I defined the PERSON relvar. In any case case, the constraint taxonomy is not terribly important -- all of them are just predicates as said before -- and one can look upon all of them as a set of the FOL sentences required to be true.
> And nowhere did you mention RR, so you still haven't defined what "set of
> constraints on RR" means.
I did, I wrote "..where RR is a set of relation schemata.."
> >> Simple, no?, especially in comparison to alternative data models. >
> Not the ones I had in mind.
> >>>>A relation instance for R(A) is a set of tuples. >>> >>>You forgot to model that the tuples have to be consistent with the header >>>of the relation. >> >> I did not, see the R(A) notation. >
> I did. It says nothing about how the tuples look.
You have a point here. A reltional tuple which is defined as a partial function T:C->D (C -- column name; D -- domain) differs from its usual math cousin where a tuple is usually understood as an *ordered* collection of elements.
However, we are playing a lopsided game. All the stuff I am storytelling here is well known and quite simple (a starightforward application of the FOL and the set theory). One would be much better off just reading any decent book on the RM and seeing for oneself how simple the model really is.
What I am really curious about is the stuff like "conceptual object type" and such for which there appears be no clear definition either formal or informal.. Let's talk about them, shall we ?
Thanks. Received on Tue Jul 05 2005 - 04:06:56 CEST