Re: Is it a prorperty or entity

From: Jan.Hidders <hidders_at_hcoss.uia.ac.be>
Date: 17 Jun 2002 16:36:30 +0200
Message-ID: <3d0df3ee$1_at_news.uia.ac.be>


In article <rb8rguo6q41lqjkh7g1q8n0mr2acu0b1kr_at_4ax.com>, GoranG <no_at_spam.net> wrote:
>On 14 Jun 2002 23:10:14 +0200, hidders_at_hcoss.uia.ac.be (Jan.Hidders)
>wrote:
>>
>>[...] If this happens and you get big clusters of properties that are
>>always together defined or undefined then this is a sign that a subtype
>>should be introduced. E.g., if entity E has properties a, b, c, d and e,
>>of which a, b, and c are always defined and d and e are always together
>>defined or undefined then you introduce the subtype E' with properties d
>>and e and let E have only the properties a, b and c.
>
>Agreed. This binding would indicate existance of functional dependancy
>at a new level - therefore a new entity woul be modeled.
>
>But what is a 'big' cluster - more than two? Or some common sense and
>project dependant - or even entity dependant constant? :)

I would say more than 2 but the most important question is if E' has a natural name in the user domain. If your data model doesn't support optional properties than the definition of "big" is "greater than 0". :-)

> Actually, I asked a wrong question, what I am actually puzzled about
>is:
>What would be indicators of taking normalization too far (in
>conceptual and/or phisical model)?

In the conceptual model: If you are introducing entities that aren't natural for the user(s) then you are going too far. If you want a nice well-defined technical indicator you can check if your schema is still dependency preserving but that is not a sufficient condition nor a necessary condition for a good conceptual model.

In the physical model: It all depends on (1) which queries will be asked (2) how often will the be asked and (3) how expensive they are to compute in the normalized form. Note that denormalization does not give you only performance benifits because the tables that are queried may be bigger than necessary and hence cause more disk access.

>Anyway, thank you very much for taking time to answer...

You're welcome and apologies for the pedantic tone.

  • Jan Hidders
Received on Mon Jun 17 2002 - 16:36:30 CEST

Original text of this message