Best way to represent (store ) area of a region

Question

Well I am developing a simulation where agents in tribes (groups) can compete for how much of the area they own in a map of a fixed size.(The map is 2D map). They compete through fighting with each other in groups and the winning group gets the owned by the other group.This simulation is written in java.

The main issue I am trying to get some ideas towards is how should I store how much of the map each group owns.At first I though of just using an instance of Dimension where it then each time a group of agents wins over an area it adds it to the Dimension.The issue however is that areas owned can be in any position in the map with gaps in-between areas as it can be seen in the picture below.(Sorry for the poor picture,was trying to draw the problem using gimp)

NOTE: The rectangles of different colours represent the areas owned by the agents whereas the circles in violet are the agents themselves.

Now another idea was to have an ArrayList of Dimension types holding all the area owned of the agents of specific tribe.

But I am thinking whether there is a better way to do this.

Answer 1

There's a one-to-many (technically a one-to-zero-or-many) relationship between each tribe and how many regions are owned by that tribe. You have 3 basic choices for representing any one-to-many relationship.

1. You can place a reference in each child to the parent
2. You can manage a list of children in each parent
3. You can manage a list of parent-child pairings separately

The question I'd ask yourself is what results are you trying to derive from your simulation? Start from there and work backwards. For example, if your goal is a report by tribe of what is owned, then it may be most efficient to manage a list of regions inside each tribe object. If your goal is a report of regions showing who owns each, then it may be simpler to reference the owning tribe inside the object of each region. It may also be reasonable to manage in both places if you're supporting multiple views.

The third option, managing the relationships outside of the objects themselves, is most useful for times when many-to-many relationships might also be supported, like allowing players to be members of multiple tribes.