Re: Proposal: 6NF

David Cressey wrote:
> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> news:1161168370.499516.204970_at_i3g2000cwc.googlegroups.com...
> >
> > David Cressey wrote:
> > > "paul c" <toledobythesea_at_oohay.ac> wrote in message
> > > news:g2iZg.155655$5R2.60964_at_pd7urf3no...
> > > > David Cressey wrote:
> > > > > "Tony D" <tonyisyourpal_at_netscape.net> wrote in message
> > > > > news:1161090234.533844.46810_at_k70g2000cwa.googlegroups.com...
> > > > >> paul c wrote:
> > > > >>
> > > > >>> Still, the bulk of the apps I've seen
> > > > >>> don't need that extended type support ...
> > > > >> I couldn't disagree with this observation more strongly. Without a
> rich
> > > > >> type system, we can't talk about the right things (attributes). If
> we
> > > > >> can't talk about the right things, we can't reasonably expect to
> > > > >> construct proper statements (relations). As well to make assertions
> > > > >> about horse racing by discussing camels :) And to have a rich type
> > > > >> system, we'd better make sure the underpinnings are at least
> consistent
> > > > >> and preferably correct ;)
> > > > >
> > > > > It seems to me that it's possible to talk about the right things
> with a
> > > rich
> > > > > domain system,
> > > > > even if lacking a rich type system. It also seems to me that user
> > > defined
> > > > > domains are not the same thing as additional types.
> > > >
> > > > PMFJI, when it comes to a dbms engine, I don't know the difference
> > > > between a type and a domain.
> > > >
> > > In the context of a dbms engine, a type would be the built in datatypes
> > > that the engine supports, like INTGER, DECIMAL, CHAR, and DATE, and
> also
> > > the builtin functions and operations, like "+" or "weekday(x)".
> > >
> > > A domain would be what you get when you say CREATE DOMAIN. It's a set,
> but
> > > it has no functions and operations other than the ones it inherits from
> the
> > > data type it is based on.
> > >
> > > Does this make sense?
> >
> > Hi David, I was previously under the impression that built in 'types'
> > such as INT's or DATE's are domain s defined by a predicate, as opposed
> > to being enumerated (e.g. tinyints := { x : x E Z, -128 < x < 128 } ),
> > and I didn't distinguish them in my mind from user defined domains.
> >
> > Are you differentiating a dbms type to a domain, in that a dbms type
> > also has built in operations which apply to its domain definiton, and
> > is this is a standard view? Cheers, Jim.
>
> I intended the implication. To my knowledge, this is not a standard view.

>From the reading I have done, I recall quite a few writers who suggest that domain and type are synonyms and another handful of writers who define a domain to be a set, where a type includes operators. In spite of a history of redefining mathematical terms when working with databases, it makes sense to me to define a domain to be a set. As mentioned elsewhere, that does not mean it lacks operations that are defined on it, but that the domain itself is "just" a set. A type, however, is widely understood as including operations.

> I agree with your comment that the builtin types are defined by a predicate.

That is implementation-specific, of course. A type in many languages might be an enumeration (e.g. Java enum).

> This question is independent of whether
> the operations on the type are construed to be part of the type definition
> or not.

A type could be defined to include some operations while others might also be defined on the same domain and used later (post-definition). Those are then operations on the type or domain, but not operations that are defined as part of the type definition. The added operators might be available only locally, while all users of the type have access to the type operators in the definition of that type.

> AFAICT, user defined domains, a la CREATE DOMAIN, are defined by a
> predicate as well. Aren't they?
> Of course, for many user defined domains, there will be a reference table
> with a primary key column based on the domain, and which serves as a
> validation table for foreign key references.

By the way, if not working with SQL where OTLT is rightly considered a no-no, there are many environments where a single validation table for many varied user-defined domains is still popular (and after reviewing it some months back I would posit that it is still worth considering as a "best practice" ;-) Cheers! --dawn

> I suppose you could say that
> the reference table enumerates the currently valid values of the domain.
>
> Is this what you meant?
>
> >
> > >
> > > > p
> >
Received on Wed Oct 18 2006 - 16:25:55 CEST