And I would add that it helps to 'release yourself' from the
constraining language that your colleagues use to describe what they in
their own special way refer to as entities.

Invariably, collective nouns used in every-day language are not really
the entities of interest, but - if you will - a Users' View of a
work-practice collection.

For example, I'm modelling a system where people go out and measure
samples (RESULT) for a particular 'THEME' such as Birds, Insects etc...

So you would assume a THEME (parent) 'owns' many RESULTs (child)
collected for that Theme.

In fact, Results are really the measurable outcome from applying a
METHOD - in this case counting birds, counting insects, weighing
insects etc.

The same METHOD may be associated with birds, or insects or a host of
other Themes.

So the application of a METHOD (count 'em, weight 'em etc.) to a
particular THEME (Birds, Insects) etc. is probably a SAMPLING EVENT.

A user's 'collective' is not necessarily, and perhaps rarely, the db
designers entity...bit different to how it appeared at first blush.

(and yes there may be at least 3 other models that might apply having
not bothered to explain the business logic any better than this).

Cheers