Re: foundations of relational theory? - some references for the truly starving

"Bob Badour" <bbadour_at_golden.net> wrote in message news:ie6dna18NqYv2giiU-KYhQ_at_golden.net...
>
> <snip>
>
> The fatal error in Mr. Murthi's logic is the assumption that the theorists
> must have ignored Pick if they have nothing positive to say about it.
>
>
<more snip>
>
> The fatal flaw in Mr. Murthi's logic is the assumption that advocates of
the
> relational model somehow fail to understand Pick. I understand it more
than
> well enough to reject it, and I observe that Pick advocates have very
little
> understanding of AQL as evidenced by the whole red]blue car exchange.
>
>

Bob,

In all honesty, I realize you need no prompting, but please feel free to correct me where I'm wrong. If this is to be an intelligent discussion and not just a bunch of children throwing tantrums and invectives, please stick to the point and show me where I'm wrong.

According to Marc Light of University of Iowa, School of Library and Information Science, Linguistics Department (I paraphrase to avoid copyright infringement):
http://que.info-science.uiowa.edu/~light/courses/autoSys/lectures/kentfirst.pdf

1st normal form: No multivlaues; all rows contain the same number of columns.
 No problem. we just flatten out our file structure. Every data element in Pick is a variable length variant so we don't have to worry about data typing and columns may contain different data types (numbers, dates, strings); but we never saw that as a problem. So every "row" can have the same number of columns, no matter if they exist or not.

2nd normal form: 1NF & no data element depends on data in composite keys No problem. We've been translating (what Pick calls a join) to create relational data for years and if we're going to flatten out our tables anyway, and since the number of translates is insignificant in normal numbers, we can store atomic data and fetch it on demand.

The example on the web site was this:

Part
Warehouse
Quantity
Address

Since Address depends on warehouse and therefore the composite key part/warehouse, this is NOT 2NF, so they move the address to a separate table and make the 2NF table:

Part
Warehouse
Quantity

We would do that naturally, because it's stupid to store the address or any such static data depending on warehouse in every part record.

3rd normal form: (1NF) 2NF & No non-key field is a fact about another non-key field.
Again, flat tables and translates and we fit right in.

Their example was

Emp
Department
Location

Since location depends on department they move it to another stand alone table. And, again, we would probably have done that anyway, because, again, it's stupid to repeat static information that's longer than a key to point to it.

So I guess my point is that Pick's strength and value isn't in that it's RDBMS compliant, though it seems like it could be, but that it's flexible enough to take advantage of "natural relationships." In a 2NF table I could never have a part item with multivalued warehouse and quantity. But there's a natural relationship implied in the structure that says this part resides at these warehouses and has these quantity respectively.

Maybe I'm wrong here and it's no about Normal Forms. Maybe I got the wrong source off the web...

Maybe it was the drugs from the 60's. I could use a good flashback right about now.

Please show me where I went astray, but please show me the courtesy of adult dialog.

Mark Brown Received on Tue Oct 21 2003 - 20:43:29 CEST