Re: Define "flatten database" ?

"Alan" <alan_at_erols.com> wrote in message news:35vj76F4sdq3pU1_at_individual.net...
>
> "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

I'm not sure you understood me. I really do know how to normalize data according to the usual practices -- I'm trying to explain a term, which is the topic of this thread. I also explained WHY when working with embedded lists, putting the data into a form that is usable as a SQL VIEW is sometimes referred to this way. This is an incorrect use of the term "normalize" but if you listen a bit, you might be able to hear how such language evolved:

George: Can you pull that into Excel using ODBC? Harry: Do you want to have a person's list of e-mail addresses all in one cell or in separate cells?
G: Separate ones
H: The e-mail addresses are in a list, so I'll have to normalize the data first
G: OK, let me know when you've flattened the data into Excel, OK?

> Normalizing is simply a process of removing redundancy from data

That is true for 2NF and beyond, but that is where I get on my soapbox about 1NF. 1NF is not about reducing redundancy, is it?

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

Of course, but one can have a row with embedded lists, thereby indicating that the data are not in 1NF, right?

> (Remember functional dependencies? Did you ever read the Elmasri/Navathe
> book you bought?)

About half of it and almost all of Date's 8th edition. I'll sitll admit to ignorance, but perhaps not as much as you might think, so you might have to decide whether or not I'm dumb instead ;-)

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

I was not trying to make it complex but to answer the original question since I have often used the non-RDBMS phrase "flatten the data" and, therefore, thought I might be able to shed some light on at least what I meant when I said it.

>
>> > You have it backwards and twisted.
>
>
>>
>> This might still be true. --dawn
>
> Well, yes...

I'm not sure you are reading me right, but I'm sure you will feel free to continue to hold that opinion. Ah well ... --dawn Received on Fri Jan 28 2005 - 23:23:21 CET