Date: Tue, 5 Jul 2005 12:41:16 +0200
In article <oRfye.137238$uq.7299167_at_phobos.telenet-ops.be>,
> >>Roughly, I would say that it means that all your data manipulation can
> >>be expressed as operations over a signature that consists only of (1)
> >>domains described by an abstract data type and (2) relations that
> >>contain in their fields only values from these domains.
> > I can't make heads or tails of this. Operations over a signature?
> Yes, that means that they can be described in a programming language in
> which your access to the database is restriced to the functions in the
> signature. These operations would be the (1) the operations that are
> associated with the domains and (2) operations that retrieve the current
> instance of a relvar.
> >>An unnest operation, for example, cannot be described in that way.
> > What if I define an unnest operator that "unnests" strings in a
> > corresponding manner?
> It does not satisfy the definition.
Or that strings are not atomic?
> > Anyway, let me rephrase my initial question.
> > What is an atomic datatype/domain?
> The problem with that question is that it makes an incorrect assumption.
> Atomicity is not a property of a domain per se,
That is news to me. All database textbooks I have used use the phrase "atomic value" to define 1NF. Which, while obviously different from "atomic domain", can hardly be interpreted very differently. I also note that most of them concur with Date that 1NF is implied by the definition of a relation.
Where do you get your 1NF definition from?
> but rather a property of
> how it is treated by certain operations. The more correct question is:
> "When does the DBMS treat a certain domain as atomic?". You can derive
> the answer to that question from what I said above.
How does that help with normalisation? And how can you say a priori that a relvar with a set-valued attribute is not in 1NF, if that depends on the operators of a particular DBMS?
-- JonReceived on Tue Jul 05 2005 - 12:41:16 CEST