14

Here's a theoretical/pedantic question: imagine properties where each one could be owned by multiple others. Furthermore, from one iteration of ownership to the next, two neighboring owners could decide to partly combine ownership. For example:

territory 1, t=0: a,b,c,d
territory 2, t=0: e,f,g,h

territory 1, t=1: a,b,g,h
territory 2, t=1: g,h

That is to say, c and d no longer own property; and g and h became fat cats, so to speak.

I'm currently representing this data structure as a tree where each child could have multiple parents. My goal is to cram this into the Composite design pattern; but I'm having issues getting a conceptual footing on how the client might go back and update previous ownership without mucking up the whole structure.

My question is twofold.

  1. Easy: What is a convenient name for this data structure such that I can google it myself?

  2. Hard: What am I doing wrong? When I code I try to keep the mantra, "Keep it simple, Stupid," in my head, and I feel I am breaking this credo.

jaco0646
  • 15,303
  • 7
  • 59
  • 83
Dale
  • 1,220
  • 2
  • 10
  • 20

3 Answers3

16

My question is two fold: Easy: What is a convenient name for this data structure such that I can google it myself?

What you have here is not a tree, it is a graph. A multimap will help you here. But any adjacency list or adjacency matrix will give you a good start.

Here is a video on adjacency matrix and list: Youtube on adjacency matrix and list

Hard: What am I doing wrong?

This is really hard to tell. Perhaps you did not model the relationship in a proper way. It is not that hard, given a good datastructure to start with.

And, as you asked for design patterns (but you probably found out yourself), the Composite pattern will let you model such an setting with ease.

Mare Infinitus
  • 8,024
  • 8
  • 64
  • 113
  • damn, your answer will take time to mull. I suspect there is good stuff. In particular, I hope there is clean literature on graphs with respect to this and not third party stuff. Yes, perhaps I did not model the relationship well... I will get back to you. – Dale Jul 19 '12 at 06:12
  • You are welcome. Given any language that has references or pointers, you do not need third party libraries. If you have further questions, just leave a comment. – Mare Infinitus Jul 19 '12 at 06:17
3

You have a many-to-many relationship between your owners and your territories (properties). I'm not sure what language you're working in, but this sort of thing can be easily represented and tracked in a relational database. (You'd probably want a table for each entity, and the relationship would probably require a third "junction" table. If it's necessary to be able to query "back in time", this could have some sort of "time index" column as well.)

If you are working in an object-oriented language, you might create two classes, Territory and Owner, where the Territory class has a property/member/field which is a collection of references/pointers to Owners and the Owner class has a similar collection of Territories. (One of these two collections may need to contain "weak" references depending on the language.)

In this case, some difficulty may arise if you want to be able to go back and look at the network state at some particular point earlier in time. (If this is what you need, say so and I (or someone else) can post a solution that works for that.)

I'm not sure what level of simplicity you are striving for, but in neither of these cases is updating the ownership relationships really that "hard". Maybe if you posted some code it might be easier to give you more concrete advice.

Turix
  • 4,470
  • 2
  • 19
  • 27
  • I appreciate your line of reasoning. Unfortunately, I have no code. Just a white board of jibberish. I do not believe representing the data this early in the calculation in a database makes much sense, both optimally and conceptually. As far as OOP goes, I was thinking...I cant newline, bear with me: class teritorry { $owners = array(); $lastOwners = array(); $vertices = array();} – Dale Jul 19 '12 at 05:50
  • And....A way to inject ownerships in higher levels of the tree is ABSOLUTELY necessary. – Dale Jul 19 '12 at 05:57
  • @user1119810 I'm not sure I understand your last comment. As Mare Infinitus rightly pointed out, you don't really have a "tree" here, so I'm not sure what you mean by "higher levels". – Turix Jul 19 '12 at 06:30
  • @user1119810 re your pseudocode, if you are keeping track of `$lastOwners`, I assume that means you want to be able to look back in time at least one timestep. Do you need more than that? (If so, an array there is not sufficient.) In addition to that, it's very important what other sorts of "queries" you want to make of this datastructure. For example, will you need to know what a given owner has now and/or in the past? Or are you more interested in territories? Or are you interested in getting collective stats about something like, say, the degree "fat-cat-ness" of your world? – Turix Jul 19 '12 at 06:34
  • wow, turix. Thank you for the question. This too will take time. I will get back to you. I suppose to answer an easy question, by higher levels, I mean, earlier in time. – Dale Jul 19 '12 at 06:57
  • To tell you the truth, I'm not even sure I mean that. – Dale Jul 19 '12 at 07:05
  • It could be that many higher levels are many higher levels in this "tree" – Dale Jul 19 '12 at 07:06
  • Or, perhaps, Rockefeller owned this chunk of dirt "forever." Now what? – Dale Jul 19 '12 at 07:07
0

Hard to tell without more information regarding the business rules. Though I've plenty of experience designing graphs where each node could potentially have numerous parents.

A common structure is the Directed Acyclic Graph. Essential rules here are that no path through the graph can cycle back onto itself. For example take the path "A/B/C/B", this would not be valid as B repeats twice.

  1. Valid:- "A/B/C", "D/E/C", node C has two parents E and B.
  2. Invalid:- "A/B/C/B", node B repeats in the same path causing a cycle.
Rax
  • 665
  • 8
  • 19