Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Table normalization

Re: Table normalization

From: <Kenneth>
Date: Wed, 24 Jul 2002 10:55:03 GMT
Message-ID: <3d3e8493.12710967@news.capgemini.se>


On Wed, 24 Jul 2002 08:43:59 +0200, "Stjepan Brbot" <stjepan.brbot_at_zg.hinet.hr> wrote:

>According to praxis or expirience, when one should normalize a table in
>parent-child tables related via PK-FK? What is the perecentage of
>redundancy of data in a table column when that table should be
>normalized in new related tables?
>
>For example, if you have "Customer" table with column "Street"
>representing only the part of customer's address, there could be more
>rows with the same street but this is not so often and that column
>shouldn't be reformed in new table. So, what is the threshold when
>column with redundant data should be reformed in new child table?
>
>--
>
>Stjepan Brbot
>
>
>

Hi Stjepan,

There is no general "treshold", the question of normalizing depends of what is possible and necessary.

Putting "Street" in a separate table would be problematic in a number of ways :

  1. Street names are not unique. Same street name appears in different towns.
  2. Street names can be spelt differently.
  3. New streets come up and old streets disappear frequently.
  4. You will probably never get a full list of all streets in the world or even in your country, unless you are the national Mail Company . Thus your street reference table will never be up to date, so you will never really be able to use it for anything.

So a "street" reference table will probably never be useful for you. On the other hand, a ZIP code reference table would be obvious to implement. There is a limited and well-defined set of ZIP codes, they are easy to achieve, and you would probably want to validate your customers ZIP codes.

Received on Wed Jul 24 2002 - 05:55:03 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US