Identity Manager 8.1.5 - Configuration Guide

Simple tables are the most common form for storing data.

The following columns are defined for simple tables:

• Primary key, consisting of one column
• Object key (XObjectKey)

Many-to-many or M:N tables contain the relationships between two other tables.

The following columns are defined for many-to-many tables:

• Two-column primary key

  Both columns are defined as foreign key columns on the referenced table.

• Object key (XObjectKey)

Many-to-many tables are also called assignment tables in this documentation.

Many-to-all or M:all tables are a special type of assignment tables that were developed for One Identity Manager.

M:all tables are implemented if part of an assignment (all) can reference different tables, meaning dynamically determined. Valid tables can be limited in this way. For example, the owner of a group can be a user account or a group.

Furthermore M:all tables are used if additional information about an assignment is mapped, for example, an assignment's validity period.

The following columns are defined for M:all tables:

• Primary key
• Foreign key defined as NOT NULL that references the primary key of another table.
• Dynamic foreign key defined as NOT NULL that reference the object key (XObjectKey) of the valid tables.
• Object key (XObjectKey)

You can define more foreign keys and dynamic foreign keys. These columns must be defined as NULL.

• If objects are generated from the table through the object layer, the table requires a primary key.

• If a table represents a many-to-many mapping, a two column primary key is defined. Both primary key columns are defined as foreign key columns in the referenced tables.

• No primary key is required for work tables.

• Primary key columns must be defined in Globally Unique Identifier (GUID) format.

  Default GUID's are created in the [0-9,a-f](8-4-4-4-12) format.

  Predefined module GUID's are mapped in the <MMM>-[0-9,a-f](32) format, where <MMM> corresponds to the module prefix. Custom module GUID's are created in the <CCC>-[0-9,a-f](32) format. For more information, see Working with a globally unique identifier module.

If objects are generated from the table through the object layer, the table must have an object key column. The object key (XObjectKey) is a unique key, which is capable of referencing every object in the database.

XObjectKey syntax:

<Key><T>TableName</T><P>PrimaryKeyOfRow</P></Key>

with:

• TableName: table name

• PrimaryKeyOfRow: primary key column's GUID

An additional <P>SecondPrimaryKeyOfRow</P> is used for two column primary keys. The order in which columns used in the XObjectKey are sorted depends on the foreign key columns identifiers (alphabetical order).

Example:

PersonInProfitcenter table

<Key><T>PersonInProfitCenter</T><P><UID_Person></P><P><>UID_Profitcenter</P></Key>

PersonInDepartment table

<Key><T>PersonInDepartment</T><P><UID_Department></P><P><>UID_Person</P></Key>

• The name of the foreign key column corresponds, as far as possible, to the name of the references table's primary key.

• Foreign key columns are defined in GUID format.

• A table is reference through the referenced table's primary key.

• If the foreign key column is part of a many-to-all table, the column in the One Identity Manager schema is labeled with the Part of key of many-to-all table option (DialogColumn.IsMAllKeyMember).

• Dynamic foreign keys are used if a reference can point to different tables. For example, the manager of a user account (<MMM>Account.ObjectKeyManagertable) can be another user account (<MMM>Account table) or a group (<MMM>Group table).

• Dynamic foreign keys reference the (XObjectKey) object key of the permitted tables.

• Permitted tables can be limited. All tables are permitted, if there are no restrictions.

• A dynamic foreign key is flagged in the One Identity Manager schema with the Dynamic foreign key option (DialogColumn.IsDynamicFK).

• If the dynamic foreign key is part if a many-to-all table, the column in the One Identity Manager schema is labeled with the Part of key of many-to-all table option (DialogColumn.IsMAllKeyMember).

The columns contain information about which users made changes at what times. The columns must always exist together.

This column contains an element's processing status. The processing status is used for creating custom configuration packages.

This column defines whether the object is marked for deletion. The columns exists when:

• The deferred deletion function can be applied to the table.

• The table is synchronized again a target system and pending objects can be handled.

In order to determine the origin of an assignment, a XOrigin column is defined in a many-to-many or a many-to-all table. The individual bit positions provide the origin of a membership.

For detailed information about calculation of assignments, see the One Identity Manager Identity Management Base Module Administration Guide.

• To discover whether an assignment is in effect, a XIsInEffect column is defined on an assignment table.

• The column only exists if the number of assignments differs from the number of effective assignments.

  For example, if an employee is deactivated, marked for deletion, or classified as a security risk, inheritance of company resources can be prohibited for this employee. The group assignment is maintained but the assignment has no effect.

• If the XIsInEffect column is used, a XOrigin column must exist.

For detailed information about calculation of assignments, see the One Identity Manager Identity Management Base Module Administration Guide.