› CIS-DF Hub › Part 7 › Database Views in Reporting
⬡ Part 7 · Topic 2

Database Views in Reporting

Database Views let you join data from multiple tables into a single read-only virtual table — perfect for reports that need fields from two related tables without complex scripting. Understanding their limits and when to use them is a key exam skill.

📋 4 sections ⏱ ~15 min read 🎯 ~6% exam weight 🏷 Reporting · Database Views
Section 1

What Is a Database View?

A standard ServiceNow report is built on a single table. If you need fields from a related table (accessed via a Reference field), you can only dot-walk one level — for example, incident.caller_id.department. But dot-walking has limits, and some report types don't support it.

A Database View (stored in sys_db_view) solves this by creating a virtual table that joins two or more tables. The join is defined once, and then users can report on the view as if it were a flat table with all the columns from both.

🧩
Analogy — SQL JOIN Made Permanent A Database View is like a pre-built SQL JOIN view. Instead of asking every report writer to manually join the incident table to the user table, you create the view once and everyone reports on "incident + user info" without needing to know about the join. The view doesn't store data — it reads from the underlying tables each time.

Create a Database View

Navigate to: System Definition → Database Views → New

  1. Set the Name (becomes the view's table name)
  2. Add the Left Table (the primary table — all its records appear)
  3. Add Right Tables (joined tables) with join conditions
  4. Select which columns from each table appear in the view
Section 2

Join Types

Database Views support two join types. Understanding the difference is critical for predicting which records appear in reports:

Join TypeRecords IncludedUse When
Inner Join Only records where both tables have a match. A left-table record with no matching right-table record is excluded. You only care about records that have related data in both tables (e.g., incidents with a user record)
Left (Outer) Join All records from the left table, plus matching records from the right table. Left records with no match show NULL for right-table fields. You want all records from the primary table, even those without a match (e.g., all incidents, including ones with no assigned user)
⚠
Exam Trap — Inner Join Excludes Unmatched Records If you create a Database View joining incident to sys_user on caller_id, and some incidents have no caller_id set, those incidents are excluded from the Inner Join view. If your report shows fewer incidents than expected, check whether you need a Left Join instead.
Section 3

Database View Limitations

Database Views are powerful but have important restrictions that the exam tests:

  • Read-only — you cannot insert, update, or delete records through a Database View. They are reporting-only constructs.
  • No ACL enforcement on view structure — the join columns are defined statically; you can't have dynamic join conditions per user.
  • Performance impact — complex views with many joined tables can slow reports. Each execution re-runs the join query.
  • No Script support on view fields — calculated fields or scripted transformations cannot be added at the view level.
  • Cannot be used as Import Set targets — since they're read-only virtual tables.
💡
Tip — When to Use Database View vs. Dot-Walking Use a Database View when: (1) you need to report on more than one level of relationships, (2) the report type doesn't support dot-walking (e.g., some Pivot reports), or (3) multiple report writers all need the same cross-table data. Use simple dot-walking (e.g., caller_id.department) when it's a one-level relationship and the report type supports it — no view setup needed.
Section 4

Database Views for CMDB Reporting

Database Views are especially useful in CMDB reporting where you need to combine CI data with related table data:

  • CI + Incidents — join cmdb_ci to incident on the affected_ci field to report on which CIs generate the most incidents
  • CI + Change Requests — similar join to show which CIs have the most change activity
  • CI + cmdb_rel_ci — join CI to its relationships to report on relationship types per CI class

Note: when joining to cmdb_ci, always add a class filter in the view or the report — otherwise you join against all CI types and the result set is enormous.

Exam Quick Reference

Common Exam Traps — Database Views in Reporting

  • Database Views are stored in sys_db_view — virtual read-only joins of multiple tables
  • Inner Join = only matching records from both tables; Left Join = all left-table records
  • Inner Join excludes left-table records with no match in the right table
  • Database Views are read-only — cannot be used for inserts, updates, or import targets
  • Use Database Views when dot-walking doesn't cover the join you need, or multiple writers need the same cross-table view
Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Database Views in Reporting Quiz 1 / 4

A report needs to show Incident records alongside the CI class name and support_group of the affected CI, but the CI data is in a separate CMDB table. What is the simplest approach?

💡 Explanation

B is correct. When a report needs fields from a referenced table that's only one level away (incident.cmdb_ci → cmdb_ci.sys_class_name), dot-walking is simpler and more maintainable than creating a Database View. In the Report Builder, you can select "cmdb_ci.sys_class_name" and "cmdb_ci.support_group" directly as fields, and ServiceNow automatically traverses the reference field. Database Views (A) are needed when dot-walking isn't sufficient — for example, many-to-many joins, left joins showing all records even without a match, or complex multi-table joins that dot-walking can't express.

A Database View is created joining the Incident table (left) with the CMDB CI table using an Inner Join on the cmdb_ci field. Which Incident records appear in reports built on this view?

💡 Explanation

B is correct. An Inner Join only returns rows where there is a matching record in BOTH tables. For the Incident-CI Inner Join: only Incidents that have a cmdb_ci value that matches an existing CI record appear. Incidents where cmdb_ci is null, or where the referenced CI has been deleted, are excluded entirely. If you need all Incidents regardless of CI association (with null CI fields for those without), you need a Left Outer Join — this includes all left-table (Incident) records, with null values for right-table (CI) fields when no match exists. Option D correctly describes Left Join behavior, not Inner Join.

An administrator wants to use a Database View as the target for an Import Set to bulk-update CMDB CI records. What will happen?

💡 Explanation

B is correct. Database Views in ServiceNow are strictly read-only virtual constructs — they represent a joined view of data from multiple tables for querying and reporting purposes only. They cannot accept inserts, updates, or deletes. An Import Set requires a writable target table; using a Database View as the target will fail. To bulk-update CMDB records via Import Set, use the actual underlying table (e.g., cmdb_ci_server) as the target, with IRE handling identification and reconciliation.

When should a Database View be used instead of dot-walking in a report?

💡 Explanation

B is correct. Database Views have specific use cases where dot-walking falls short: (1) Left outer joins — needed when you want all records from the left table even without a match in the right table; dot-walking only does inner joins. (2) Many-to-many joins — when multiple right-table records match a single left-table record (e.g., one Incident linked to multiple CIs). (3) Reusable joins — when many reports need the same cross-table join, creating one Database View is more maintainable than configuring dot-walk paths in every report independently. For simple one-level reference field access, dot-walking is simpler and should be preferred.

Score: 0 / 4
Dashboards & Scheduling →