User Import Macros

Canonical Tables

The following figure illustrates the names and structures for the tables in which identity information is stored during batch processing:

Table Structures and Relationships

[Table Structures and Relationships]

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. See User ID Formats.
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. See External Identities. 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. Constraints are documented in What Information Is Imported?.
We recommend that you avoid using spaces or special characters in the name of a user, group, or role that you create. 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).

Example: Partial Tables Showing Selected User Data

[Example: Partial Tables Showing Selected User Data]

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.

Top of Page