|
| 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
|
|
|
|
|
|
|
|
|
|