While working on the database, I worry about crazy new ideas infecting my brain which can lead to bad habits which can lead to general insanity. Thus, I have this insatiable urge to blah out my crazy ideas so everyone can make fun of me and strip me of self-respect so I may learn one thing or two. 
The ideas mainly relate to how I make decisions on how to relate groups of entities. Mind you, this is not about "Is this a one-many relationship or a many-many relationship" but more about the overall picture consisting of complex relationships.
So, I'll list what I do use to base my decisions, in no particular order, and if it's half-baked, maybe everyone here can help me bake it completely. Also, I'd love it if anyone else shared their ideas.
Child Table Inheritance
Child tables always inherit parent tables' record entries. This can be proved by executing a query pulling child record using its ID, and including the parent's record.
Does it then follows that when considering which child table should be made a junction table, one can ask whether we want this child to inherit the 'other' parent table's properties to determine which table we need to convert to a junction table?
If a table needs to be a three way junction table, it means it has three parent table to inherit properties from.
Determining inheritance in reverse manner is also a good way to identify the relationship. The_Doc_Man already has made the suggestion of doing a trace to identify how objects are related. I usually start with a paper listing every questions I need to know about a given entity. I then ask myself if this question can be answered by itself. If yes, there is no relationship. But if I say, "Well, I need to know this...", then there's a relationship to be traced, because this question need to inherit that extra information.
PS Forgive me if using the term "inheritance" is odd; it was the one that made most sense to me, coming from a object-oriented programming perspective.
Auxillary junction tables
Suppose we need to create a three way junction tables to describe relationship among three entities that are independent in each own rights. Does it then follow that we need a two way junction table for each pair of parent, a total of three two way junction to complete the relationship?
It seems that if you need to track how a pair of parent may be related, and may need some extra information that is fully dependent on this pair and never for the third entity, then yes, you need that two-way junction table. Another scenario is if you need to enumerate which specific instances of entity can go with another entity, as not all X may be related to all Y or something, necessitating a two way junction table to help identify which instance of X does have such relationship. Otherwise, it is implicitly referred to within the three-way junction table. Is that right?
Preventing Circular References
For a long time, I used to think that if when looking at relationship layout, I could trace starting at a table and end up back at the same starting table, I had a circular reference. However, this seems to not be always the case, as it is possible to have X depend on Y, while Y depends on Z and the pair of X and Z forms a meaningful relationship. This is not same thing as saying "X depends on Y, while Y depends on Z, while Z depends on X", which would be truly circular. Same can be said of self-join, which is self-referential. However, I believe that the correct algorithm could be thus: If the table X is a many side table to table Y which is a many side to table Z, which is many side table to X, then this is a bad set. OTOH, saying that table X being a many side to table Y and Z being many side to Y and X isn't circular. Correct?
That's all I can think of; I'd love it if anybody can critique the suggestions and input their own, helping along to under how we want to organize data.

The ideas mainly relate to how I make decisions on how to relate groups of entities. Mind you, this is not about "Is this a one-many relationship or a many-many relationship" but more about the overall picture consisting of complex relationships.
So, I'll list what I do use to base my decisions, in no particular order, and if it's half-baked, maybe everyone here can help me bake it completely. Also, I'd love it if anyone else shared their ideas.
Child Table Inheritance
Child tables always inherit parent tables' record entries. This can be proved by executing a query pulling child record using its ID, and including the parent's record.
Does it then follows that when considering which child table should be made a junction table, one can ask whether we want this child to inherit the 'other' parent table's properties to determine which table we need to convert to a junction table?
If a table needs to be a three way junction table, it means it has three parent table to inherit properties from.
Determining inheritance in reverse manner is also a good way to identify the relationship. The_Doc_Man already has made the suggestion of doing a trace to identify how objects are related. I usually start with a paper listing every questions I need to know about a given entity. I then ask myself if this question can be answered by itself. If yes, there is no relationship. But if I say, "Well, I need to know this...", then there's a relationship to be traced, because this question need to inherit that extra information.
PS Forgive me if using the term "inheritance" is odd; it was the one that made most sense to me, coming from a object-oriented programming perspective.
Auxillary junction tables
Suppose we need to create a three way junction tables to describe relationship among three entities that are independent in each own rights. Does it then follow that we need a two way junction table for each pair of parent, a total of three two way junction to complete the relationship?
It seems that if you need to track how a pair of parent may be related, and may need some extra information that is fully dependent on this pair and never for the third entity, then yes, you need that two-way junction table. Another scenario is if you need to enumerate which specific instances of entity can go with another entity, as not all X may be related to all Y or something, necessitating a two way junction table to help identify which instance of X does have such relationship. Otherwise, it is implicitly referred to within the three-way junction table. Is that right?
Preventing Circular References
For a long time, I used to think that if when looking at relationship layout, I could trace starting at a table and end up back at the same starting table, I had a circular reference. However, this seems to not be always the case, as it is possible to have X depend on Y, while Y depends on Z and the pair of X and Z forms a meaningful relationship. This is not same thing as saying "X depends on Y, while Y depends on Z, while Z depends on X", which would be truly circular. Same can be said of self-join, which is self-referential. However, I believe that the correct algorithm could be thus: If the table X is a many side table to table Y which is a many side to table Z, which is many side table to X, then this is a bad set. OTOH, saying that table X being a many side to table Y and Z being many side to Y and X isn't circular. Correct?
That's all I can think of; I'd love it if anybody can critique the suggestions and input their own, helping along to under how we want to organize data.