Learn 2 SalesforceRelational Databases For Those Who Like Spreadsheets

So What Are We Talking About?

Salesforce for most people is a big black box. They don’t know how it works, or why it works like it does.

This ‘course’ aims to give you a better understanding of the Salesforce system. Starting with the very basics and moving up from there.

Along with making life easier for the Salesforce admin team, learning what is and is not possible may give you ideas on how we can make it better for you and your team.

Outline

Salesforce is at it’s core is a database. It uses some different terms from standard, but it IS a database. So we’ll start our adventure by learning more about them.

I am going to be teaching this as if you were a database/salsforce admin in training so you can think like one.

So today we will be covering: What is a database? What are objects/tables What are relationships What are the relationship types

Why should I Care? You’ll be less confused when using the system. You may be able to resolve more errors on your own, and

understand various error messages and notices. You’ll understand what I’m talking about more in meetings. You’ll be able to come up with cool ideas that are

implementable to make life easier for you. These skills and knowledge are/is transferable and make you a

more valuable employee.

Oh, and if you pay attention, stay involved and I feel you grasp the topics, I may give you access to some really powerful tools in Salesforce later on (mass update anyone?)

What is a Database?

A database in the simplest form, is an organized collection of data. Usually the data is organized in such way to represent different aspects of reality (such as people, hotel rooms, cars, etc)

You can think of a database as an Excel workbook for now. A collection of data and each tab represents a different thing.

A few terms Before we dig deeper, we will need to define a few terms. Each

term is first shown with it’s standard name, after the slash is how Salesforce refers to it.

Database/Org – Collection of tables that contain data. Table/Object – A collection of similar that share attributes in the

Database (like on page of an excel workbook) Attribute/Field – The vertical columns of a table. Describes the

data contained. Row/Record – The horizontal rows of a table. Null – The complete absence of data. Not 0, but nothingness. A

vacuum. Relationship – A way to link records from one table to another to

share data between them. Primary Key/Lookup – Name for the field that creates a

relationship.

PhilosophersID Firstname Lastname1 Bertrand  Russell2 John Morley3 Socrates

ID ParentID Quote

1 1 The fundamental cause of trouble in the world today is that the stupid are cocksure while the intelligent are full of doubt. 

2 2 Where it is a duty to worship the sun it is pretty sure to be a crime to examine the laws of heat. 

3 3 An unexamined life is not worth living4 1 I would never die for my beliefs because I might be wrong.5 3 As for me, all I know is that I know nothing. 6 2 You have not converted a man because you have silenced him.

Quotes

Database/Table Example

Make Sense?

For the last diagram, see if you can figure out the following.

What were the names of the tables? What was the relationship between the tables? Give an example of a record in the first table Give an example of an attribute in the second table Did either table have an example of null in them?

Answers What were the names of the tables?

Philosophers and Quotes What was the relationship between the tables?

Quotes was linked to Philosophers via the parentId field Give an example of a record in the first table

Bertrand Russell or John Morely or Socrates Give an example of an attribute in the second table

Id or ParentId or Quote Did either table have an example of null in them?

Yes, the first table. Socrates last name was a null value.

Some To Know About Databases

In general attributes/fields (columns) are not created, modified, or deleted during everyday use. They are created during setup and not modified.

Records/Rows can and are created, deleted, and updated frequently.

If your database design cannot handle hundreds of thousands of records without need to modify the structure of the tables, you have done something wrong.

Databases are meant to be searchable. Include fields that make it easy to identify records you are looking for.

Fields/Attributes

There are many kinds of fields. Each is meant to house a specfic kind of data, such as whole numbers (integers), text, rational numbers (has a decimal point), currency and more.

Each database system has it’s own set of field types. Some like those listed above a common in nearly all of them, and each DBMS (database management system) has it’s own unique field types as well.

Salesforce Field Types - Basic 1 Checkbox - Allows users to select a True (checked) or False

(unchecked) value. Currency - Allows users to enter a dollar or other currency

amount and automatically formats the field as a currency amount. 

Date - Allows users to enter a date or pick a date from a popup calendar.

Date/Time - Allows users to enter a date and time, or pick a date from a popup calendar. 

Email - Allows users to enter an email address, which is validated to ensure proper format.

Number - Allows users to enter any number. Leading zeros are removed.

Percent - Allows users to enter a percentage number, for example, '10' and automatically adds the percent sign to the number.

Salesforce Field Types - Basic 2 Phone - Allows users to enter any phone number.

Automatically formats it as a phone number. Picklist - Allows users to select a value from a list you

define. Picklist (Multi-Select) - Allows users to select multiple

values from a list you define Text - Allows users to enter any combination of letters and

numbers Text Area - Allows users to enter up to 255 characters on

separate lines. Text Area (Long) - Allows users to enter up to 32,768

