Summary

---

Joins can hardly be called an exciting, business-driven subject; however, if you correctly define the parameters covered in Chapter 6 and the joins covered in this chapter, you have built a sturdy foundation for a correct universe. The Classes and Objects covered in the next chapters become the familiar façade that users trust. If, on the other hand, you have made mistakes in the joins, then objects may not work with one another-or, worse, they give users incorrect results. To define joins correctly, keep in mind the following guidelines:

• Define joins based on the actual data and not just the logical business model.

• If you start using contexts, you must keep using them and ensure all tables belong to at least one context.

• Use aliases to create multiple joins between the same two tables that have different business meanings.

• Use shortcut joins to provide faster paths between two tables that have a direct relationship, rather than forcing a join through a fact table.

---