the system dictionary contains the definition for each and every table and field in

the database

admins can use these tools for viewing and modifying the database structure:
tables module: provides a list of all tables in the database
tables and columns module: provides a list of all existing tables, with columns,
column attributes, and indexes
schema map: provides graphical representation of the relationships between tables
data dictionary tables: contains additional information that defines database
elements

a table is a collection of records in the database

records are identified by a 32-character globally unique id, called sys_id

records numbers can be automatically incremented and the number format per table in
the system can be changed by visiting the all > system definition > number
maintenance application

each field has three key attributes: label, name, value

field name is a unique term that does not always match a field label

reference fields are identified with the reference lookup icon, that opens a dialog
box for locating a record to reference presented as a list of the referenced table

a reference field stores a sys_id of a record on another table which is what

establishes the reference relationship

when you define a reference field the system creates a relationship between the two
tables, making the other fields in the referenced table available to the form

a reference field can refer only to records from one other table, to add a field
that can refer to records on any table use the document id element type

tables can be related in various ways, such as:

one to many: within a table, a field can hold a reference to a record on another
table, there are three one to many relationship fields
> reference fields: allows a user to select a record on a table defined by
the reference field
> glide list: allow a user to select multiple records on a table defined by
the glide list, like a watchlist field
> document id: allows a user to select a record on any table in the instance

many to many: two or more tables can be related in a bi direcional relationship, so

that the related records are visible from both tables in a related list

database views: a database view defines table joins for reporting purposes, for
example a database view can join the incident table to the metric definition and
metric instance tables, this view can be used to report on incident metrics and may
include fields from any of these three tables, the data in the virtual table
created by a database view is read only

extensions: the extended table includes unique fields plus all of the fields and
their properties from the parent table

a table that extends another table is called a child class and the table it extends
is the parent class
task and configuration item are examples of parent classes

extending a table incorporates all the fields of the original table and allow for
unique fields to be created on the new table

table and fields properties can also be inherited, examples include whether a field
is mandatory, business rules, acl, ui policies, client scripts etc

a parent class that is not an extension of another table is called a base table

a table can be both parent and child class

a core table is a table that exists in the sn base system, tables that come with
the system are the core tables, but a core table can also be a parent table (task)
a child table (incident) or a base table (task)

base tables is a table that serves as a base from which other tables may extend

what makes a base table differente from a core table is that the base table is not
an extension of another table (it has no parent)

tables created by admins are called custom tables

when creating a custom table, the table name is automatically populated based on
the table laabel and a prefix, if the table is being created in a scoped
application, the name is prefixed with a namespace identifier "x_" indicating that
it is a part of an application, in the global application feature "u_" as their
prefix

scoped apps are sandboxed from the system at large and utilize a restricted API to
minimixe damage to anything outside their scope

custom tables may be subject to additional licensing fees, cmdb tables can be
extended at infinitum at no charge

CRUD (create, read, update, delete)

application and modules access are controlled by roles configured at the

application and module level

database access, access to tables and their records and fields are controlled via
globally defined system properties (deny access is the default behavior)

elevated roles grant modification access allowing users to modify the ACL

there are other elevated roles like workplace_admin and security_admin

in addition to restricting crud operations, acl rules can restrict servicenow

specific operations on tables and fields like:
execute: users cannot execute scripts on a record or ui page
edit_ci_relations: user cannot define relationship between cmdb_ci tables
report_on: user cannot create reports on the object
personalize_choices: user cannot right-click a choice list field and select
configure choices

to view acls associated with a table, use the filter navigator, type <table>.config
and click the access control tab
when a custom table is created, the system creates four access control rules by
default (crud), a role is also created by default and associated with the access
control rules

each access control rule specifies a valid operation (crud), the object being
secured and the permissions required to access the object

access control rules are defined for an applied to a specific table so that the
rule is within the context of the table and the type of data sored

table.-none- applies to the entire table

table.field is one specific field on the table
table.* represents all other fields in the table not defined with a table.field
rule, this method reduces the number of acls that need to be written for a table

best practices when creating a acl is:

when creating .* acls, also create a none acl because only none grants access to
records
when writing an acl that mostly grants access, use only none
when writing an acl that mostly denies access, use none and .*

when a session requests data, the system looks for matching access control rules
1. match the object against table acl - most specific to most general
2. match the object against field acl - most specific to most general

a user must pass both table and field acl rules to access a record object

import sets provide a mechanism to pull data into sn, any user logged in with the
admin or import_admin role can manage all aspects of import sets

data sources are records in sn that contain information regarding an import set,
you can import data from a local source (xml, csv, excel) or from a network server
by providing a path and authentication information

importing good practices:

understand what data you are bringing in and where it should be placed
plan time before an import to verify your data, remove obsolete data and fix
inaccurate data

the import set table is a staging area for records imported from a data source

data should not be imported in extremely large chunks

if a match is found using the coalesce field, the existing record will be updated
with the information being imported

if a match is not found using the coalesce field, then a new record will be
inserted into the database

if no coalesce is defined, all imported rows are treated as new records, no

existing records are updated, if the import is executed again, duplicate records
will be created

there are several possible configurations you can use to coalesce data in import
sets:
single field coalesce: you can coalesce on a single field to update an existing
records
multiple field coalesce
conditional coalesce: you can use a script to determine if an import table row
should coalesce to a target record

if you had the "copy empty fields" check box selected in the transform map, it
would have overwritten the data from the record with a blank value from the xlsx
file