Check Knowledge Module Overview

1. Check Knowledge Module Overview

• The Knowledge Module (KM) overview should be checked to understand the different components and tables it works with.

2. Types of Tables Maintained by Standard CKMs

Standard CKMs manage two different types of tables:

• Summary Table (SNP_CHECK_TAB)
• Purpose: This table holds a summary of errors for each table and constraint.
• Location: Created in the work schema of the default physical schema for the data server.
• Usage: It helps analyze the overall data quality of a model.
• Error Table (E$_)
• Purpose: This table contains the actual records that were rejected by the data quality processes.
• Records: These rejected records are identified by both static and flow controls.
• Location: One error table is created for each datastore that was checked.

3. How These Tables are Used

• SNP_CHECK_TAB can be used to assess the overall health and quality of the data by reviewing the summary of errors.
• E$_ helps in pinpointing specific records that failed validation or data quality checks.

4. Key Considerations

• Ensure both tables are properly maintained and accessible for the purpose of monitoring and improving data quality.
• Both tables play a critical role in understanding where errors occur and tracking rejected data records.

This approach can help in checking the data quality and identifying areas that need attention.

Here’s a step-by-step breakdown of the standard CKM process:

1. Drop and Create the Summary Table

• Action: Execute the DROP statement only if the designer requires resetting the summary table.
• Action: Always execute the CREATE statement. If the table already exists, the error is tolerated.

2. Remove Previous Run Summary Records

• Action: Remove the summary records from the previous run from the summary table.

3. Drop and Create the Error Table

• Action: Execute the DROP statement only if the designer requires recreating the error table.
• Action: Always execute the CREATE statement. If the table already exists, the error is tolerated.

4. Remove Previous Run Rejected Records

• Action: Remove the rejected records from the previous run from the error table.

5. Reject Records Violating Primary Key Constraint

• Action: Reject any records that violate the primary key constraint.

6. Reject Records Violating Alternate Key Constraint

• Action: Reject any records that violate any alternate key constraint.

7. Reject Records Violating Foreign Key Constraint

• Action: Reject any records that violate any foreign key constraint.

8. Reject Records Violating Check Condition Constraint

• Action: Reject any records that violate any check condition constraint.

9. Reject Records Violating Mandatory Attribute Constraint

• Action: Reject any records that violate any mandatory attribute constraint.

10. Remove Rejected Records from the Checked Table (if required)

• Action: Remove the rejected records from the checked table if required by the process.

11. Insert Summary of Detected Errors in the Summary Table

• Action: Insert the summary of all detected errors into the summary table.

 

1. "Primary Key" Tag

• Purpose: The command defines the code needed to check the primary key constraint.
• Usage: During code generation, Oracle Data Integrator (ODI) uses this command for every primary key constraint to ensure the uniqueness of the records.

2. "Alternate Key" Tag

• Purpose: The command defines the code needed to check an alternate key constraint.
• Usage: ODI will use this command for every alternate key constraint during code generation to ensure that records adhere to alternate key rules.

3. "Join" Tag

• Purpose: The command defines the code needed to check a foreign key constraint.
• Usage: This tag ensures that the code checks relationships between tables. During code generation, ODI will use this command for every foreign key constraint to enforce referential integrity.

4. "Condition" Tag

• Purpose: The command defines the code needed to check a condition constraint.
• Usage: The condition constraint could involve specific rules (e.g., value ranges or formats). During code generation, ODI will use this command to apply the condition constraint to every check condition.

5. "Mandatory" Tag

• Purpose: The command defines the code needed to check a mandatory attribute constraint.
• Usage: This ensures that certain attributes (fields) are not null. ODI will use this command during code generation to enforce mandatory attribute constraints for each attribute that requires a value.

6. "Remove Errors" Tag

• Purpose: The command defines the code needed to remove rejected records from the checked table.
• Usage: During the CKM process, this tag is used to define the code that removes any records that were rejected due to violations of the constraints. This is essential for cleaning up the data after validation.