Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

From: Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be>
Date: Mon, 04 Jul 2005 21:37:55 GMT
Message-ID: <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?

> 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?

>>>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.

>>>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.

> 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. And nowhere did you mention RR, so you still haven't defined what "set of constraints on RR" means.

> 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.

  • Jan Hidders
Received on Mon Jul 04 2005 - 23:37:55 CEST

Original text of this message