Re: Stupid Database Tricks

On Jun 13, 8:53 am, Jan Hidders <hidd..._at_gmail.com> wrote:
> On 13 jun, 10:41, vldm10 <vld..._at_yahoo.com> wrote:
>
> > [...] Although, regarding that you are
> > knowledgeable person I would like to know what is in your opinion
> > reinvented (or looks like it) in my "model". You can roughly present
> > it or one by one.

This is not about reinventing ORM. Anyway I have first time in this NG the questions that go in some deeper parts of my "model". One important thing in model is representation of data in form of "simple key + one attribute" or as sometime is described as the total decomposition. This form of data has enormous importance for practical issues

> The ideas of :
> 1. Adding a special key to relations that identifies the entities or
> relationships represented by the tuples in the relation.

Here I believe that you misunderstand what is key. I have 1. the identifier of the state of an entity or relationship 2. the identifier of the entity or relationship. I will use shortcut IdSt for first and IdEt for second Usually key is IdSt. But IdSt always goes in pair with IdEt. These two identifiers have strong semantic and conceptual base. In simple DBs we can use only IdEt as key. For example if entity has only one state i.e. if entity is always same, then IdSt = IdEt i.e. there is no IdSt.

> 2. Using the presence of this key

The idea here is not:
>to split everything as much as
> possible into binary relations.

Here we need method to do this "decomposition" effectively and completely. In fact here we don't have decomposition, we have construction.

> These are old ideas, and have already been rejected before. I have not
> seen any argumentation by you that explains why this would now have
> become a good idea.
>
> Btw. did you realize that for a relation R(K, A_1, ..., A_n) where {K}
> is a superkey, it always holds that the relation equals the joins of
> R(K, A_1), ..., R(K, A_n)? Any assumptions about mutual independence
> are not necessary. Also note that such a relation is not necessarily
> in 5NF if {A_1, ..., A_n} are mutually independent, or even in 4NF,
> for that matter.

This is about normal form which I defined and I would like to emphasize same aspects and intentions of it. 1) It is simple.
2) It is the construction rather then the decomposition.

    So I don't want first to construct a relation and then if it is wrong to make decomposition.

    I want immediately good construction.     In this sense it is irrelevant for this construction that R should be in 5NF or 4NF. It is important

    that R1, .. Rk are in all normal forms immediately, and good for many other things. This construction

    also means that I don't need to decompose a relation first in 4NF, then in 5NF and then in my

    Simple Form. Construction doesn't need any sequence of the decompositions. It do only one - Simple Form. 3) there are two conditions here

    (i) That key is simple.
    (ii) That attributes are mutually independent - this is in fact about entity.

     So entity is involved here as a set of mutually independent attributes Here entity is an

      abstraction as it is set i.e. relation. I gave some relationship between these abstractions in 4.3.

     So I believe that these abstractions are very "connected". 4) There is one condition more here which is not mentioned. It is that one attributes always belong

     to one entity. Also the attributes A1,...,An. are all belongs to one entity. This condition can be derived

    from other things in this "model"

 So this definition is rather convention about above conditions.

Definitely, I don't have good examples and this is what confused people. I am very short with time and I need 3-5 days to make two good examples.

>
> -- Jan Hidders

Vladimir Odrljin Received on Thu Jun 14 2007 - 12:55:01 CEST