Salesforce - Developer - Data Modeling

salesforce-developer

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
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License