Groups > Borland > Delphi Object Oriented design > Re: Groups and Kinds of Grouping




Groups and Kinds of Grouping

Groups and Kinds of Grouping
Thu, 9 Aug 2007 00:02:05 +0200
Consider Items that can be grouped in many kinds:

GroupKind1: Group11: (Item1, Item2), Group12: (Item3, Item4)
GroupKind2: Group21: (Item1) Group22: (Item2), Group23: (Item3, Item4)
GroupKind3: Group31: (Item1, Item2, Item3) Group32: (Item4)

(1)Each Item is assiciated with exactly one Group for each GroupKind.
(2)Each Group is associated with exactly 1 GroupKind.

We have effectively 3 entity classes: GroupKind, Group and Item.
The question: how should look like relations between classes in order to
ensure the rules (1) and (2) without additional constraints?

It's easy to see that e.g. the solution

Item 0..* ---------------- 0..* GroupKind
           Item_GroupKind
                |
                 0..* ------------------ 1 Group
is not the solution indeed because a Group can corespond here to many
GroupKinds.

/Efim

Post Reply
Re: Groups and Kinds of Grouping
Mon, 13 Aug 2007 09:41:37 -050
"Efim Mett" wrote
> I wonder if my question was understandable for anybody?

Sure. Let's start here:

(1)Each Item is assiciated with exactly one Group for each GroupKind.

This basically suggests
                               (relationship object)
GroupKind --------   GroupKindItem  ----------  Item
                                           |
                                           |
                               (relationship object)
                               GroupKindItemGroup
                                           |
                                           |
                                       Group

The logical relation of GroupKind to Group is 1..n, not 0..n, because there
has to exist at least one group in the GroupKind for items to be members of.
This suggests that a GroupKind needs a default or 'unassigned' group.
Otherwise, if you create a new GroupKind, what happens to rule (1) "Each
Item is associated ..."

It's not clear what you mean by "without additional constraints"

bobD

bobD


Post Reply
Re: Groups and Kinds of Grouping
Mon, 13 Aug 2007 10:20:11 -040
Efim Mett wrote:
> Consider Items that can be grouped in many kinds:
>
> GroupKind1: Group11: (Item1, Item2), Group12: (Item3, Item4)
> GroupKind2: Group21: (Item1) Group22: (Item2), Group23: (Item3, Item4)
> GroupKind3: Group31: (Item1, Item2, Item3) Group32: (Item4)
>
> (1)Each Item is assiciated with exactly one Group for each GroupKind.
> (2)Each Group is associated with exactly 1 GroupKind.
>
> We have effectively 3 entity classes: GroupKind, Group and Item.
> The question: how should look like relations between classes in order
> to ensure the rules (1) and (2) without additional constraints?
>
> It's easy to see that e.g. the solution
>
> Item 0..* ---------------- 0..* GroupKind
>           Item_GroupKind
>                |
>                 0..* ------------------ 1 Group
> is not the solution indeed because a Group can corespond here to many
> GroupKinds.

It seems to me the above design is correct. The many-many relationship 
between Item and GroupKind means an item can only appear in a GroupKind once 
which is exactly what you want. The relationship from the Item_GroupKind 
association class can then only point to a single group, thus an item can 
appear in multiple groups, but only one group within a group kind.

What am I missing?

-- 
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Reality is that which, when you stop believing in it, doesn't go
away." — Philip K. Dick 

Post Reply
Re: Groups and Kinds of Grouping
Mon, 13 Aug 2007 10:29:22 +020
I wonder if my question was understandable for anybody?

/Efim

Post Reply
Re: Groups and Kinds of Grouping
Mon, 13 Aug 2007 14:05:27 -050
"Efim Mett" wrote
> Why do you need GroupKindItemGroup?

May not in the final design--but I generally tend to start off with explicit
relational objects--we can remove them later is they prove uninteresting.

> What multiplicities do you presume for
> the association GroupKindItem ------ Group in your design?

Wasn't thinking multiplicities (the relationship between a GroupKindItem and
a Group is probably 1::1), but of behavior. For example

  --what happens when a new groupKind is created?
  --what happens when a new Item is created?
  --what happens when (from your original diagram) Item1 from GroupKind2
moves from Group21 to Group22 (leaving Group21 empty). If "it can be
assumed
that each Group contain at least 1 Item" then this action must either
fail,
or result in destroying Group21.

Starting off with the relational objects gives me a place to start putting
this interaction behavior.

bobD

Post Reply
<< Previous 1 2 3 4 5 6 Next >>
( Page 1 of 6 )
about | contact