Re: A Question On Many-To-Many Linking Table(s)

From: D Guntermann <guntermann_at_hotmail.com>
Date: Thu, 26 Sep 2002 22:59:26 GMT
Message-ID: <H32IJ1.LKq_at_news.boeing.com>


"--CELKO--" <71062.1056_at_compuserve.com> wrote in message news:c0d87ec0.0209261152.18f69412_at_posting.google.com...

[snip]

> In some cases, such as a formal marriage, there is quite a bit of
> stuff that comes with it; inheritance being the biggy in most cases,
> but also liability for the actions of the spouse, etc. Can you really
> model a legal database in which a marriage is NOT distinguished as a
> legal entity in itself? That one is not opinion; it is black letter
> law and has been for a looooong time.

I'm failing to see your point. You add a considerable layer of complexity to the fact that I just want to record the event of two people getting married; or alternatively, I want to record some marriage between two people. You see, the two sentences mean the same thing, irregardless of marriage licences, inheritence, and whatever other criteria makes sense to just you. If the sentences, one where 'get married' is used, and the other, where 'marriage' is used can mean the same thing, then I think it stands to reason that a marriage as an entity and a relationship called married-to can be considered to have the same semantic meaning, especially if the constraints applied are the same.

> The data modeling criteria is pretty clear; does the relationship qua
> relationship have attributes of its own or have only the attributes of
> the members of the relationship?

I'm not sure I understand you here. Could you rephrase? I'm guessing that you are stating that relationships (in the entity sense) are only relationships if they do not contain attributes of their own, but I can't be sure.

> >> You've in one fell swoop basically stated that any unary
> relationship should be discounted as a valid alternative for both
> modeling and implementation. <<
>
> How did you get that out of my posting??

To quote you: "Another problem with the adjacency list model is that the boss and employee columns are the same kind of thing (i.e. names of personnel), and therefore should be shown in only one column in a normalized table."

For any unary relationship, _the same kind of thing_ will involve two values, the value of the candidate key and the value of the referencing key, which is the same kind of thing as the referenced candidate key. This means that any tuple/row that references another tuple/row in the same table will have two values "of the same type" (which is a good thing by the way). By your statements, you indicate that any since a unary relationship will involve two columns of the same _semantic_ type, a BOM for interchangeable parts (part-part), part kits (part-part), boss-subordinate relationships, etc that might involve unary relationships would all be unnormalized tables.

>
> The basic definition of all normalization (credit to C. J. Date and
> Dave McGoveran for the idea and me for the snappy phrase) is "one
> fact, one place, one way, one time".

Codd introduced the concept of normalization (1-3NF) at the same time he introduced the concept of a relational system. Fagin and Boyce also contributed a great deal to the body of knowledge in this area, as did many others, including Date and McGovern. Moreover, I've heard the phrase stated more accurately by other authors well before you created a variant.

Please go back and review the concepts of normalization and normal forms. It starts with understanding functional dependencies among sets of attributes and memorizing sets of criteria to apply to relations/relvars in order to determine the quality of relation design. The primary objectives of the process are to reduce redundancy (note the word is 'reduce', not 'eliminate') and work to eliminate update anomolies; it is not merely reduced to a single phrase of "one fact, one place, one way, one time", especially given your propensity of mangling the meaning.

  In a (1:m) relationship, the 1
> side is the single fact and DRI cascades it out to the (m) side
> tables. The fact resides in one place, but it is referenced in many.
> Ditto with (m:n) whe i change either the (m) or (n) side.
>
> >> How do you propose to maintain this model without being able to
> have more than one of the same value (attribute) within a database?
> Good grief.<<
>
> Your mental model is still a file system.
 No. It's the relational model. I submit that your mental model is a file system.

Just because the display
> shows 'red' as the color for several items, the database does not have
> to be made of separate "records", each with a "field" hold that
> string. Quit thinking a row is like a punch card! That is what the
> smaller, weaker, earlier SQL products did and it sucks. Thye are also
> stuck with the mental model that a table has to be "sorta like file";
> the trick is to view the schema as a whole, with tables as
> interrelated parts of it.
>
Kind of like a Universal Relation?? Come on...is this supposed to be enlightening?

> In Nucleus, for one example of a modern SQL product, The value 'red'
> appears in a domain and appear only once.

Wow! So if red only appears once, then only one object can appear simultaneously with a property of red.

Columns are then
> constructed from domains via compressed bit vectors and finally tables
> are built from columns via compressed bit vectors. The result is
> insanely fast processing for VLDBs long with really good data
> compression. It is weird to see columns appear one at a time on the
> screen instead of rows appearing one at a time.
>
> Sybase IQ, Kx, Teradata all have totally different physical models.

That's fine. In fact, that's great, but I think you are having a problem isolating ER and relational model arguments from actual physical implementation issues. Regardless, it should be under the covers and not visible to the user. If so, then they have enhanced an implementation of the relational database without breaking from the vision of Codd with automatic navigation. Received on Fri Sep 27 2002 - 00:59:26 CEST

Original text of this message