Re: Define "flatten database" ?

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:cte2b6$h5u$1_at_news.netins.net...
> > OK, I'd vote for both terms being incorrect. It is not denormalizing
> > because it is starting with non-1NF data -- agreed? And it is not
> > normalizing because, well, it clearly isn't (the key, the whole keyu and
> > nothing but the key ...). However, the reason that "we" sometimes call
it
> > normalizing is that it takes a non-SQL92-compatible structure and turns
it
> > into something that can be used with ODBC, for example. By formal
> > definitions (until perhaps recently) the source data are not in first
> > normal form. So, informally, to get ODBC to work (for example) someone
> > might suggest they are normalizing it. I'm one of the people who says
> > "flatten" instead because normalizng is clearly wrong. However, it is
> > still an informal way people might say it as in "we need to nornalize
the
> > data in order to pull it into Excel". (Wrong, but you can see how such
> > language evolved).
>
> I'll just add one other point that the reason that "flattening" from a
> non-1NF is sometimes referred to as normalizing is that there is a sense
> that the nested structures are pulled into separate "rows" thereby
> normalizing, and then a view created that ties them to their original
table,
> but now as if both relations (the parent and the child) were normalized
and
> then joined. Did that help clarify the langauge?
>

No. Putting anything into rows (seperate or otherwise) is not normalizing Normalizing is simply a process of removing redundancy from data and reducing the possibility of insert, update and delete anomalies. It is not done at the row level, it is done at the individual data element level. (Remember functional dependencies? Did you ever read the Elmasri/Navathe book you bought?) The structure of a row is defined +as a result+ of the process, it is not the process itself. Flattening is the process of doing the opposite (DEnormalizing)- taking normalized data from many normalized tables (think of it as a kind of hierarchy (not that it is), or parent-child relationships (Joe Celko, do not yell at me- I am just trying to explain this in simple terms)) and putting it into fewer tables (usually to one table) (IOW, taking away the hierarchy "pyramid", therfore causing it to appear "flat" or "flattened", hence the term "flattening"). This could introduce redundancy, and therefore cause the above mentioned anomalies.

I _still_ don't understand why you insist on making this complex. It isn't - it is soooo basic - but I give up.

> > You have it backwards and twisted.

>
> This might still be true. --dawn
>
>

Well, yes... Received on Fri Jan 28 2005 - 20:48:19 CET