SFDC Database Basics
0 likes27 views
This document provides an overview of Force.com databases including standard and custom objects, fields, relationships, and querying. Key points include: standard objects contain core CRM data while custom objects are defined by developers; fields include standard, custom, and field types like auto-number, formula, and encrypted fields; relationships include lookups, master-details, and hierarchical relationships; and querying is done through SOQL for structured queries and SOSL for full-text search.
SFDC Database Basics
- 1. Force.com Database Sujit Kumar Zenolocity LLC © 2012 - 2024
- 2. Overview • Standard and Custom Objects • Standard and Custom Fields • Ids, Formula Fields, Validation Rules • Rich Data Types, History Tracking • Relationships: Master-Detail, Lookup • Introduction to SOQL and SOSL • Methods of Data Import • External ID Fields, Encrypted Fields • Self and Hierarchical Relationships • AutoNumber Fields, Rollup Summary Fields
- 3. Objects • Standard and Custom Objects. • Objects related to tables and fields are related to columns. • Standard Objects – data for CRM or core functionality like user identity. Can be extended by adding user defined fields. • Custom objects defined by developer to build business apps.
- 4. Custom Objects • Logical but not physical. No physical database tables created for custom objects. • No physical representation accessible to the developer. • Tuning is not developer’s responsibility. • Undelete support via “Recycle bin”. They can expire in the Recycle bin.
- 5. Fields • Standard and Custom • Standard fields are created by Force.com • Custom fields are created by developer. • Custom fields are also logical but not physical.
- 6. Unique Ids • Every object has a standard field called Id. • 18-character, case-insensitive, alphanumeric string to uniquely identify each record. • Can also be expressed as a 15-character, case-sensitive string. • Both styles of IDs can be used interchangeably.
- 7. Validation Rules • Place restrictions on the values of a new or updated record. • Defined using an expression language.
- 8. Formula Fields • Formula fields contain values that are automatically calculated by Force.com. • Derived from other fields in the same object or in different objects. • Use the same expression language as validation rules.
- 9. Rich Data Types • Supports typical types like String, Number, Date/Time & Boolean data types. • Rich data types map to direct usage in UI with prebuilt validation, input masks and output formatting. • Examples of rich types: phone, picklist, multi-select picklist, email, URL and rich text area. • Picklist types maintain their own IDs allowing their labels to be modified without updating the records that reference them.
- 10. History Tracking • Allows 20 fields of an object to be audited. • Every object that has history tracking enabled has a corresponding History object with old and new values for every change. • Records in history object cannot be deleted !
- 11. Relationships • Similar to those found in RDBMS. • 1-1, 1-many, many-to-many. • Foreign keys are mandatory & always-on. • Polymorphic foreign keys are allowed for standard objects but not custom objects. • Do not specify join conditions for queries (except for semi-joins and anti-joins). • In join queries, specify the fields you want and Force.com takes care of traversing the necessary relationships to retrieve the data.
- 12. Query Languages • SOQL : SalesForce Object Query Language • SOSL : SalesForce Object Search Language. Used to search the full text of 1 or more objects. • SOQL – structured search • SOSL – unstructured search • SOQL is quite different from SQL. It is more like a reporting or object query language.
- 13. SOQL Features • Implicit Join – no concept of join other than semi-join and anti-join. • Example: SELECT OrderId, (SELECT LineItemId FROM OrderLineItems) From Orders • No functions in select list except aggregate functions like count. But aggregate functions can’t be used in a query containing any other fields in the SELECT list.
- 14. SOQL Feature (contd…) • Governor Limits – based on licensing agreement with SalesForce.com • Examples of governor limits: # of records that can be queried at a time. amount of memory used. size of messages sent between Force.com and external hosts.
- 15. SOSL Features • full-text search capabilities across many objects and fields simultaneously. • Inefficient to do this using SOQL. • Example: FIND 'java*' IN ALL FIELDS RETURNING Project__c, Resource__c, Assignment__c, Skill__c
- 16. Comparison with Web Application Development • With Force.com, either you are coding “on the platform,” which is akin to writing stored procedures. • Or you are developing a “composite application,” which executes somewhere else but integrates with Force.com data and logic. • Access Force.com data by using a web services API – equivalent to a JDBC driver. • ORM built into the platform and available to Apex code. • Force.com does not use DDL but has its own XML schema for metadata. Metadata API for importing metadata XML into the platform. Supports sharing model like ReadWrite. • Generated UI - tightly integrated with the data model.
- 17. Developer Edition (DE) • DEs are also knows as organizations or orgs. • Size of the org depends on the licensing agreement with SalesForce. • DE orgs are full featured but limited storage and limited # of users -> 20 MB files, 20 MB of data, 2 full users and 3 platform-only users. • Sandbox or Enterprise Edition (EE) allow testing with production data and user volumes.
- 18. Free Edition (FE) • FE is free for a single application with up to 100 users, 10 custom objects, 1GB of storage, and an additional linked DE org called a Developer Sandbox. • The Sandbox can be refreshed with the full contents of an FE account (metadata and data) with a single click. • Useful for testing your app with a larger org before upgrading to EE
- 19. Importing Data • Data Loader – Admin setup – Data Mgmt • Import Wizard – Admin setup – Data Mgmt • Excel Connector – excel add-in – allows import and export.
- 20. Defining Custom Objects • Only 2 fields are required – the label and the plural form. • Object Name : used in Apex code, formula fields and validation rules. Auto populated from label name but can be set manually. • Object name appended with “__c” to differentiate from standard objects. • Record Name Label – used on the UI as a label for the record. • Record Name Format – Auto Number Type causes names to be auto generated from a pattern or a Text Type with a max of 80 chars. Uniqueness not required.
- 21. Defining Custom Fields • Field Names – similar to custom object names. • Field names – used in Apex code, formula fields and validation rules. • Auto populated from Field Label but can be set manually. • No spaces in field names. • Automatically appended with “__c” to differentiate from standard fields.
- 22. Defining Custom Fields (contd…) • Text fields – ONLY Unicode – 1 to 255 chars. • Text Area – same as text fields but also allows line breaks. • Text Area Long and Text Area Rich – upto 32000 characters – only first 2048 are searchable. • Text Area Rich can store images and formatting info as well.
- 23. Defining Custom Fields (contd …) • Record Types can be used to create multiple picklists for the same field to be shown to different types of users based on their profile. • Number: 1 to 18 digits long, decimal places included. Currency and Percent are also Numbers but add type-specific formatting, such as a dollar sign.
- 24. External ID check box on custom fields • Text and Number fields can be designated as External IDs. • By default, the only unique identifier on an object is the standard Id field. But if ExternalID is checked, a custom field can be used to uniquely identify records. • External ID is not unique by default, needs to be chosen as unique. • Searchable from the Search sidebar. • Each object can have a max of 3 External ID fields.
- 25. Encrypted Fields • Are text fields that can contain letters, numbers, or symbols but are encrypted. • Value is only visible to users that have the “View Encrypted Data” permission. • Cannot be unique, an external ID, or have default values. • Not available for use in filters such as list views, reports, roll-up summary fields, and rule filters. • Cannot be used to define report criteria but they can be included in report results. • Not searchable but they can be included in search results. • Only the <apex:outputField> component supports presenting encrypted fields in Visualforce pages.
- 26. Encrypted Fields (contd…) • Can still validate the values of encrypted fields using validation rules or Apex. • Existing custom fields cannot be converted into encrypted fields nor can encrypted fields be converted into another data type. • To encrypt the values of an existing (unencrypted) field, export the data, create an encrypted custom field to store that data, and import that data into the new encrypted field.
- 27. Relationship Fields • Express 1-1, 1-many and many-to-many relationships. • Do not create an object for every table as a rule. Normalization is good but adds complexity in code. • Force.com has hard limits on the distance between objects that can be joined.
- 28. Relationship Fields (contd…) • When you are querying a child object & referencing data from parent objects, the maximum number of objects that can be referenced is 5. • In the reverse scenario in which the query is against a parent and references the child, the maximum is 1. • Use workarounds, such as using formula fields to consolidate fields from distant objects.
- 29. Lookup Relationships • Default choice – they are most flexible. • Up to 25 on a single object. • Maintain their own record of ownership. • Child records can be reassigned to a new parent. • No automatic cascade delete.
- 30. Master-Detail Relationships • Useful for enforcing mandatory relationships, in which a child record cannot exist without its parent record. • All child records in a M-D relationship must have a parent record specified. • Automatic cascade delete behavior. • Up to 4 nested levels of M-D relationships can be created => a child can have a great-grandparent object but not a great-great-grandparent. • Allow aggregation of child records through roll-up summary fields.
- 31. Master-Detail Relationships (contd…) • A single object cannot be the child in more than two Master-Detail relationships. When an object is the child of 2 M-D relationships, that object is referred to as a Junction Object. It joins two parent objects in a many-to-many relationship. • After a child record has referenced its parent record, it cannot be reassigned to a new parent record.
- 32. Lookup &Master-Detail Relationships • LR: Child records exist independent of parent MD: Child records cannot exist without parent • LR: Independent ownership MD: Always owned by parent record • LR: No cascading behavior MD: Deletion of parent cascades to delete children • LR: No roll-up fields MD: Roll-up summary fields supported • LR: Unlimited nesting, although limited by SOQL MD: Up to four nested levels
- 33. Self and Hierarchical Relationships • A self relationship is a lookup relationship to the same object. Example: you can have a self-relationship from Position to Position. • A Hierarchical Relationship is a special lookup relationship available only for the user object. • Allows users to use a lookup field to associate one user with another that does not directly or indirectly refer to itself. • For example, a custom hierarchical relationship field can be used to store each user's direct manager.
- 34. AutoNumber field Type • Read-only text fields with a maximum length of 30 characters. Equivalent to identity or sequence fields in RDBMS. • Define the length, a display format used to generate values, and the starting number. • Example: Car-{0000} and a starting number of 200, the Auto Number field in the first record will contain a value of Car-0200.
- 35. Other Field Types • Formula Fields: read-only fields whose values are calculated by Force.com based on the expression specified. • Roll-Up Summary Fields: allow child records in a Master-Detail relationship to be summarized and the result stored in the parent record.
Editor's Notes
- #12: Many standard objects contain special fields that can be related to multiple object types. For example, a support case can be assigned to an individual user or a group representing a collection of users. In the Case object, the OwnerId field can contain the ID of a record in the User object or the Group object. Both types of foreign keys are valid.