Difference between revisions of "Junction Object"

From AgileApps Support Wiki
imported>Aeric
imported>Aeric
Line 18: Line 18:
# Specify the object at the other end of the Junction, and the field to use for indexing.<br>(Typically, the default ''ID'' field is perfect.)
# Specify the object at the other end of the Junction, and the field to use for indexing.<br>(Typically, the default ''ID'' field is perfect.)


That process of creating a relationship adds the second Lookup to the middle object (from Orders_Tags to Tags, in this example), and identifies Orders_Tags as a "junction" object. Because the platform knows it is a junction object, the user sees records from the end-point object (Tags) when doing a look up. (Otherwise, the user would see records from Orders_Tags.)
That process of creating a relationship adds the second Lookup to the middle object (from Orders_Tags to Tags, in this example), and identifies Orders_Tags as a "junction" object. Because the platform knows it is a junction object, the user sees records from the end-point object (Tags) when doing a look up. Otherwise, the user would see records from Orders_Tags.
<noinclude>
<noinclude>


[[Category:Glossary]]
[[Category:Glossary]]
</noinclude>
</noinclude>

Revision as of 18:14, 18 September 2012

In a relational database, a Lookup field in a source object can point to exactly one record in a target object. That capability creates one-to-many and many-to-one relationships. (For example, many Orders point to a single Customer. That's many-to-one. Looking at it the other way around, a Customer has multiple Orders. That's one-to-many.)

But sometimes, you need a many-to-many relationship. (For example, an Order can have multiple tags, and each tag can clearly apply to multiple orders.) You accomplish that goal with a junction object:

JunctionObject-80percent.png

Here, the junction object is Orders_Tags. Every record in it points to exactly one Order and one Tag. But several records that point to the same Order can each point to a different Tag. Similarly, several records that point to the same Tag can each point to a different Order. In that way, a many-to-many (N:M) relationship is established.

Create a Junction Object Manually

You can use the platform's Wizard to create a Many to Many relationship. In that case, the Junction Object is created for you, behind the scenes.

You can also create a junction object manually (a technique you'll need to know if you creating relationships programmatically):

  1. Create the object that will become the junction. For example: Orders_Tags.
  2. Add a Lookup to one of the target objects. For example: Orders.
  3. Go to the Relationships tab.
  4. Edit the relationship.
  5. Select the Junction radio button to make the relationship many-to-many.
  6. Specify the object at the other end of the Junction, and the field to use for indexing.
    (Typically, the default ID field is perfect.)

That process of creating a relationship adds the second Lookup to the middle object (from Orders_Tags to Tags, in this example), and identifies Orders_Tags as a "junction" object. Because the platform knows it is a junction object, the user sees records from the end-point object (Tags) when doing a look up. Otherwise, the user would see records from Orders_Tags.