Re: Normalisation

Jon Heggland wrote:
> In article <oRfye.137238$uq.7299167_at_phobos.telenet-ops.be>,
> jan.hidders_at_REMOVETHIS.pandora.be says...
>

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

By itself it doesn't. Until you start introducing operations that treat it as non-atomic. Then it does.

> (By the way, is you phrase "domains described by an abstract data type"
> significant? If so, can you explain what it means? Are you talking about
> type generators like set, array, list and so on?)

It's only there to emphasize that the only allowed access is through the functions defined for it and that you cannot access the internal implementation / representation. I believe that in programming language circles this is not always assumed.

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

No, just that the fields that can be unnested with that operator cannot be considered atomic anymore.

> Or that string are atomic and should not be normalised unless and until
> I define an unnest_string operator, in which case all my relvars with
> strings suddenly are no longer in 1NF?

Yes. Although the "should not be normalized" is a bit odd since the whole point is that the defintion says that in that case they already are normalized.

> Does it matter whether my unnest_string is system defined (by the DBMS)
> or user-defined?

Yes. Note btw. that if user-defined functions are restricted to the domains (their input and output types are only domains) then you cannot define such an operation as a user-defined function.

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

Absolutely, the point of the definition is to make more precise what it means that the values in a domain are treated as atomic values.

> How does that help with normalisation?

Since it defines atomicity it tells you when you are in 1NF or not. Just to be clear on this, I regard this discussion separate from the question whether you actually *should* be in 1NF or not. All I'm arguing here is that it is not a meaningless concept and can be defined reasonably well.

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

You cannot. Isn't that a big problem? I don't think so. To understand why it is important to get a good feeling of which operations break the atomicity of certain domains. Also consider the following. Suppose a new user-defined domain is added. If there is no operation defined on it that exposes its internals by mapping it to a relation, then even an unnest operation cannot break its atomicity.

• Jan Hidders