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

>> What the heck is a legal entity? <<

Corporations, contracts, counties, countries, etc.

>> Is there a formal definition for illegal entities? What do we do
with one if we catch one? <<

Yep, in most places there is; you hope you are not part of it <g> whent hey get caught.

>> I can see where adding additional conditions and criteria based on
personal
insight might help one in determining whether some modelling construct should be identified as either a entity or a relationship, but for every Celko with his own idea of distinguishing between the two, there is an anti-Celko who believes just the opposite. Why? Because it is more in the realm of <interpretation> and <opinion> than on any formal modelling framework. <<

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.

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?

>> 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 prove that this is not normalized, assume that "Chuck" changes
his name to "Charles"; you have to change his name in both columns and several places.]
So what? You have to do this for any 1-M or N-M relationship when you need
to change the referenced key or key component value within a relational
database... <<

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". 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. 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.

In Nucleus, for one example of a modern SQL product, The value 'red' appears in a domain and appear only once. 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. Received on Thu Sep 26 2002 - 21:52:09 CEST