Coming from Salesforce or Pega, you're familiar with the idea of a data model—the structured foundation that holds everything together. ServiceNow operates on a similar principle but with its own unique architecture. At its heart is a relational database where every piece of information, from a user's name to a server's configuration, lives in a table. The master key to understanding this entire structure is the System Dictionary—it's the definitive guide to every table and field within your instance.

You can access it directly through the System Definition > Dictionary module. This isn't just metadata; it's a series of tables that ServiceNow itself uses to build forms, lists, and business logic. The primary table, sys_dictionary, contains a record for every field on every table in the database. Another key table, sys_db_object, holds a record for each table.

ServiceNow makes extensive use of table inheritance to promote reusability. This concept is best understood by looking at three types of tables:

The Task table is a perfect example. It contains common fields needed for any task-based activity, like number, assigned_to, and state. When you create an Incident, Problem, or Change Request, you're using a table that extends Task. This means an Incident record automatically has all the fields from the Task table, plus specific fields like caller_id.

Visualizing these relationships can get complicated. That's where the Schema Map comes in. You can access it from a table's configuration menu. It's an interactive tool that shows you the parent and child tables for any given table, making complex inheritance chains easy to follow.

What if you need an inherited field to behave differently on a child table? For example, perhaps the state field on an Incident record should have different choices than the state field on a Change Request. You can't change the field on the Task table, as that would affect all child tables. The solution is a Dictionary Override a powerful feature that lets you alter a field’s properties on a specific extended table without changing the parent.

Creating relationships between tables is fundamental. In ServiceNow, this is primarily done using Reference Fields. A reference field stores a unique identifier (the sys_id) of a record on another table, but it displays a more human-readable value, like a user's name or an incident number.

This enables a powerful mechanism called dot-walking Dot-walking allows you to pull data from related records directly into a list or script. For example, on a list of incidents, you might want to see the email address of the person assigned to each incident. If your list shows the Assigned to field, you can dot-walk through the reference to the User table to get the Email field. The path would look like assigned_to.email.

Sometimes you need to combine data from multiple tables for reporting in a way that goes beyond dot-walking. Instead of forcing users to export data and merge it in spreadsheets, you can create a Database View. A database view is a virtual table that joins two or more tables to create a single, reportable set of records. For instance, you could join the Incident table with the Metric Definition and Metric Instance tables to report on how long incidents spent in a particular state.

Understanding ServiceNow's data architecture is not just academic. It's the key to building efficient, scalable applications and passing the database management portion of the CSA exam.