Dynamic foreign key
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 object key (XObjectKey) of the permitted tables. Permitted tables can be limited. All tables are permitted, if there are no restrictions. Restrictions are stored in the DialogValidDynamicRef table.
If you are defining custom dynamic foreign keys, at least one of the participating partners (dynamic foreign key column or referenced table) must be a custom object. It is not possible to extend predefined dynamic foreign keys by adding references to predefined tables.
To edit dynamic foreign keys
- In the Designer, select the One Identity Manager Schema category.
- Select the table and start the Schema Editor with the Show table definition task.
- Select the column and then the Column properties view.
- On the Miscellaneous tab, enter the following information.
- Set the option Dynamic foreign key.
- If the dynamic key is part of a many-to-all table, enable Part of key of many-to-all table.
- Enter the following information on the Valid reference tables tab by clicking
next to Dynamic referenced tables menu and enter the following information:
Table 30: Properties of dynamic foreign keys
| Table |
Table from which the object key is to be determined |
| Only transport as group |
During data transports, the contents of the column are always transferred together with the contents of the referenced column. |
|
Parent object in Job queue |
Specifies whether the parent object is added to the list of objects affected by a process. This can prevent the parent object from being processed simultaneously more than once. |
| Parent relation constraint |
Constraint on the relation. Permitted values are:
-
Delete: Dependencies are not taken into account on deletion.
-
Delete Cascade: All dependent objects are deleted when this object is deleted.
-
Delete Restrict: The object can only be deleted when no more references to other objects exist.
-
Delete Set NULL: When deleting the object, references to the object being deleted are removed from all dependent object (SetNULL). |
| Child relation test instance |
Specifies who will run this referential integrity tests. Permitted values are:
- DLL: Checks through the object layer.
- Trigger: Triggers and constraints are implemented to monitor the database.
|
| Child relation constraint |
Constraint on the relation. Permitted values are:
|
| Child relation test instance |
Specifies who will run these referential integrity tests. Permitted values are:
- DLL: Checks through the object layer.
- Trigger: Triggers and constraints are implemented to monitor the database.
|
Related topics
Supporting file groups
One Identity Manager supports file groups to group tables together to help with administration, data assigning and data distribution. A distinction is made between logical disk stores and physical disk stores.
In the default installation, logical disk stores are predefined for the table in each module of One Identity Manager and the system tables. You cannot change the assignments. You can create your own logical disk storage for grouping custom tables.
To define logical storage for custom tables
- In the Designer, select the One Identity Manager Schema | Logical disk stores category.
- In the menu, select the Object | New menu item.
- Enter a name and description for the logical storage.
- Assign custom tables to the logical disk store.
-
Select the View | Select table relations menu item and enable the DialogTable table. This shows the Tables tab for assigning tables.
You can link logical storage with physical storage - the file groups - in the One Identity Manager schema.
If, for example, tables with employee data and tables with Active Directory content are created on different a data storage medium, performance can be improved by parallel access through your own E/A controller. Performance can also be improved if, for example, tables for processing DBQueue Processor tasks or table for handling processes in file groups are grouped together.
NOTE: You cannot move the following groups into other file groups. If you do so, proper functioning of the One Identity Manager database cannot be guaranteed.
- DialogColumn
- DialogTable
- DialogValidDynamicRef
- QBMDBQueueTask
- QBMDBQueueTaskDepend
- QBMModuleDef
- QBMModuleDepend
- QBMRelation
- QBMViewAddOn
- QBMDiskStoreLogical
- QBMDiskStorePhysical
One Identity Manager supports the distribution of tables to file groups with a variety of database procedures that you execute in a suitable program for executing SQL queries in the database.
|
|
WARNING: Only carry out the following steps for implementing file groups, together with an experienced database administrator.
Ensure that the database cannot be accessed while file groups are being set up, for example, by the Job server, application server, web server, user interfaces, or the Web Portal. After restarting the DBQueue Processor, wait for all DBQueue tasks to be processed before reconnecting the database. |
IMPORTANT: Select a user that you use for migrating the database to execute the SQL queries.
To distribute tables to file groups under SQL Server
- Create your file groups. For detailed information about this, see the documents for your currently installed version of SQL Server.
- Synchronize the file groups to the One Identity Manager database. Run the query below using a suitable program for executing SQL queries in the database.
exec QBM_PDiskStorePhysicalSync
- In the Designer, assign physical storage to logical storage.
- In the Designer, select the One Identity Manager Schema | Logical disk stores category.
- Select the logical disk store and in the Properties view, select the file group under Physical disk store.
-
Select Database | Save to database and click Save.
- Disable processing of DBQueue Processor tasks and process handling. Run the queries below using a suitable program for executing SQL queries in the database.
exec QBM_PWatchDogPrepare 1
exec QBM_PDBQueuePrepare 1
- Move the tables into the configured file groups. Run the query below using a suitable program for executing SQL queries in the database.
exec QBM_PTableMove
- Reactivate the DBQueue Processor. Run the queries below using a suitable program for executing SQL queries in the database.
exec QBM_PDBQueuePrepare 0,1
exec QBM_PWatchDogPrepare
Editing the user interface
Certain components of the One Identity Manager’s graphical user interface are stored in the One Identity Manager schema and can be tailored to suit customer requirements. Menu items in the navigation structure, interface forms, and task definitions can be configured in this way.
Menu items, interface forms and task definitions are assigned to permissions groups. The user's effective components of the user interface depend on the authentication module used for logging in to the One Identity Manager tools. If a user logs in to a One Identity Manager tool, a system user is found and the available menu items, interface forms, task definitions, and individual program functions are identified depending on the permission groups to which this system user belongs and the adapted user interface is loaded.
Data is displayed as objects in the user interface. User interface objects are meta-objects. You provide a selection of configurable elements that describes how the data stored in the database is perceived. These objects enable data to be distinguished by specific properties. They provide an additional control function for configuring the user interface. Hence, interface forms and tasks are linked to object definitions, which means that different forms and tasks are displayed in the user interface depending on which object is selected.
You can only modify the supplied user interface components to a certain extent and they are overwritten by schema installation. You can integrate components of the default user interface into your own user-defined user interface. If necessary you can disable individual components of the default user interface to stop them from being displayed. The system users provided are not effected by this limitation. Components labeled as disabled remain so after schema installation.
Captions are used in the user interface to create user friendly names for different components of the user interface such as menu items, tasks, and column names. You can maintain multi-language display text in One Identity Manager which enables you to display captions in different languages.
The default One Identity Manager installation is supplied in the English - United States [en-US] and German - Germany [de-DE] language. You can add other languages to the user interface and display text if required. In this instance, you must translate the text before One Identity Manager goes live. There is a Language Editor in the Designer to help you do this. A special control is provided in the One Identity Manager tools that aids multi-language input.
A user interface is always set up for one application. The standard version of One Identity Manager includes the applications and predefined navigation for the Manager, Designer, and Launchpad tools.
Detailed information about this topic
Object definitions for the user interface
The data in the user interface is represented by objects. Objects in the user interface map the data stored in the database. These objects can be configured and enable data to be distinguished by specific properties.
User interface forms and task definitions are linked to object definitions and displayed depending on the selected object definition. Object definitions provide an additional control function for configuring the user interface.
You can assign several objects to each table in the One Identity Manager schema. Basically, each database table should have at least one object definition that is generally valid, that means, without limited selection criterion. Other object definitions then relate to the respective special case limited by the general case.
TIP: To create object definitions for new tables, run the Missing DialogObject consistency check in the Designer and use the repair method. You must edit object definitions created like this afterward.
Table 31: Example relationship between tables and user interface object definitions
|
Employee |
Employee general |
None |
|
Employee |
Employee dummy |
Employees flagged with the Dummy employee property |
Detailed information about this topic
