In our first tutorial we have seen some basic concepts about cloud and cloud vendors. We learned that Salesforce.com is one such cloud vendor who has gained popularity due to its flexible service offering.
In this second tutorial we will see some more concepts about database in Salesforce.com. We will see how salesforce relates to other RDBMS databases available out there. We will see the similarities in the concepts but difference in naming and execution. We will see how data is created, relationship among data is maintained.
Here is the first article in case you missed to go through.
2.1 Overview of Database Concepts
In Salesforce.com Database is an organized collection of objects. The term object refers to information. We use database tables to collect (or store) the information about things, people, or concepts which are important for us and may require in the project for further use. In salesforce we refer this information as object. In a database the information in the table is presented with rows and columns. Salesforce its maintained as Record and Field. Example in an Employee table the information about ID, Name, Contact Information, Designation, Salary etc is stored. So Salesforce terms Employee would be an Object and ID, Name etc would be its Fields
2.2 Database Structure
In Salesforce.com objects are of three types:
- Standard Objects: These are the objects that are pre defined by the salesforce and readily available.
- Custom Objects: These are the objects created by user according to their need .Each custom object has five standard fields (refer Note 2.2.1)
- External Objects: These are the custom objects which are used to map the data stored outside your organization.
- ID: This is an index allocated to each object. This value is unique. ID can be of 15 digit (Case sensitive) and 18 digits (Case insensitive)
- Created Date/ Created By
- Last Modified Date/ Last Modified By
Apart from this salesforce.com provides some objects available in the API, we can access only authorized objects. The access to objects is determined by many factors such as object configuration, user permissions, access settings, data sharing model, and other factors related specifically to the object. Most of the objects accessible through the API have read-write access. However, few objects are read-only.
Relationships defined in Salesforce.com
There are several relationships which can be defined on databases. Relationships associate one object with other object. Relationship is always defined on the child object. The child object has complete access of the parent. Based on the handling of data deletion, record, ownership, security different types of relationships are categorized in to following ways:
1) Many to One (Many child objects but one Parent Object)
E.g. many metro cities are associated to One Country.
This kind of relationship is represented in four different forms like
- LookUp (Loosely Coupled Relationship)
Master-Detail (1: n) — (One Parent Object and Many Child Objects)
- The record of child object gets automatically deleted when we delete the master object.
- To create a child object parent object reference field is required.
- Child object does not have separate sharing but it derives from Parent object, the detail records inherits the sharing and security settings of respective master record.
- The Owner field is automatically set to the owner of its associated master record as owner field is not available at detail side (child object).
- The detail record must have the master detail relationship field on its page layout.
- Administrators select Allow reparenting option in the master-detail relationship definition to represent child records in master-detail relationship on custom objects.
Master-detail relationships can be defined on two custom objects. One can define this relationship between one custom object and one standard object but in such relationship the standard object cannot be on the detail side of a relationship with a custom object. The data of custom object is displayed on page layout.
Note: master-detail relationship can’t be created on objects where the User or Lead objects are the master.
Lookup (1: n) — Lookup is also one-to-many relationship but in this relationship two objects has no effect on deletion or security.
- Child objects are independent
- Child object have separate setting
- If we delete parent object child object will remain in system.
- Child may or may not have parent.
Self : In this relationship the object is self-referred. E.g. Add on Card on your credit card
Hierarchical: This is also (1: N) Lookup relationship but can only be defined on User object. In this we can use lookup field to associate one user with other user. User objects may not directly or indirectly refer to itself.
2) Many-to-many– master-detail relationships can be used to model many-to-many relationships between any two objects. In many-to-many relationship each record of one object is linked with multiple records from another objects and vice versa. We need to create custom junction object to create a many-to-many relationship and then master-detail relationship fields, are linked with this objects.
- Junction object: This object is used to create Many-to-Many relationship. Salesforce support two relationship master detail and Lookup but both are 1:n that is one-to-many. To define many-to-many relationship we need third object and that is called junction object.
2.3 Normal (Excel based) Database vs. Relational (Salesforce.com) Database
- In Normal or excel based systems it may lead to have duplicate information for several times. While in Relational database the information is instances only once but can be referred by multiple fields.
- Generating a report out of excel is tedious while salesforce.com comes with many pre defined reports and report parameters
That’s all for this session. Please come back to us if you have any questions related to Salesforce.com. Stay tuned for our next article in this tutorial series.