Salesforce - Developer - Data Modeling
https://trailhead.salesforce.com/data_modeling/object_relationships
https://help.salesforce.com/articleView?id=overview_of_custom_object_relationships.htm&language=en_US&type=0
https://developer.salesforce.com/page/An_Introduction_to_Force_Database
https://developer.salesforce.com/page/Build_Your_Cloud_Database
https://developer.salesforce.com/page/Architecting_Force.com_Apps_A_Design_Primer
https://help.salesforce.com/articleView?id=dev_objectedit.htm&language=en_US&type=0
// Salesforce - Developer - Data Modeling:
All objects have a number of read-only system fields automatically associated
with them. The ID field, discussed above, is one such field. Others include:
1. CreatedDate—the Date and time when the object was created.
2. CreatedById—the ID of the User who created the object.
3. LastModifiedById—the ID of the User who last modified the object.
4. LastModifiedDate—the date and time when the object was last modified by a user.
5. SystemModStamp—the date and time when the object was last modified by a user
or process, such as a trigger.
The database automatically assigns values to these fields when an object is
created or modified.
Name Field:
The name field of an object is a required field that has a special place in the
life of the object. The record name is intended as a human-readable identifier
for a record. It's not required to be a unique identifier, but it is supposed
to be the primary way users distinguish one record from another. In the
automatically generated user interfaces, you’ll see that the value for the
name is always displayed as a link to the record itself, to its own detail page.
A name can be one of two types: a text string or an auto-number field. For an
auto-number field, you must specify the format for the field and the starting
number. Auto number fields increment by one each time a record is created.
Custom Field:
We can also define custom field. See the Data Types page for different data
types.
Relationship Fields:
The Force.com database differs from relational databases in the way that record
relationships are implemented. Instead of having to deal with primary keys and
foreign keys, to define relationships between data, Force.com uses relationship
fields. A relationship field stores the ID of the parent record in a
relationship, as well as optionally providing user interface representations
in both the parent and child records.
You can define two types of relationship fields:
1. Lookup—This creates a relationship that links one object to another object.
The relationship field allows you to navigate from records in one object to
the related records in another object (both visually, and programmatically).
Lookup relationships can be used to create one-to-one and one-to-many
relationships.
2. Master-Detail—This creates a special type of relationship between two objects
(the child, or "detail") and another object (the parent, or "master").
Master-detail relationships can be used whenever there is a tight binding
between two objects. For example, consider a blog and blog posts. If the
blog is deleted, the blog posts should go too. They can also be used to
create many-many relationships. The master object in a master-detail
relationship can also contain rollup summary fields. These fields store
values aggregated from the child records in the relationship. For example,
you can use these fields to count the number of child records, sum values in
field of a child record, or determine the maximum/minimum of a field in a
filtered set of child record.
The use of relationship fields greatly simplifies the task of designing and
implementing an effective data model for your app.
Other Features of Objects:
Here is a partial list of features available with all objects.
1. Formulas—Formulas can be used in many places, such as setting up validation
rules, creating workflow rule criteria, and even to define a field. A
formula field type behaves much like a spreadsheet formula—it reflects some
calculation based on other fields and operations on those fields. The formula
language is a rich expression language that lets you perform calculations
and manipulate strings, dates, numbers and regular expressions.
2. Validation—Validation rules help improve data quality by preventing users
from saving incorrect data. These rules use the same formula syntax as found
in formula field types to define a formula which is evaluated each time a
record is saved. If the formula for a validation rule evaluates as “True”,
the save is aborted and an error message displayed. You can define one or
more validation rules that consist of an error condition and corresponding
error message. For example, you can create a validation rule to ensure that
a number falls within a particular range.
3. Triggers—Triggers, written in the Apex language, are pieces of code that can
fire before or after a record is saved, updated or deleted.
4. Labels—Every object and record has a label and can include a description,
for help, which is automatically included in the user interface.
5. Notes and Attachments—You can create, view, and edit notes and add
attachments for any record in an object that has this functionality enabled.
This provides users of the object the ability to easily add arbitrary text
notes, and upload associated documents, for each record.
6. Track Field History—Certain fields on your objects can be configured to
track their history. Any time a user modifies any of the field data whose
history is set to be tracked, a new entry is added to an automatically
created History related list. This History list tracks the date, time,
nature of the change, and who made the change.
7. Security—Database services provide a flexible security model that you can
use to control who has access to objects, records and/or fields.
In most cases, you can simply activate and configure these features on your
objects to get the desired functionality.
The Force.com database differs from relational databases in the way that record
relationships are implemented. Instead of defining relationships through primary
keys and foreign keys, the database uses relationship fields. A relationship
field is a custom field on an object record that contains a link to another
record.
Just as a personal relationship is a two-way association between two people, in
terms of relational data, a relationship is a two-way association between two
objects. Without relationships, you could build out as many custom objects as
you can think of, but they'd have no way of linking to one another.
With relationships, you can display data about other related object records on
a particular record's detail page. A relationship field stores the ID of the
parent record in a relationship, as well as optionally providing user interface
representations in both the parent and child records.
Relationships Allow Information about Other Object Records to be Displayed on a
Record Detail Page.
For example, suppose you’re building a recruiting app that contains custom
objects for Position and Job Application. If you define a relationship between
the Position and Job Application objects, each position record can have a
related list of all the job applications for candidates who have applied for
the position. Then a job application record can have a link to each position
for which that candidate is applying.
Types of Object Relationships. There are two main types of relationship fields.
1. Lookup: This creates a relationship that links one object to another object.
The relationship field allows you to navigate from records in one object to
the related records in another object (both visually and programmatically).
Lookup relationships can be used to create one-to-one and one-to-many
relationships. When you define a lookup relationship, you have the option to
include a lookup field on the page layouts for that object as well as create
a related list on the associated object's page layouts. For example, if you
create a lookup relationship field on a Job Application object that
references position records, many job application records can be related to
a single position record. This will be reflected both with a new Position
field on the job application record and with a new Job Applications related
list on the position record. You can also put multiple lookup relationship
fields on a single object, which means that the Job Application object can
also point to a Candidate object.
2. Master-Detail: This creates a special type of relationship between two
objects (the child, or detail) and another object (the parent, or master).
This type of relationship closely links objects together such that the
master record controls certain behaviors of the detail and subdetail record.
In a master-detail relationship, the ownership and sharing of detail records
are determined by the master record, and when you delete the master record,
all of its detail records are automatically deleted along with it.
Master-detail relationship fields are always required on detail records.
Master-detail relationships can be used whenever there is a tight binding
between two objects. For example, say your recruiting app has a Review
custom object that contains an interviewer's feedback on a job application.
If you delete a job application record, you will probably want all of its
review records deleted as well. In this case, you would create a
master-detail relationship on the Review custom object with the Job
Application object as the master object.
The master object in a master-detail relationship can also contain rollup
summary fields. These fields store values aggregated from the child records in
the relationship. For example, you can use these fields to count the number of
child records, sum values in field of a child record, or determine the
maximum/minimum of a field in a filtered set of child record.
Differences Between Lookup and Master-Detail Relationships:
There are fundamental differences between the two types of relationships in
areas such as data deletion, sharing, and required fields in page layouts.
Master-detail relationships are typically used when there is a direct dependency
between the two objects. These relationships have the following unique features.
1. You can’t create a detail record without a master record.
2. When you delete a master record, all its detail records are automatically
deleted.
3. The detail record inherits sharing rules from the master record.
4. The number of master-detail relationships you can use are limited, depending
on your edition and license.
5. You can’t set profile object permissions for a detail record. The detail
record inherits permissions from the master record.
6. Master-detail relationships are automatically included in report record types.
Lookup relationships are appropriate when a relationship between two objects is
required in some cases, but not always. Typical scenarios for lookup
relationships are:
1. To reference commonly shared data, such as reference data.
2. To relate multiple parent records to the child record.
3. To link two objects together when you don't want the behavior of the
master-detail relationship, such as sharing rules, profile permissions and
cascade delete.
4. If the detail object has its own tab, then you probably want to use a lookup,
and not a master-detail, relationship.
You can convert a master-detail relationship to a lookup relationship as long as
no roll-up summary fields exist on the master object. You can convert a lookup
relationship to a master-detail relationship, but only if the lookup field in
all records contains a value.
To Create a Lookup Relationship. Suppose you want to associate a hiring manager
with a position by putting a lookup relationship field on the Position object.
The lookup field allows users to select the hiring manager for the position by
selecting from all the users of the Recruiting app. For example, to assign
someone as the hiring manager for the Technical Writer position, recruiters can
click the lookup icon (Lookup icon) next to the lookup relationship field. The
hiring manager’s name then appears on the Position detail page.
Let’s say you want to put a Hiring Manager field on the Position object. Create
a many-to-one relationship between the Position object and the standard User
object that comes with every org. This relationship reflects that a hiring
manager can be responsible for several positions at a time.
To create the lookup relationship fields:
1. From Setup, enter Objects in the Quick Find box, then select Objects.
2. Click Position.
3. In the Custom Fields & Relationships related list, click New.
4. Select Lookup Relationship, and click Next.
5. In the Related To drop-down list, choose User, and click Next. User is a
standard object that comes with all organizations on the platform. It
contains information about everyone who uses the app in your organization.
6. In the Field Label text box, enter Hiring Manager. Once you move your cursor,
the Field Name text box is automatically populated with Hiring_Manager.
7. Click Next.
8. Accept the defaults in the remaining two steps of the wizard.
9. Click Save.
You can also create a hierarchical relationship between objects. A hierarchical
lookup relationship is available only for the user object. It lets you use a
lookup field to associate one user with another who’s not automatically linked
to the first user. For example, create a custom hierarchical relationship field
to store each user's direct manager.
Create a Master-Detail Relationship. Let’s continue with the example of the
recruiting app. Interviewers, recruiters, and hiring managers create reviews so
they can record their comments about each candidate's job application, and rate
the candidate's suitability for the position. They also read the reviews posted
by other people. To enable our users to do these tasks, we'll create a custom
Review object and relate it to the Job Application object.
The Review object has a many-to-one relationship with the Job Application object
because one job application can have one or more reviews associated with it. A
related list on the job application record shows the associated reviews,
representing the “many” side of the relationship.
Review Has a Many-to-One Relationship with Job Application. However, instead of
creating this relationship with a lookup relationship field, you can use a
master-detail relationship field. A master-detail relationship field makes
sense in this case because reviews lose their meaning when taken out of the
context of a job application. Accordingly, you want your app to automatically
delete reviews when you delete a job application to which they're related.
To create the master-detail relationship field to relate the Review object with
the Job Application object:
1. From Setup, enter Objects in the Quick Find box, then select Objects.
2. Click Review.
3. In the Custom Fields & Relationships related list, click New.
4. Select Master-Detail Relationship, and click Next.
5. In the Related To drop-down list, choose Job Application, and click Next.
6. Click in the Field Name text box and enter the field name Job_Application.
7. Select the Read/Write radio button.
8. Check Child records can be reparented to other parent records after they are
created if you want to be able to change the relationship field’s value. If
you leave this box unchecked, you can’t change the value in the future.
9. Click Next.
10. Accept the defaults in the remaining three steps of the wizard.
11. Click Save.
This sharing setting prevents people from creating, editing, or deleting a
review unless they can also create, edit, or delete the associated job
application.
You can also create a master-detail relationship with multiple levels. With
multilevel master-detail relationships, create reports that roll up data from
all levels of the data model, and trigger cascading deletes when a master
record is deleted. For example, you want a candidate’s applications and review
records to be deleted when a hiring manager deletes a candidate. Create a new
master-detail relationship field that relates the Job Application object with
the Candidate object. The Review and Job Application objects are already related
to each other in a master-detail relationship, so you’ve built a multilevel
relationship where Candidate is the master, Job Application is the detail, and
Review is the subdetail.
To Create a Many-to-Many Relationship. You can use master-detail relationships
to model many-to-many relationships between any two objects. A many-to-many
relationship allows each record of one object to be linked to multiple records
for another object, and vice versa. For example, suppose your recruiting app has
a custom object called Website that stores information about various employment
websites. You want to track which open positions are posted to those sites. Use
a many-to-many relationship because:
1. One position could be posted on many employment websites.
2. One employment website could list many positions.
Instead of creating a relationship field on the Position object that directly
links to the Website object, we can link them using a junction object. A
junction object is a custom object with two master-detail relationships, and is
the key to making a many-to-many relationship. To create a many-to-many
relationship, you first create the junction object, then create the two
master-detail relationships for it.
Let's look at a typical scenario in the recruiting app. There are open positions
for a Project Manager and a Sr. Developer. The Project Manager position is only
posted on Monster.com, but the Sr. Developer position is harder to fill, so it's
posted on both Monster.com and Dice. Every time a position is posted, a job
posting record tracks the post. As you can see in the following diagram, one
position can be posted many times, and both positions can be posted to the same
employment website. In relational database terms, each job posting record is a
row in the Job Posting table. Each row consists of a foreign key to a position
record, and a foreign key to a website record.
So, to define a many-to-many relationship between the Position and Employment
Website objects, you’d create a Job Posting object with the following fields:
1. A Position master-detail relationship
2. A Website master-detail relationship
Using a Job Posting Object to Create a Many-to-Many Relationship Between
Positions and Employment Websites. To handle this scenario, you can create a
junction object called Job Posting. A Job Posting record represents a posting
about a single position on a single employment website. In essence, the Job
Posting object has many-to-one relationships with both the Position and Website
objects. Through those many-to-one relationships, the Job Posting object also
creates a many-to-many relationship between the Position and Website objects.
To Create the Junction Object:
1. From Setup, enter Objects in the Quick Find box, then select Objects.
2. Click New Custom Object.
3. In the custom object wizard, consider these tips specifically for junction
objects:
a. Name the object with a label that indicates its purpose, such as JobPosting.
b. For the Record Name field, we recommend using the auto-number data type.
c. Leave the “Launch New Custom Tab Wizard after saving this custom object”
box unchecked before clicking Save. Junction objects don’t need tabs.
To Create the Two Master-Detail Relationships:
1. On the junction object, create the first master-detail relationship field.
In the custom field wizard:
a. Choose Master-Detail Relationship as the field type.
b. Select one of the objects to relate to your junction object. For example,
select Position. The first master-detail relationship you create on your
junction object becomes the primary relationship.
c. Give your master-detail relationship a name.
d. Select a Sharing Setting option. For master-detail relationship fields,
the Sharing Setting attribute determines what access users must have to a
master record to create, edit, or delete its associated detail records.
e. Optionally, add your new field to the page layout.
f. For the Related List Label that displays on the page layout of the master
object, don’t accept the default. Change the label to the name of the
other master object in your many-to-many relationship. For example,
change it to Websites so users see a Websites related list on the
Position detail page. We haven’t created a custom object called Website
as part of this module. To try out this step, create a custom Website
object using the steps from the Creating Custom Objects and Fields unit.
2. On the junction object, create the second master-detail relationship. In the
custom field wizard:
a. Choose Master-Detail Relationship as the field type.
b. Select the other desired master object to relate to your junction object.
For example, select Website. The second master-detail relationship you
create on your junction object becomes the secondary relationship. If you
delete the primary master-detail relationship or convert it to a lookup
relationship, the secondary master object becomes primary.
c. Select a Sharing Setting option.
d. For the Related List Label that displays on the page layout of the master
object, don’t accept the default. Change the label to use the name of the
other master object in your many-to-many relationship. For example, change
it to Positions so users see a Positions related list on the Website
detail page.
For a many-to-many relationship, each master object record displays a related
list of the associated junction object records. For a seamless user experience,
change the name of the junction object related list on the master object page
layouts to the other master object’s name. For example, change the JobPosting
related list to Positions on the websites page layout and to Websites on the
positions page layout. You can further customize these related lists to display
fields from the other master object.
You can change the parent record for a child record in a master-detail
relationship. To enable this option, select the Allow reparenting option in
the master-detail relationship field definition. By default, you cannot
“reparent” records in master-detail relationship.
A lookup relationship field is optional but you have the option to make it
required. When a lookup field is optional, you can specify one of three actions
to take place on dependent lookup fields when someone deletes a referenced
lookup record.
1. Clear the value of this field: This is the default option. Setting a lookup
field to null is appropriate when the field does not have to contain a value.
2. Don’t allow deletion of the lookup record that’s part of a lookup
relationship: This option restricts the deletion of a lookup record that has
dependencies, such as a workflow rule built on the relationship.
3. Delete this record also: This option cascades the deletion of a referenced
lookup record to dependent records. It is available only for lookup fields
in a custom object; however, the lookup field can reference either a
standard or custom object. Choose this option for tightly-coupled record
relationships when you want to completely delete related data in one
operation
page revision: 9, last edited: 03 Dec 2016 20:01