Re: Some really confusing things about parent-child relationship

From: Jan Hidders <hidders_at_gmail.com>
Date: Thu, 16 Aug 2007 23:53:48 -0000
Message-ID: <1187308428.035386.190290_at_a39g2000hsc.googlegroups.com>


On 16 aug, 20:26, beginner16 <kaja_love..._at_yahoo.com> wrote:
> Sorry for additional questions
>
> On Aug 16, 9:26 am, Jan Hidders <hidd..._at_gmail.com> wrote:
>
>
>
> > On 14 aug, 20:15, beginner16 <kaja_love..._at_yahoo.com> wrote:
>
> > > hello
>
> > > I would really need some help with the following questions. And
> > > apologies for so many of them
>
> > > 1)
>
> > > a)
> > > In hierarchical model parent class can have several subclasses. What
> > > does that mean exactly?
>
> > > That an instance A of parent class can have connections to several
> > > instances of certain subclass, or that an instance A can have
> > > connections to two or more instances, where each instance is of
> > > different subclass type, or both?
>
> > The last.
>
> The last as in "an instance A can have connections to two or more
> instances, where each instance is of different subclass type"?

Yes.

> > > b)
> > > And why do we name some classes subclasses and other classes
> > > parents?
> > > It makes sense in object oriented programs, but here subclass doesn't
> > > necessarily suggests more specialized version of parent class.
> > > As far as I understand it, in hierarchical model we get a parent
> > > child relationship by simply creating a connection between two
> > > classes?!
>
> > Indeed. The term subclass is here used in a very different meaning
> > than in OO. Here it expresses something similar to containment. As in:
> > the engine is part of the car so Engine is a subclass of Car.
>
> Couldn't engine in a way be viewed as more specialized version of a
> parent class?

Sure, sometimes they are similar. Take for example biological hierarchies. In some sense the species Homo Sapiens is a subclass of the genus Homo, and in some sense it is a part of Homo. Note that strictly speaking the hierarchical model doesn't tell you what the hierarchy exactly means, just that you can specify one. But it is clearly more suitable for part-of relationships than for is-a relationships (no inheritance et cetera).

> > > Anyhow, book divides network model in three parts:
> > > * simple network model --> M:N connections are not allowed
> > > * complex network model --> M:N connections are allowed
> > > * limited network model
>
> > > c
> > > Now how do we know which of the two connected entity types is a
> > > parent and which a child and why does it matter?
>
> > It doesn't. It's an artifact of the way this model was implemented
> > usually.
>
> Could you elaborate a bit more on this?

The relationship would usually be implemented by a type of linked list that allowed you to navigate from a parent to its children and vice versa, but that would not be completely symmetrical and favor certain types of navigation over others. For more information and an illustration on that see: http://en.wikipedia.org/wiki/CODASYL

> > > d)
> > > Next comes the mother of all confusing statements:
> > > book starts claiming that between the two entity types there can be
> > > several 1:N connection ( meaning just 1:N connections ... M:N
> > > connections ).
> > > Huh, didn't it previously claimed that complex network model allows
> > > M:N connections?
>
> > Hard to say without more context. Of course, saying that there can be
> > several 1:N relationships doesn't exclude that there may also be
> > several N:M relationships.
>
> I reread that part and I think the book is saying that between the two
> types there can be several different 1:N connection types ( meaning
> just 1:N connection types )

My guess would be that the authors ar speaking in the context of the simple network model. But that is mainly based on the observation that then it makes sense. :-) That was, AFAIK the more common model anyway.

> 3)
> a)
> Also, couldn't an instance of a subclass have several parents ( these
> parents being instances of parent class A ) and also several other
> parents ( these parents being instances of of super class B )?

Yes.

> b)
> BTW - one of the reasons why I'm confused about this parent-child
> stuff is that all network diagrams presented in a book have snake like
> shape --> meaning if class B is connected to class A on one side and
> class C on the other side --> class C is connected with B on one side
> and with class D on other side. Point being, that no class ( in the
> diagrams presented in a book ) is connected to more than two classes.
> So I'm thinking there's got to be a reason for that?!

See page 4 on:

http://www.rocw.raifoundation.org/computing/BTech-IT/DataBaseManageSys-3.202/lecture-notes/Lecture-03.pdf

  • Jan Hidders
Received on Fri Aug 17 2007 - 01:53:48 CEST

Original text of this message