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

Mark Brown wrote:

>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.
>
The first thing to understand about relations is that they don't really exist. They are a mirage. They
don't exist on disk and when they are read into programs or shown on screen they cease to be relations.
So it does not make sense to talk about how a relation is physically stored. The DBMS is free to do
with the relations whatever it want's just as long as it answers your queries correctly.

So, even though a relation (which does not really exist) has a column that references some other
relation (loosly speaking) in memory (or disk) this may be represented as a pointer, or by clustering
or however, just as long as the user has the ILLUSION that the value is part of the relation.

Now, most, if not all SQL-DBMS'es today pretty much save the relations as they look,
give or take a few bytes. But that is not a limitation set by the relational model. It is probably
the legacy of System-R, the IBM prototype that became SQL/DS and DB2.

Normalising is just a tool for the benefit of the datamodeler, so that update anomalies can
be avoided. It is not really part of the relational model per se (except for 1st NF).

It would be perfectly legal to, say, create the tables in a normal fashion, and then, with
some other commands, tell the DBMS how you want the tables to be clustered together.
I don't know if something like this has been implemented, but it would not go against the
spirit of the relational model, au contrair!

best regards,
Lauri Pietarinen Received on Tue Oct 21 2003 - 21:38:47 CEST