Re: A simple situation shows confusion about basic concepts
Date: Tue, 26 Oct 2004 16:41:40 -0400
Message-ID: <2u7r45F277rc5U1_at_uni-berlin.de>
"Ney André de Mello Zunino" <zunino_at_inf.ufsc.br> wrote in message
news:2u59kcF27bu54U1_at_uni-berlin.de...
> Alan wrote:
>
> > 0. It strikes me that KB is incorrect in that you have uc_id1 and
uc_id2.
> > There should only be uc_id, and this is a foreign key to UC.
>
> The KB is a collection of entries, where each of which establishes a
> relationship between *two* UCs. There are different types of
> relationships, e.g. a /car/ *is a* /vehicle/ or /Brazil/ *is part of*
> /South America/. I thought of two foreign keys because the definition of
> a KB entry requires two UCs. I apologize if I have misunderstood your
> remark.
>
> > 1. You only need uc_id at all if you have more than one uc with the same
> > name(description?) or you will be adding additional attributes to UC.
So...
>
> Yeah, I considered that as well. However, because the UCs are going to
> be referenced from some other entities and because their "description"
> can get very large, I chose to use an artificial key, as mentioned in
> the original post.
>
> > 3. need uc_id, and you therefor have a 1:m relationship between UC and
KB.
> > uc_id is the PK in UC and the FK in KB.
> >
> > You end up with:
> >
> >
> > UC (Universal Concept)
> > ======================
> > uc_id (PK)
> > uc
> >
> > KB (Knowledge Base)
> > ===================
> > entry_id (PK)
> > uc_id (FK)
> > relation_type (whatever that is)
> >
> > You are making this much more complex than it really is. This is a
simple
> > 1:m situation. E.g., one word has one or more definitions.
>
> I don't see how the above scheme would allow me to model the binary
> relationships between UCs. I mean, each entry *must* refer to two UCs.
>
> I hope to have clarified the situation a little better and thank you
> already for your response.
>
> Regards,
>
> --
> Ney André de Mello Zunino
KB (Knowledge Base)
entry_id (PK)
uc1_id (PK) <--- CHANGE to PK
uc2_id (PK) <--- CHANGE to PK
relation_type
And actually, you don't really need entry_id- you could just use relation_type, but I think you mentioned that originally, and your reason for using it is valid.
Keep in mind that what we have here is not an entity-relation model (ERD), we have a relational schema (table design). The modeling on an ERD would be different. I can't draw it here, but basically, you have one rectangle (UC) and one diamond (KB) connected twice, once in the uc1 role, and once in the uc2 role, both with mandatory participation and "many" cardinality. Further, you have two attributes on the diamond, entry_id and relation_type. Received on Tue Oct 26 2004 - 22:41:40 CEST