David Portas (7/5/2011)
Tom,I'm well aware that the relational model and TTM require relations that consist of atomic attributes. What I see as a problem is that your article uses another criterion for 1NF:
Is this or isn't it in 1NF? That depends on what the database is expected to do with it
You define 1NF based on intended usage. This doesn't make any sense to me. Suppose I create a relation variable using my RDBMS and call it T. T happens to have a string attribute that encodes multiple telephone numbers. That's OK because a string is by definition an atomic value. According to your definition T is in 1NF as long as "the database doesn't know anything about that encoding". I don't have any problem with that so far because I don't ever intend to split out the phone numbers in the database. T is in 1NF.
Later on however, I change my mind. I want to split out the phone numbers using some code in my database. As you put it: "There will have to be code in queries to decode that complex string". Now you say that T is not in 1NF. But it's the same relation variable as before! The atomicity of the string and the structure of the relation has not changed. Just because I intend to use it differently T cannot suddenly stop being a relation. So your suggested criteria is an additional requirement for 1NF over and above the requirement for T to be a relation - a relation being a thing which is defined by structure alone and never by intended usage. According to you, the relation variable T can change from moment to moment from being in 1NF to not being in 1NF depending on what code exists in my database.
I think you are missing the point -it's not about precluding the database from holding certain objects, it's about ensuring that the objects it holds have so far as the database is concerned only types which are directly supported by the relational calculus or algebra language made available by the database system. Not an issue of abstruse theory, a really simple and straightforwards practical issue.
It's not the decision to have the object in the database that breaks 1NF - it's the decision to have the object in the database and require it to be manipulated by the database language (relational algebra or calculus with the interfaces of supported types) in a manner that requires understanding of its structure without including support for its type in the database language. And don't try to tell me that the type of a list of telephone numbers is string - because correct typing precludes nonsense like allowing 'XvMZQ54(w@^%' as list of telephone numbers.
If you modify the database system to recognise a type "phone number list" and add the operations that implement this type (append number to list, delete number from list, is number in list, is list empty, create empty list, merge two lists, and so on) then you are still in 1NF. If instead to decide to write those longhand in the database language using the primitives for operating on lists of characters (strings) provided by your database then you are not in 1NF because the object is not atomic in the database.
Tom