Many to Many Relationships

,

So far, you have defined a couple of Force Platform objects and created a productive link between them. The power of relationships drives data design on the Force Platform, and good development practices suggest that you spend time designing your objects to leverage the full productivity of these relationships. In this section, you will learn about a different tyype of relationships you can easily create in your Force Platform database.

The relationship you created in the previous section is known as a one-to-many relationship. Each Position record is associated with one Location record, and a Location record can be associated with many Position records.

But what about situations that call for a many-to-many relationship? In this type of relationship, a record on each side of the relationship can be associated with many records on the other side.

The Recruiting application you are building contains a good example of this type of relationship. Each Position record can be associated with many different Candidates, an object you will create shortly. And each different Candidate can apply for many different Positions.

Creating a Junction Object

In order to implement this type of relationship, you need to create an intermediate object, referred to as a junction object. This object has a relationship to the objects on both sides of the many-to-many relationship, with a single instance of this junction object for each relationship between an individual Candidate and an individual Position.

1.
Follow to the instructions in the Code Share project for this book, described in Chapter 1: Welcome to the Force Platform, to create the Candidate object and its fields.

2.
Follow the instructions in the Code Share project for this book to create the Job Application object.

The Job Application object is used to create a junction between a Candidate record and a Position record. You are now ready to implement a many-to-many relationship.

Implementing a Many-to-Many Relationship

Your objects are in place, so you can now link the Position and Candidate objects through the Job Application object. As mentioned above, each Candidate can apply for more than one Position, and each Postion can have many different Candidates. The Job Application record links together a single Candidate for a single Position, as well as including other information.

1.
Click Setup Create Objects Job Application to modify the junction object the script just created.

2.
Add a new master-detail relationship field to this object, linking the Job Application object to the Position object.

3.
Accept the default Field Label and Field Name, and give the field an appropriate description and help text. Note that the field is automatically set to required.

You can limit access to this detail record based on the shared setting for the master record. You can either require users to have read and write access to the master record in order to create, edit, and delete this detail record, or you can only require read access to the master record. In this scenario, you probably want to require the more limited access.

Note

You will learn all about the Force Platform security model in Chapter 7: Protecting Your Data.

4.
Select the second Sharing Setting, requiring Read/Write access of the master record, and click Next.

5.
Accept the default security and page layout choices on the next two pages, clicking Save and New on the final page of the wizard.

You want to have a master-detail relationship between the Job Application object and the Position object to be able to use Roll-up Summary Fields to aggregate information about the applications for the jobs.

6.
Add a master-detail relationship from this object to the Candidate object, again including an appropriate description and help text, the more limited Sharing Setting as with the Positions relationship, and accepting the default security and page layout choices. Click Save.

Although you will not have an immediate need to use Roll-up Summary Fields from the Job Application object to the Candidate object, the master-detail relationship is still appropriate here because of the way you want the Candidate and Job Application records to interact. For the purposes of this system, you will want to delete all individual Job Application records once either the Candidate record is deleted or the Position is deleted. The Job Application record is not meaningful if either side of the many-to-many relationship is no long available.

The order in which you define the two master-detail relationships has an effect on the representation of this object in the Force Platform environment. When displaying links to a record in the Job Application object, the icon used is the icon associated with the tab of the first master-detail relationship defined for this object.

With these two steps, you have implemented a many-to-many relationship. You can add more information to this object, such as status indicators that apply to individual Job Applications, rather than an Candidate or Position – an action you will take in the next chapter.

At this time, there is no need to define a tab for Job Application since you will be able to create new Job Application records directly from either the Position or Candidate pages.

Many-to-Many Relationships at Work

Your recruiting application now has the ability to define and use many-to-many relationships. You did not load any data into the Job Application object you defined, so you can see how this object works behind the scenes to implement the relationship.

1.
Click the Positions tab and select a position from the home view. Notice that the Job Applications are now shown as a related list.

2.
Click New Job Application in the Job Applications section to bring up the page shown the following figure to add a new Job Application from the Position.

This page is as you would have expected. No need to add an ID for the Job Application, since that is an Auto Number field, and the Position relationship is automatically included for the new application, since the page was called from a position record.

Figure 42. Adding a new Job Application junction object


3.
Use the lookup button to select a Candidate for the Job Application.

Tip

You can add fields to the lookup dialogs in the same way you modified the fields shown on the Home page by modifying the Lookup Dialogs in the Search Layouts section of an object.

4.
Click Save to save the new Job Application record and return to the detail page for the Position record.

Since the Job Application implements a many-to-many link between Positions and Candidates, you can also create a Job Application from a Candidate record.

5.
Click the Candidates tab and select a candidate.

6.
Click New in the Job Applications related list and associate this candidate with a particular position.

You can add multiple positions for a candidate, or multiple candidates for a position, by using Save and New for the Job Applications page.

Relationships, and the functionality they provide, are one of the core pieces powering the productivity of the Force Platform. Understanding the relationships inherent in your overall data scheme helps you create more flexible applications with cleaner implementations.

Best Practices for Data Design

You have already noticed that a good data design can have a pretty significant impact on your development effort on the Force Platform. You can maximize your developer productivity for both initial implementation and ongoing maintenance work by adhering to a few best practices:

  • Normalize your data into objects, just as you would for tables in a relational database. Since related objects are automatically connected in your Force Platform applications, designing your objects to keep the number of fields limited to those that are directly related to the main purpose of the object is a great approach. Just because you can add more and more fields to an object does not mean that you should. At best, you end up with large pages that present a cumbersome user interface.

  • Avoid duplicating values in many records in an object. Related objects make this easy to implement, so one location, in this sample application, is represented by one, and only one, name and record. By storing a the name of the location in a single Location record, and having multiple Position records access that record, you not only reduce your storage needs, but you make it easier to both maintain data integrity for the name and to change the name, if necessary, down the road.

  • Avoid copying data from one object to another. For instance, it would not make sense to have a Location field in a Position record, copying the value from the Location table. What happens when the value for that location changes in the parent record, or one or more child records, or both at once? Copying data starts out as a bad idea and gets worse, so use relationships to unique parent records to express repeated values.

  • Help your users avoid duplicating data. As the previous two points highlight, duplicate values present problems. Your users may be entering duplicate records unknowingly. The autocomplete feature of search lookups can help them identify the proper related value, but you might want to consider adding logic to your applications to prevent users from accidently duplicating values.

Of course, none of these recommendations should be seen as hard and fast rules. You should use these best practices as your defaults, and take a different approach only when your particular development task requires it.


..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.218.188.95