Visión de Gobierno Electrónico Ecuatoriano

Creating a New Instance of an Existing Table Definition

If you use an existing Table as a definition source, its Columns and other properties are already defined. See "Creating an Instance of an Existing Definition" on page 3-3.

Setting and Modifying Table Attributes

When you create a new Table definition and/or Table instance, the system populates its attribute values. To change these values, as well as the name and other attributes described in "Creating a New Table Definition and Instance" on page 4-4, click Update. Process Type The processing type determines how Oracle LSH writes data to the Table instance. See "Data Processing Types" on page 13-2 for information.

For Table instances that are the target of an Oracle-technology Load Set, you can instead select Create Table as a View from the Process Type drop-down list. No processing type is required because the system does not write data to the Table instance. Instead, you use the Table instance as a pass-through view to see data in the source system. The option appears after you map the Table instance to an

Oracle-technology Load Set.

Allow Snapshot Snapshots are possible only on audited Tables (Reload,

Transactional with Audit, or Staging with Audit). See "Data Snapshots" on page 13-8. ■ If set to No, creating and labeling snapshots of this Table instance is not allowed. ■ If set to Yes, users can create and label snapshots of this Table instance.

Blinding Flag This setting has effect only for Table instances. The setting in the Table definition serves only as a default setting for instances of that Table definition. See "Managing Blinded Data" on page 13-13 for further information.

■ If set to No, the Table instance is intended to never contain blinded data. ■ If set to Yes, the Table instance may contain blinded data. The system maintains

two sets of rows: one set for the real data and another set for dummy data, effectively partitioning the table in the database.

Note: The system prevents you from selecting a processing type that requires a primary or unique key (Reload or Transactional with Audit) until you have done the following:

■ Defined Columns for the Table

■ Defined a primary or unique key for the Table

■ In the Audit Key Constraint field, which appears when you select a processing type that requires a primary or unique key, selected the primary or unique key you want the system to use for auditing. See "Data Auditing" on page 13-7.

Note: If you change the setting of the Blinding flag for a Table instance that is already installed, you cannot use an Upgrade-mode Work Area installation to reinstall the new version of the Table instance. You must do a Full-mode Work Area install to apply a new blinding status to an installed Table instance, which deletes the Table instance's data; see "About Work Area Installation" on page 12-11.

Setting and Modifying Table Attributes

Blinding Status If the Blinding Flag is set to Yes, you can set the Blinding Status attribute to one of two values:

■ Blinded. The real, sensitive data cannot be viewed or operated on except by a user with Blind Break privileges. Any user with normal security access to the Table instance can view and operate on the dummy data.

■ Unblinded. A person with special privileges can change the Blinding Status from Blinded to Unblinded; for example, at the end of a trial. After the status is set to Unblinded, users require special, but less restrictive, privileges to view and operate on the unblinded data. See the chapter on security in the Oracle Life Sciences Data Hub Implementation Guide for more information on blinding-related privileges. See also "Managing Blinded Data" on page 13-13.

If the Blinding Flag is set to No, you can set the Blinding Status attribute to one of two values:

■ Not Applicable. This is the default value. It is intended for use with Table instances that never will contain sensitive information that would require blinding.

■ Authorized. Use this status in the rare case that the Table instance is the target of a Program that reads from a blinded Table instance, and the Program is written in such a way that this target Table instance will never contain sensitive data that should be blinded. When the Blinding Status is set to Authorized, the system allows users who have Blind Break privileges on all blinded source Table instances to run the Program that writes to this Table instance. These users see a warning and must confirm that they want to run the Program.

You may need to use this feature, for example, when creating dummy data; see "Loading Real and Dummy Data" on page 13-14.

Definition Source This field applies to the instance only. It specifies the Table definition to which this Table instance points. See "Definition Source" on page 4-15. Tablespace Name If your company has created its own tablespaces, select the appropriate tablespace for the actual database table created when you install this Table instance. If you do not enter a value, the system creates the table in the default

tablespace for the database.

1. Click the Search icon. The Search and Select window opens.

2. Enter the name of the tablespace you are looking for and click Go. You can use the % wildcard, but not as the first character. The system displays the tablespaces that meet the search criteria.

3. Click the Quick Select icon. The system returns you to the Table instance screen with the selected tablespace displayed.

Note: While you are developing a Program that reads from a blinded Table instance and writes to a nonblinded Table instance, set the target Table instance's Blinding flag to Yes until you are sure that neither the Program nor its log file exposes any sensitive information.