Related Extract with Disguise for zOS DB2
BMC AMI Test Drive
BMC Compuware Test Data Privacy – Related Extract with Disguise zOS Db2
This tutorial will introduce you to the BMC AMI DevX Data Studio Related Extract to create a relationally intact subset of data while using Disguise Rules to change and protect sensitive data.
Revised: 2024/03/14 00:00
- Getting Started
BMC AMI DevX Data Studio
Create a Related Extract Specification- Application Relationships
Selection Criteria
Execute Extract with AR and Selection Criteria
Getting Started
Instructions:
- This guide contains many screenshots to provide a visual reference
- Please note each place that you must enter your own specific ID or number
- You must complete each step before proceeding to the next to successfully follow the test drive script
If, at any point during your experience, your host connection times out, you may need to log back in to the TestDrive host connection.
If at any time during the execution of this script the Common Enterprise Services Login popup is shown, enter your test drive ID and password under User ID and Password, check the Save credentials box and then depress the ENTER key or click OK.
BMC AMI DevX Data Studio
The Data Explorer View is a part of BMC AMI DevX Data Studio which simplifies the complex task of managing and preparing data for testing. This enables developers and test engineers to perform data-related tasks without writing programs or scripts, coding SQL, or using multiple utilities. They can easily create specifications to extract related sets of data from one environment and load them into another. Extracting just the relevant data needed for testing is done using easy-to-use selection criteria or starting key values. The extracted data will remain relationally intact based on the referential integrity (RI) or application relationships (AR). Data Privacy rules can be applied at the time of extract to protect sensitive data. Data can then be loaded into the environment of choice by supplying the necessary target information in a Related Load job.
In this exercise you will:
- Create a Related Extract specification
- Extract all related data using Referential Integrity
- Create Application Relationships
- Create Selection Criteria to extract only specific data
- Disguise Data during Extract
Create a Related Extract Specification
In this example you will extract data from multiple z/OS DB2 tables. Note that you can use this same process against DB2, DB2 z/OS, Oracle, Sybase, and SQL Server.
You now see all tables related to the ORDER_TABLE through referential integrity and will be included in the extract.
The Relationships view shows the objects as parents and dependents and the type of relationship. In this example all objects are related through RI (referential integrity).
The Visualization view shows the objects graphically. Solid lines indicate the tables are related through RI (referential integrity) which is maintained in the database.
For distributed databases you have an additional tab for Keys. You do not see this in your current view.
Extracts may be driven by a key file to subset the data and get precise information. Key files may also be created from an extract to drive another extract, possibly in a different database. This functionality will be coming soon for z/OS DB2.
Extract Options include limits, discovery options, and more advance database options.
You have now successfully created a Related Extract job and extracted rows from multiple tables related through Referential Integrity and applied disguise rules to replace sensitive data in columns containing Names, Phone Numbers, Social Security Numbers, Credit Card Numbers, Dates, and Email addresses.
Application Relationships
Application Relationships are used to related objects when there is no RI maintained within the database or between certain tables. This allows the Related Extract to extract only related rows from these tables in the same manner as it would with RI. These Application Relationships are maintained within the product and make no changes to the database.
To create the Application Relationship we will relate the Customer Number column in the Customer table to the Cust Num column in the Order table.
Note: Multiple tables can be related through AR. If there were more tables selected, the Create button would allow additional relationships to be created. Also, tables can be related through more than one column.
Here you can see the tables related to each other and you can scroll down to see the columns at the bottom that make up this relationship. Icons on the right allow you to add other objects to this relationship, create a new relationship, or edit or remove this one. Icons at the bottom right allow adding, editing or removing associations between these two objects.
This Application Relationship can now be incorporated into a Related Extract job. This type of relationship will be treated in the same manner as an RI relationship during the extract process. The parent row extracted will pass along the key to the dependent table based on the column used to relate the tables and any rows there that match will also be extracted.
Selection Criteria
Selection Criteria allows specific data to be extracted based on data values. In this example all rows from the Order table where the Order Type is equal to Purchase will be selected. Then during the extract all related rows will be extracted from the other tables.
Execute Extract with AR and Selection Criteria
For this exercise we will open the Related Extract job created earlier. This time we will be adding in additional tables through the use of Applications Relationships. We will also be limiting the number of rows extracted by using Selection Criteria.
Note you now see the Customer table because of the AR created to the Order table. There is also an additional table, Contact table.
Note the Customer table is related to the Order table with a Relationship Type of AR. Once the Customer table is related, it will include in the extract the Contact table since they are related through RI.
You can graphically understand how the objects are related to each other. Note the dashed line marking the Application Relationship.
For that table you can apply selection criteria, determine process type, and see properties. This can be activated and applied to any table, not just the driving table for more complex criteria to get just the data needed.
This will extract all rows from the Order table where Order Type is equal to Purchase. Then it will extract the related rows of data from the other tables related through Referential Integrity, including the Customer table now related through an Application Relationship. Since we had previously selected a Data Privacy Project any sensitive data will also be disguised.
Note that we are now only selecting 17 rows from the Order table instead of the 35 rows from the previous execution with no selection criteria.
Listed here are all the data items that were disguised. It shows for each table which columns had a disguise rule applied and how many rows were changed. Scroll through to understand how the rules were applied according to the Source Data Identifiers in the Project.
You have now successfully extracted related data using Referential Integrity and Application Relationships while applying Selection Criteria to subset that data based on specific data values and Disguised the data so that it is now compliant with existing privacy regulations. This data is now ready to be loaded into a testing or development environment.
This completes the Related Extract with Disguise section.