Re: Can we solve this -- NFNF and non-1NF at Loggerheads

"Alan" <not.me_at_rcn.com> wrote in message news:36n9rvF54k6k3U1_at_individual.net...
>
> "Tom Ivar Helbekkmo" <tih+nr_at_eunetnorge.no> wrote in message
> news:86mzuhd51g.fsf_at_athene.hamartun.priv.no...
>> "Alan" <not.me_at_rcn.com> writes:
>>
>> > You just redefined "atomic" as meaning "divisible". It Codd intended
>> > 1NF to include divisible attributes, he would have used the word
>> > "divisible", not "atomic".
>>
>> No, when he said "atomic", he meant something else: he meant that the
>> objects in question were atomic _with respect to the theory_. That
>> is, his relational theory was not concerned with what those objects
>> actually were; as far as the theory went, they were atomic. This does
>> not mean that they have to be scalar values; they can be _anything_.
>> However, if the value of an attribute is, say, a relation, there is
>> nothing in Codd's theory that looks into that relation, and lets its
>> contents affect operations on the outer, "real", relations.
>
> I refer you to the Elmasri/Navathe text, which states quite the opposite.
> Paraphrasing it (as I don't have it with me at the moment), 1NF means that
> all values are atomic (simple and indivisible - are terms used to explain
> "atomic" in the text), and any value must be a single value from the
> domain
> of that attribute. It does not allow nested data. It does not allow
> multi-valued or composite attributes. These constraints on 1NF are
> specifically stated in the text. Dawn has a copy. Perhaps she can look it
> up
> (look up First Normal Form).

It's at the office, but with a cut and paste from p. 15 of http://www.cc.gatech.edu/classes/AY2002/cs6400_spring/normalize_revised.pdf

"3.2 First Normal Form
- Disallows composite attributes, multivalued attributes, and nested relations; attributes whose values for an individual tuple are non-atomic - Considered to be part of the definition of relation"

>
> Note that Date and Codd often disagreed. Date attempts to expland upon the
> theory, but it is not an expansion so much as a modification so extreme as
> to become something else.

Agreed.

>Date is correct that a theory is needed to explain
> MVAs, but foisting it upon 1NF just to have a "unified theory of
> normalization" (sorry Albert) is silly.

to put it in technical terms ;-)

> Make a new theory. There's no law
> against it. Just don't pretend it is still 1NF.

We are in agreement!

> Call it MVA Normal Form.
> Call it Date Normal Form. Call it Dawn's Normal Form. Just don't call it
> First Normal Form. It isn't. It is similar to 1NF, but values don't need
> to
> be atomic. That should satisfy the pre-relational programmers among you
> who
> are at the core of this nonsense.

Hey, I resemble that remark. However, I went with the crowd on relational theory earlier in my career. There are people I could bring to the table who would testify that I spouted relational notions and also told them they should move toward access to their data via SQL (yes, I know that SQL deviates from relational theory, but SQL is the way that relational practitioners typically access their data). I also made an early pitch at a business I worked for to prepare to move from IMS to DB2 citing what I had read about relational theory. That was mid-late 80's through late 90's.

However, after having a team work with Prime Information in the late 80's, moving to UniData from there, I was amazed at the difference in productivity for developers writing DataBASIC and MultiValue Query language in the UniData environment compared to COBOL/CICS against IMS or PL/SQ:L plus COBOL against Oracle. I then worked with ODBC and JDBC along with a vareity of back-end databases as well as OLAP cube products. I've come back to the old PICK environment (UniData is a flavor-ish of PICK, although Dick Pick lost that particular lawsuit) because my intuition (from experience) tells me there is something about the data model that really does provide the developer and companies who use it a bigger bang for the buck. I started investigating because it was very disconcerting that the theory I believed was correct and the practice that I saw was more agile (for want of a better term) were at odds.

So, I'm not saying that old procedural languages are the way to go in spite of my own skill sets. I do have some forward motion, likely more than many "old programmers". Right now I'm working with something old (PICK), something new (Java 1.5, looking at Java Server Faces and variations on distributed computing), something borrowed (di-graph models for data + predicate logic, borrowed from mathematics), and something blue (IBM database product). I'm hoping it is a happy marriage. We will see.

> Next thing I'm going to hear is that
> linked lists are really 2NF, and adding additional pointers to other lists
> allows for 3NF and foreign key constraints.

Even if you never recognize that I have a brain, Alan ;-) perhaps some day you might give me credit for at least attempting to do something worthwhile with the knowledge I've gained from experience even if it means questioning relational theory as you were taught it.

But until then ... smiles. --dawn Received on Sun Feb 06 2005 - 21:23:52 CET