Definitely read Henric Cronström's blog post mentioned above. Definitely read Radoslaw Korga's comment on that blog. And definitely look at what Sunny T posted above as well.
The primary question to ask yourself is what ROLE each of these fields are playing on each of their tables, what relationship they have to each other. Henric talks about one way the roles of these fields may be different in different tables, and how that might suggest a particular way of splitting the tables apart.
Radoslaw proposes a different way of storing the relationships, a more generic way, a way I find generally more appealing, though the two approaches will lend themselves better and worse to different sorts of analysis, so neither is strictly best. You use what best supports the particular needs of your users. If you're unsure what best supports them, understand better what sort of analysis they want to do, and experiment with both approaches to understand the differences.
But what if you've looked at the roles and relationships between the fields, and they simply are all the same? Well, if the relationship is always the same, then Radoslaw's star schema doesn't need the relationship field, and the whole thing can collapse down into a single fact table. And that, essentially, is what Sunny T is showing - what to do if the relationships between these tables are consistent, and you have the ability to join them all together with no ill effects, duplicated rows, etc.