characters on separate lines. URL - Allows users to enter any valid website address.

When users click on the field, the URL will open in a separate browser window.

Salesforce Field Types - Advanced Auto Number - A system-generated sequence number

that uses a display format you define. The number is automatically incremented for each new record.

Formula - A read-only field that derives its value from a formula expression you define. The formula field is updated when any of the source fields change.

Roll-Up Summary - A read-only field that displays the sum, minimum, or maximum value of a field in a related list or the record count of all records listed in a related list.

Lookup Relationship - Creates a relationship that links this object to another object. The relationship field allows users to click on a lookup icon to select a value from a popup list. The other object is the source of the values in the list.

Tables - General We have already had some exposure to tables, but now we are

going to talk a little more about exactly how to use them, and how they are set up.

Tables are composed of attributes/fields (the columns) and rows/records (the rows).

Tables are used to contain records that have attributes in common. Lists of cars, people, events, whatever. They however should not contained mixed sets of data. All things in a table should have one overarching thing in common that binds them together. Otherwise they should be in different tables.

In Salesforce, a table is an object. The contact object is a table. A single contact is a row/record. Accounts, Studies, Contacts, Payments all just tables.

Tables - Design

Plan what kind of data you will need to hold ahead of time.

Use as few fields as possible to keep things clean Use relationships to get data that is in another table

instead of replicating it. Use descriptive, simple attribute names. Attribute names

should not have spaces, or special chars. They must be unique within the table.

All tables, should always, always have an ID field with a value that is unique to every record (Though Salesforce handles this for you).

Choose the closest matching, smallest field type that will hold the data you need.

How would you structure this?

I have a pet store, and I want to keep track of the types of animals we keep. I want to track:

The name of the type of animal A Price for that type of animal A short description of it How many of them I have in stock A value indicating how easy they are to care for.

How many tables would I need? What attributes? What field types are those attributes?

Answer (one of practically infinite)id name price description qunatity easeOfCare1 Dog 500.00 Cute, Playful,

Loyal10 Easy

2 Cat 250.00 Fuzzy, Sharp, Cuddly

15 Medium

3 Human 1000.00 Walking talking meat.

3 Hard

Id – Salesforce Generated Id (automatically created)Name – Text (100 chars max)Price – CurrencyDescription – Text Area Long (32,000)Quantity – Number (no decimal points)Easy of Care – Picklist (Easy, Medium, Hard)

Relationships

No man is an island, and most tables aren’t either. Tables rely on each other to help create a complete picture of an organizations data.

Relating tables allows you to share data between them. Connecting tables in normal databases is done by keys,

and done in Salesforce with lookup, and master-detail relationship fields.

Logistically there are 3 major kinds of relationships, one-to-one, one-to-many and many-to-many.

Relationships - One to One

A one to one relationship is where one record in a table will be related to exactly one other record in another. Type type of relationship is fairly rare, is if this is the case, odds are the two tables could be joined into one.

An example in our database/org would be payments to checks. One payment will spawn exactly one check. Every check has a 1 payment, every payment has 1 check. No more, no less.

Check Check

Relationships – One-to-Many This is probably the most common type of relationship.

One ‘parent’ with many ‘children’. Each child can get information from it’s parent easily.

An example in our org would be accounts and contacts. One account can have many contacts, but contacts can have only one account.

In general it is easy to get parent information when looking at the child, but it is harder to get specific child information when looking at the parent (as you have to specify which child you want).

Account

Contact

Contact

Contact

Relationships Many-to-Many

Many-to-Many relationships are the most complicated, but somewhat frequently used. They make use of what is called a ‘junction’ object to allow connecting of many objects to each other.

An example in our org is Contacts to Respondents to Studies

Contact

Respondent

Respondent

Respondent

Study

Reporting In Salesforce reporting is done by running a query ( a

request to the databse to get some data ). You don’t have to write the actual code for the query, you get to use that nice report builder (You can write the queries directly, but you need a special tool to do that, we’ll talk about that later).

All your design decisions should take reporting into affect. A report can only contain data from the source object (what you decide to report against) and objects it has relationships with.

Always structure your data so that reporting will be easy and meaningful. Don’t use a text field (which could have any value) when a picklist will get you better data to report against.

Summary

Now you should have a basic idea of the structure of a database. When you are using Salesforce you can start to see the underlying principals that power it. What the objects are, the field types, the relationships. Understanding these things will make the system make a lot more sense.

Next time we will talk more about the interplay of parent and child objects. How summarizations/aggregation work, roll-up fields, and the importance of master-detail relationship fields.

Questions? Comments?

I know that was a lot of information, and mostly fairly abstract so feel free to ask anything. Seriously, this stuff is kind of complicated and it’s really important to understand it. Ask. Ask now. Do it. Nobody is going to judge you. I’d rather you ask now than break something later.