Learn 2 Salesforce
Relational 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.
Database/Table Example
Philosophers
ID
Firstname
Lastname
1
Bertrand
Russell
2
John
Morley
3
Socrates
Quotes
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 living
4
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.
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
easeOfCare
1
Dog
500.00
Cute, Playful,
Loyal
10
Easy
2
Cat
250.00
Fuzzy, Sharp,
Cuddly
15
Medium
3
Human
1000.00
Walking talking 3
meat.
Id – Salesforce Generated Id (automatically created)
Name – Text (100 chars max)
Price – Currency
Description – Text Area Long (32,000)
Quantity – Number (no decimal points)
Easy of Care – Picklist (Easy, Medium, Hard)
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, oneto-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).
Contact
Account
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
Respondent
Contact
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.