The following figure illustrates the names and structures
for the tables in which identity information is stored during batch
processing:
Here are some key points
about the tables:
-
You don't have to use all of the
tables. For example, if you are not going to store e-mail addresses,
you don't need an email table.
-
For each table that you do use,
all columns must be present. However, you don't have to include data
in every column. In the figure, the required columns for the primary
objects are indicated with a star.
Note: Each user should have a login
that includes a qualified user ID.
-
The keyids in the person table
(users), idgrps table (groups and roles), and authdomain table (authentication
domains) tie each of those primary objects to its related information.
In the metadata, the keyid value is stored as an external identity.
For each keyid column, use a fixed, enterprise-wide identifier such
as these:
-
In the person table, consider using
employee identification numbers.
-
In the idgrps table, consider using
group names (or LDAP Distinguished Names).
-
In the authdomain table, consider
using authentication domain names.
-
All of the relationships between
a primary object and its related data are zero-or-more relationships.
For example, you can store no phone numbers, one phone number, or
multiple phone numbers for each user.
-
We recommend that you avoid using
spaces or special characters in the name of a user, group, or role.
Not all components support spaces and special characters in identity
names.
The following figure
depicts data for a user named Tara O'Toole. The ovals indicate personal
data for Tara. The check marks indicate data that is indirectly related
to Tara (through her group memberships).
In the figure, notice
these things:
-
In the person table, the employee
number is used as the keyid. The name column uses user IDs (that column
also requires unique values). The displayName column contains a common
name for each user.
-
In the grpmems table (group memberships),
Tara is a direct member of the ETL group. Tara is an indirect member
of the Developers group, because that group has the ETL group as one
of its members. Tara also has a third-level membership in the ReportConsumers
group.
-
In the idgrps table, the group
name serves as the keyid. This choice is appropriate because the metadata
server enforces uniqueness across all group and role names.
-
In the idgrps table, the grpType
column is empty. This indicates that the entries in this table are
all groups. To create a role in the metadata, provide a grpType value
of
ROLE.
-
In the email table, Tara has two
e-mail addresses and each one has a different type.
-
In the logins table, Tara has personal
logins in two different authentication domains. Tara can also use
the ETL group's login (for DB2Auth), because Tara is a member of the
ETL group.
-
In the authdomain table, the authentication
domain name serves as the keyid. This is appropriate because the metadata
server enforces uniqueness across all authentication domain names.
