Putting it together: real engagements, a worked project and the glossary

Plain-English definitions of the terms used in the guide, each with a pointer to the section that explains it. Terms are alphabetical within each group: general ideas first, then privacy, ETL, and one group per tool. Tool-specific terms carry the tool name in brackets, for example "(Delphix)".

10.25 General TDM and data terms

Acceptance criterion

A measurable statement that decides whether a piece of work is done, such as "0 orphan orders". Section 10.17

Assessment

A structured review of an application and its data environment, ending in a written report of findings and recommendations. Section 10.8

Audit trail

A record of who ran what, when and with which settings, kept so compliance questions can be answered later. Section 3.35

Boundary value

A value at, just below or just above a limit the application enforces, such as ages 17, 18 and 19 for an 18-plus rule. Section 3.3

Collision

Two different inputs masked to the same output. Fine for names, harmful in a column that must be unique. Section 2.34

Column / field / attribute

One fact held for every row of a table, such as first name or order date. Section 1.22

Composite key

A primary key made from more than one column. Section 1.23

COTS

Commercial off-the-shelf software: bought ready-made from a vendor rather than built in house. Section 1.5

Coverage matrix

A grid of test conditions against the data that covers each one, so gaps show at a glance. Section 3.1

Data

Raw facts such as "1001" or "Asha", before anyone says what they mean. Section 1.21

Data pattern

One of five shapes for values: boundary conditions, sequential, random, edge cases and null. They serve test purposes rather than form a separate classification. Section 3.4

Data profiling

Scanning a data source with software and reporting facts about it, such as nulls, uniqueness and patterns. Section 2.16

Data subset

A smaller copy of a database that still hangs together: fewer rows, same structure, referential integrity intact. Section 2.20

Data type

The kind of value a column holds (number, text, date), which controls what is allowed. Section 1.22

Database

An organised store of data that a program can search and change reliably. Section 1.22

Database administrator (DBA)

The person who grants the TDM tool access to source and target databases and helps with performance and storage. Section 1.13

Deterministic masking

Masking that turns the same input into the same output every time, so a customer is masked identically in every table and run. Section 2.33

Dictionary / lookup file (masking)

A list of replacement values, such as thousands of first names, that substitution picks from. Section 2.32

Discovery (data discovery)

Finding out what a data source holds: which tables and columns exist, which are sensitive and how tables relate. Section 2.16

Driving table

The table you start from when choosing a subset; related rows are pulled in from it. Section 2.22

Dynamic masking

Masking at the moment of reading, depending on who asks. It protects production views, not test copies, and the guide's sources do not cover it. Section 2.35

Edge case

A rare but possible input outside normal use, such as a surname with an apostrophe or a date on 29 February. Section 3.3

Encryption

Scrambling data with a key so key holders can unscramble it. Reversible, so it is not masking. Section 2.30

Engagement

One piece of TDM work for one client or business unit, from first conversation to hand-over. Section 10.1

Environment

A complete running copy of the application with its own servers and database: dev, QA, UAT, staging or production. Section 1.7

Evidence pack

The queries, screenshots and reports that prove each success criterion is met. Section 10.1

False positive / false negative

Discovery mistakes: flagging a column that is not sensitive, or missing one that is. The second is more dangerous. Section 2.19

Flat file

A plain file holding records as lines of text, with no database engine, keys or data types behind it. Section 1.24

Foreign key (FK)

A column whose values must match the primary key of another table; it is the link between tables. Section 1.23

Format-preserving

A masked value that keeps the original's shape: a 10-digit phone stays 10 digits, a card number keeps its checksum. Section 2.32

Hand-crafted data

Test rows typed or edited by a person: slow, hard to repeat and tiny in volume. Section 3.3

Hash (MD5)

A one-way scramble: the same input always gives the same output, but the output cannot be turned back into the input. MD5 is one hash function, with a 128-bit result. Section 6.18.11

Hybrid test data

Masked or queried production data with generated rows added on top. Section 3.3

Information

Data with meaning: "customer 1001 is Asha, living in postal area 560001". Section 1.21

In-place masking

Masking that changes the values inside the database you point the job at. Never aim it at production. Section 2.35

Irreversible

You cannot recover the original value from the masked one. Section 2.34

KPI

Key performance indicator: a number tracked to show whether TDM is helping. Section 10.14

LOB

Line of business: one business area with its own applications and data. Section 10.1

Logical key (general)

A column the tool is told to treat as a key, with no change to the real database. Section 1.23

Luhn check

The checksum formula that real payment card numbers follow, used by payment forms to catch mistyped numbers. A Luhn-valid number is not necessarily a real card. Section 6.18.11

Masking

Replacing real sensitive values with realistic but fictitious ones so test data cannot identify real people. Section 2.30

Metadata

Data about data: table and column names, types, lengths and key definitions, not the values. Section 1.22

Metadata profiling / data profiling

Metadata profiling reads names and types; data profiling reads the values. They find different things. Section 2.17

Negative test / negative data

A test, or data, the application should reject or handle safely, such as an order total of -5.00. Section 3.3

Non-deterministic (random)

Giving a different output each time for the same input. Section 2.29

Non-production environment

Any copy of the application that is not live: development, QA, UAT or staging. Section 1.5

Null

"No value at all" in a column, different from an empty string, which is a value of zero characters. Section 7.7

Obfuscation

Umbrella word for making data hard to read by any method; masking is one kind. Section 2.30

On-the-fly masking

Reading unmasked data from a source and writing only masked data to a different target. Section 2.35

Orphan

A child row whose foreign key points at no existing parent; it means the data is broken. Section 1.23

Parent table and child table

The table pointed at is the parent; the table holding the foreign key is the child. Section 1.23

Pilot (services-partner sense)

In one services partner's approach, a real medium-sized project chosen to cover the key scenarios and show the client measurable improvement before a roadmap and rollout. It is larger than a lab POC. Section 10.7

POC (proof of concept)

A small, time-boxed trial of an approach on a slice of real systems, run before full rollout. Section 10.7

Positive test / positive data

A test, or data, the application should accept and process normally. Section 3.3

Primary key (PK)

A column, or columns, whose value is unique in every row and never empty. Section 1.23

Production (prod)

The live system real customers use; it holds real data. Section 1.7

Production support period

A set period after go-live in which the client can bring problems and questions back to the project team; the last phase of the partner's approach. Section 10.7

Provisioning

Delivering a prepared data set to a test environment so testers can use it. Section 3.35

RACI

A table marking who is Responsible, Accountable, Consulted or Informed for each task. Section 10.13

Random data

Values picked unpredictably from a set or range, giving realistic variety. Section 7.4

Record

One row of a table, or one line of a flat file: one customer, one order. Section 1.24

Referential integrity

The rule that every foreign key value matches an existing primary key value. Section 1.23

Refresh

Replacing the data in a test environment with a newer copy. Section 1.5

Regression testing

Re-checking that old features still work after a change; it wants the same data every run. Section 1.7

Repeatable

Giving the same results when re-run. Informatica uses the word for deterministic masking switched on by a seed. Section 2.31

Risk register

A living table of things that could go wrong, with likelihood, impact, owner and mitigation. Section 10.9

Sampling

Reading or picking only some rows; efficient, but a rare value may be missed. Section 2.17

Schema

The description of the data (tables, columns, types, keys) as opposed to the data itself. Section 1.22

Seed

A starting number for a random picker. The same seed gives the same "random" values every run. Section 3.7

Sequential data

Values that follow a fixed order such as 1, 2, 3, 4; the usual choice for ids. Section 7.3

Shuffle

Moving a column's existing values between rows. The values stay real, so check it is safe enough. Section 2.32

Sign-off

Formal written approval by named people that agreed criteria have been met. Section 10.11

SQL

Structured Query Language, used to ask a relational database questions and change its data. Section 1.25

Stateful data

Rows in a particular condition that a workflow needs, such as an order already shipped whose payment has settled. Section 3.3.3

Static masking

Creating a masked copy once; anyone using the copy sees masked data. The normal TDM approach. Section 2.35

Subsetting

Taking a small, consistent slice of a big database instead of all of it. Section 2.20

Substitution

Replacing a value with a believable, unrelated one picked from a list. Section 2.32

Success criteria

Measurable pass-or-fail statements agreed before a POC starts. Section 10.7

Synthetic data

Data created by a program from rules, not copied from real people. Section 3.5

TDG (test data generation)

Creating synthetic test data with a tool rather than copying production. Section 10.1

TDM engineer

The person who discovers sensitive data, designs subsets, configures masking and generation and fixes failures. Section 1.13

TDM pipeline

The chain from production (or a generator) to usable test data: find sensitive data, cut down, mask, load, check. Section 3.39

TDM (Test Data Management)

The planning, tools and habits that give testers safe, realistic, right-sized data when they need it. Section 1.9

Technique (Informatica) / algorithm (Delphix)

The method that changes a value, such as substitution or date shift. Section 2.29

Technology landscape

The list of systems, databases, files and interfaces that hold or move the data in scope. Section 10.4

Test case

One specific check: "do this, with this data, expect that result". Section 1.5

Test condition

A specific situation a test wants to check, such as a customer with no phone number. Each needs data that creates it. Section 3.1

Test data

The data a test case needs: rows that exist before it starts and values typed during it. Section 1.5

Test data as a service

Test data that teams request and receive like a service-desk ticket, owned by a small group with the rules. Section 3.11

Tokenization (general)

Replacing a value with a token while keeping a protected way to reverse it. Section 2.30

UAT (user acceptance testing)

Testing where the business confirms the application does what it asked; it needs believable data. Section 1.7

Unique permutations

Every combination of values worth testing; one of the kinds of data GenRocket's CEO says masked production copies lack. Section 3.3.3

Unique / uniqueness

A column where no value repeats; masking must not create duplicates there. Section 2.34

Validation of masked data

Checking a finished job: re-run discovery, test joins, formats, uniqueness, repeatability and job warnings. Section 2.38

World Quality Report (vendor-cited)

An industry quality report that GenRocket's CEO cites for two figures: 69% of organisations use spreadsheets to generate test data and 59% still create it manually. Section 6.2.1

10.26 Privacy and regulation

Anonymisation

A goal: data that identifies no one, even in combination. Legal tests are strict, so masking alone does not guarantee it. Section 2.30

Business associate

Under HIPAA, a vendor that handles PHI for a covered entity, such as a firm testing a hospital's billing system. Section 2.5

CCPA

California Consumer Privacy Act: gives California residents rights over personal information businesses hold. Section 2.5

Compliance officer

The person responsible for making sure the organisation follows laws and internal data rules. Section 2.9

Consent / lawful purpose

Ideas shared by privacy laws: data needs a lawful reason, and testing is a different purpose from running the shop. Section 2.5

Covered entity

Under HIPAA, a health plan, healthcare provider or healthcare clearinghouse. Section 2.5

Data classification

Labelling data by how much damage a leak could do (for example public, internal, confidential, restricted) so protection fits. Section 2.6

Data minimisation

Collecting and keeping no more data than needed. It is the legal argument for subsetting. Section 2.5

Data steward

The person who knows a data set's meaning and quality and says what a column holds and who may see it. Section 2.9

De-identification

Making data no longer point to a person. HIPAA names two ways: remove 18 listed identifier kinds, or get an expert to certify tiny risk. Section 2.5

Detection signals

The clues tools use to find sensitive columns: column name, data pattern, list of values, plus type and length. Section 2.7

Direct identifier

Data that points to one person on its own, such as an SSN. Section 2.4

DPDP Act

India's 2023 consent-centred law on digital personal data. Rules are phased in, so check current status. Section 2.5

Especially sensitive data

Data many laws treat as extra delicate, such as ethnic origin, religion, health or biometrics. Blanking it can beat faking it. Section 2.6

GDPR

General Data Protection Regulation: EU law, applying since May 2018, covering personal data of people in the EU wherever the company sits. Section 2.5

HIPAA

US law from 1996 whose Privacy and Security Rules protect health information that identifies a person. Section 2.5

Identifier

A piece of data that points to one person, alone (direct) or in combination (indirect). Section 2.1

Indirect identifier (quasi-identifier)

Data that identifies only in combination, such as zip code plus birth date plus gender. Section 2.4

Minimum necessary

HIPAA idea: people and systems get only the least PHI their job needs. Testers rarely need the real thing. Section 2.5

PCI data

Payment card details such as card number and expiry date. Section 2.3

PCI DSS

Data Security Standard from the card brands for anyone handling card data. A contractual standard, not a law. Section 2.3

PHI (Protected Health Information)

Health data that can be tied to a person. The link to an individual, not the diagnosis alone, makes it PHI. Section 2.3

PII (Personally Identifiable Information)

Data that identifies a person alone or combined with other data, such as name, email, phone or government ID. Section 2.3

Pseudonymisation

Replacing identifiers with pseudonyms while a way back exists elsewhere; still personal data under GDPR. Section 2.30

Regular expression (regex)

A compact text recipe for a pattern, for example three digits, a hyphen, two digits, a hyphen, four digits. Section 2.7

Re-identification

Working out who a "nameless" record belongs to by combining it with other information. Section 2.4

Sensitive data

Data that could hurt a person or company if leaked or misused. "Sensitive" is a business and legal judgement. Section 2.2

10.27 ETL

All-or-nothing load

Loading inside a transaction so a failure undoes everything. Section 3.27

Batch processing

Collecting data for a period and processing it as one group; easy to re-run. Nearly all test data provisioning is batch. Section 3.23

Bulk load

Loading rows in the database's native bulk-load format instead of row by row, used for very large volumes. GenRocket's bulk load receivers write that format. Section 3.22.1

Change data capture (CDC)

Any technique that detects which source rows were inserted, updated or deleted, so only those are processed. Section 3.19

Cleaning

Making values consistent so equal things look equal, such as "MENON" and "Menon ". Section 3.21

Data quality dimensions

Completeness, validity, uniqueness, consistency and timeliness: five questions to check a load. Section 3.28

Data warehouse

A separate database built for reporting across lots of history, with a few big reads. Section 3.17

Deduplication

Keeping one row for each real-world thing. Section 3.21

ELT

Extract, Load, Transform: load raw data first, then transform in the target. Raw sensitive data lands unmasked. Section 3.23

ETL

Extract, Transform, Load: copy data out of sources, reshape and clean it, write it to a target. Section 3.16

Extract

Reading data out of a source system without changing it. Section 3.19

Full extract / incremental extract

Reading everything every time, versus only what is new or changed since last time. Section 3.19

Integration (ETL) engine

The program that actually reads, transforms and writes rows. Section 3.24

Load

Writing transformed rows into the target correctly, repeatably and fast enough. Section 3.22

Lookup (ETL)

Enriching a row by finding a related value in a reference table. Section 3.21

Mapping (ETL)

The definition of how source columns become target columns; also, narrowly, translating codes like S to Shipped. Section 3.21

Mapplet (ETL)

Informatica's reusable group of transformations, built once and used in many mappings. Section 3.26

Metadata repository (ETL)

A database storing mapping and connection definitions and run history. Section 3.24

Operational database (OLTP)

The database an application uses to run the business, built for many small fast reads and writes. Section 3.17

Reconciliation

Comparing counts and totals between two stages to show nothing was lost or invented. Section 3.28

Reject (error) row

A row the job could not process, written aside with a reason instead of stopping the run. Section 3.27

Scheduler

Starts jobs at the right time or after another job finishes. Section 3.24

Session (ETL)

A runnable instance of one mapping with its run settings. Section 3.25

Slowly changing dimension (SCD)

A way to keep history in a warehouse table when descriptive data, like an address, changes. Section 3.22

Staging area

A temporary landing zone where extracted data sits unchanged before transformation. Section 3.20

Streaming

Processing each event within seconds of arrival. Section 3.23

Transform

Turning staged raw data into the clean, correctly typed shape the target needs. Section 3.21

Transformation

One operation on rows, such as filter, lookup or aggregate. Section 3.25

Truncate and load

A full refresh: empty the target table, then insert everything. Section 3.22

Type conversion

Turning text into real dates and numbers so sorting and arithmetic work. Section 3.21

Upsert

"Update if the row exists, insert if it does not." Section 3.22

Watermark

A saved marker, such as the last order id loaded, telling the next run where to start. Section 3.19

Workflow / job (ETL)

A set of sessions and steps with an order and conditions, started by a schedule or trigger. Section 3.25

10.28 Informatica TDM

Actions menu (Informatica)

A menu that changes with the view; almost every task starts with "click Actions". Section 4.10

Ad hoc rule (Informatica)

An unnamed rule made directly on a column inside one project; it cannot move to another project. Section 5.17

Advanced rule (Informatica)

A rule that combines techniques using input, variable and output columns, to mask or generate several columns together. Section 5.3

Application service (Informatica)

A background program in the installation that does one job, such as running profiles or workflows. Section 4.1

Assignment (Informatica)

The link between a rule and a column, made directly or through a data domain. Section 5.2

Audit Trail Report (Informatica)

A report of all recent activities (type, object, user, time); it ignores permissions. Section 5.40

Auto cascade (Informatica)

Masks a parent key and its child foreign keys with the same value; applied by default where key constraints exist. Section 5.4

Column profile (Informatica)

Reports range, values and patterns of chosen columns so generation rules can be inferred. Section 4.32

Concatenation pipe operator (||) (Informatica)

In a PowerCenter expression, || joins values into one string, as in first_name || ' ' || last_name; the concatenation function does the same. Section 5.9

Conditional constraint (Informatica)

A table-level rule limiting one column by another, such as To_City not equal to From_City. Section 5.23

Conformance (Informatica)

The percentage of rows that fit a rule or pattern; a threshold lets a few disagree. Section 4.25

Connection (Informatica)

Saved access to a database, repository or service; plans choose source, target, staging, lookup and storage connections. Section 4.4

Constraint (Informatica)

A rule linking two tables, usually a foreign key; physical if declared in the database, logical if added in TDM. Section 4.39

Content panel and Details panel (Informatica)

The two screen areas: one lists items, the other shows more about the selected row. Section 4.10

Criteria parameter (Informatica)

A named placeholder in an entity filter so the value can change at run time. Section 4.39

Curation (Informatica)

Reviewing suggested profile results and approving or rejecting each. Section 4.25

Custom rule (Informatica)

A global rule that uses the logic of an imported PowerCenter mapplet. Section 5.17

Data coverage analysis (Informatica)

Checks whether a data set has enough rows for each combination of two chosen columns, shown as a grid. Section 5.41

Data domain (Informatica)

A named kind of data, such as Social Security Number, found by data patterns or column-name patterns, with a sensitivity level and preferred rules. Section 2.8

Data domain profile (Informatica)

A profile that assigns data domains to columns by searching data, column names, or both. Section 4.31

Data generation (Informatica)

Creating new realistic but fictional rows from rules instead of copying real ones. Section 5.15

Data Integration Service (Informatica)

The application service that performs discovery profiles and data coverage tasks. Section 4.4

Data integrity for subset (Informatica)

A plan setting for how far subsetting follows relationships: Transactional (default), Referential Only, One-way or Two-way. Section 4.44

Data pack (Informatica)

A data set published to the self-service portal for testers who do not use Test Data Manager. Section 5.29

Data pattern and metadata pattern (Informatica)

Two regular expressions on a data domain: one matches values, the other matches column names. Section 4.22

Data set (Informatica)

A named collection of tables in the test data warehouse; storing it again creates a new version. Section 5.44

Data Validation Option (Informatica)

A separate Informatica solution used with PowerCenter to check that target data is accurate. Section 4.3

Dictionary (Informatica)

A file or table of ready-made values that a rule picks from; an authorised user must add it to TDM first. Section 5.22

Driving table (Informatica)

The table chosen as an entity's starting point. Section 4.39

Effective Dates technique (Informatica)

Fills start and end date columns so periods follow one another without overlap. Section 5.22

Encryption masking (Informatica)

Standard (AES, CRC, MD5) or format-preserving encryption; the latter can be decrypted with the same pass phrase. Section 5.6

Entity (Informatica)

A driving table plus all tables related to it by constraints; the unit copied to a subset. Section 4.42

Entity profile (Informatica)

A profile that finds possible entities by comparing column names across source tables. Section 4.30

Exception handling (Informatica)

Per-rule settings for nulls, blanks and errors, plus optional pre- and post-processing expressions. Section 5.5

Exception test data (Informatica)

Deliberate nulls and invalid values, set as percentages, mixed into generated output. Section 5.21

Expression Builder (Informatica)

A dialog for building a formula by picking functions and columns. Section 4.17

Expression masking (Informatica)

Applies a formula built in the Expression Builder; repeatable output needs a storage table. Section 5.6

Expression transformation (Informatica)

A PowerCenter transformation that computes a new value for every row; the mapplet example uses one to build full_name. Section 5.9

Generation rule (Informatica)

A saved recipe for one kind of value: a technique plus its parameters. Section 5.14

Global rule (Informatica)

A named rule created once in Policies and reusable in every project. Section 5.17

Group (Informatica)

Unrelated tables, or tables to copy unfiltered, added to a plan as they are. Section 4.43

ilmcmd, tdwcmd, tdwquery (Informatica)

Command-line programs: ilmcmd runs some TDM tasks, tdwcmd lists warehouse details, tdwquery runs SELECT queries on a data set. Section 5.42

Impacted Objects dialog (Informatica)

A warning listing what breaks when you change or delete something already in use. Section 4.10

Informatica Administrator

The web client where a domain administrator manages application services, users and groups. Section 4.4

Informatica domain

The family of Informatica services installed and managed together, with a shared set of users. Not a data domain. Section 4.1

Job (Informatica)

Something TDM runs, such as a profile, workflow generation or workflow run, listed in Monitor with a state like In Queue, Running, Success, Error or Terminated. Section 5.39

Key masking (Informatica)

Deterministic masking from input, rule and seed; give key columns in both tables the same seed. Section 5.6

Logical key or constraint (Informatica)

A key relationship defined only inside TDM; the source tables are not updated. Section 4.25

Major / minor constraint (Informatica)

A foreign-key severity: major pulls rows both ways, minor only child to parent. Section 4.44

Mapplet Designer (Informatica)

The part of PowerCenter Designer where mapplets are built. Section 5.9

Mapplet (Informatica)

A reusable group of PowerCenter transformations; TDM can import one as a custom masking or generation rule. Section 5.9

Mapplet Input transformation (Informatica)

The mapplet box that lists the input ports, such as first_name and last_name, that receive values from the mapping. Section 5.9

Mapplet Output transformation (Informatica)

The mapplet box that returns the output port, such as full_name; without it the mapplet has nothing to return. Section 5.9

Masking rule (Informatica)

A technique plus its parameters, saved under a name. Section 5.1

Masking technique (Informatica)

The logic that replaces a value, such as substitution or shuffle. Section 5.6

Model repository (Informatica)

Holds table metadata for discovery profiles and connection information. Section 4.4

Monitor (Informatica)

The view for checking job status, stopping jobs and reading logs. Section 5.39

Normal load (Informatica)

The load setting chosen in Workflow Manager when the target has a primary key; bulk loading skips some database checking and logging. Section 5.9

Nullification (Informatica)

Replaces the value with NULL. The strongest privacy result, but the target column must allow NULL. Section 5.6

Override (Informatica)

Letting whoever assigns a rule change its parameters for one column. Overridden seeds on matching columns break the match. Section 5.3

Parameter (Informatica)

A named placeholder whose value you supply at run time, so one plan serves many runs. Section 5.29

Plan (Informatica)

The saved recipe of one operation: components, source and target connections, settings. It does nothing until a workflow is generated and run. Section 5.30

Policy (Informatica)

A named bundle of data domains saying what is sensitive and how to protect it. It holds no data. Section 2.8

Policy pack (Informatica)

A ready-made policy shipped with TDM: PII, PHI or PCI. Section 2.8

PowerCenter

Informatica's ETL product, the engine under TDM. Section 4.4

PowerCenter Integration Service (Informatica)

Runs the subset, generation and masking workflows. Section 4.4

Preferred rule and default rule (Informatica)

Rules attached to a domain are preferred; one is the default for all its columns unless you pick another. Section 2.8

Profile (Informatica)

A saved search definition (tables, kind of analysis, sampling limits) you can run again. Section 4.25

Profiling warehouse (Informatica)

The database where profile results are loaded. Section 4.4

Project (Informatica)

The workspace for one job; holds imported source tables, profiles, assignments, subset definitions and plans. Section 4.18

Random masking (Informatica)

Non-repeatable output within a range or blur; no seed. Section 5.6

Reference Lookup technique (Informatica)

Takes values from an existing parent table so child keys are valid. Ad hoc only. Section 5.22

Repeatable output (Informatica)

Same input gives the same masked value in every table and run; switched on with a seed. Section 5.5

Repository (Informatica)

A relational database where Informatica keeps its own definitions and results, not your business data. Section 4.1

Reset (Informatica)

Copying a data set version from the warehouse back to a target so a test environment returns to a known state. Section 5.45

Residual tables (Informatica)

Tables not yet in any group or entity; tick them into a group to cover the whole source. Section 4.43

Restricted column (Informatica)

A column property that stops the value being written to the target. Section 2.6

Row Count Report (Informatica)

Shows the tables in a workflow run and how many rows were affected. Section 5.40

Rule (Informatica)

The logic that masks a value or generates test data: a technique plus parameters. Section 2.8

Rule Simulator (Informatica)

A built-in preview showing original beside masked values for a standard rule. Section 5.3

Seed (Informatica)

A start number, 1 to 999 and default 1, giving repeatable output. Note: sources differ; one guide table says 1,000. Section 5.5

Sensitive flag (Informatica)

A per-column label for reference only; nothing is masked until a rule is assigned. Section 2.6

Sensitivity level (Informatica)

A label on a data domain, from a list an administrator defines. Section 4.10

Sequence technique (Informatica)

Generates ordered numbers or dates from a start value and increment. Section 5.22

Set of Values technique (Informatica)

Generates a short typed list of values, each with a percentage of rows. Section 5.22

Shuffle masking (Informatica)

Swaps a column's values between rows; random, representative or constrained variants. Not allowed for XSD sources. Section 5.6

SSN, SIN, phone, credit card, email, IP and URL masking (Informatica)

Built-in techniques that keep each format valid, for example a card number keeps a valid checksum. Section 5.6

Staging connection (Informatica)

A database connection for temporary working tables; recommended as the source for cyclic subsets. Section 5.33

Standard rule (Informatica)

A built-in technique with parameters: one technique, one input column and one output column. Section 5.3

Storage connection (Informatica)

A database holding storage tables for repeatable substitution and expression masking. Section 5.33

Substitution masking (Informatica)

Replaces a value with similar unrelated data from a dictionary; unique substitution fails if the dictionary is too small. Section 5.6

Template (Informatica)

An optional container for entities and groups; the guide gives little detail. Section 4.43

Test Data Manager (Informatica)

The web client you work in; the name is also used for the whole product. Section 4.1

Test Data Manager Service (Informatica)

Creates and manages the TDM repository and runs Test Data Manager. Section 4.4

Test Data Warehouse (Informatica)

A central store for versions of test data, so teams can save and restore a known-good state. Section 5.43

Uniqueness percentage (Informatica)

The share of values in a column that are unique; 100 means no duplicates. Section 4.25

Value cascade (Informatica)

Gives similar columns not linked by a key the same masked value, via a chosen driving column. Section 5.4

Version and tag (Informatica)

Each re-store of a data set makes a new version; tags are comma-free words used to search data sets. Section 5.44

View (Informatica)

One of the main Test Data Manager screens, chosen from the tab bar. Section 4.10

Workflow (Informatica)

The runnable job TDM generates from a plan; PowerCenter runs it. Section 4.1

Workflow Manager (Informatica)

The PowerCenter tool where a workflow is created to run a mapping. Section 5.9

10.29 GenRocket

Attribute (GenRocket)

One characteristic of a domain, such as firstName; for a database it is a column. Section 6.3

Attribute property key (GenRocket)

A receiver setting for one attribute, such as columnName or include. Section 6.22

Bulk load receiver (GenRocket)

A receiver writing a database's native bulk-load file, much faster than JDBC inserts for millions of rows. Section 6.23

DDL import (GenRocket)

Creates domains and attributes from CREATE TABLE text. It does not create relationships, receivers or scenarios. Section 6.14

DelimitedFileReceiver (GenRocket)

Writes values to a delimited file such as CSV, with optional header and quoting. Section 6.24

Domain Dashboard (GenRocket)

The screen where you work on one domain's attributes, variables, receivers and scenarios. Section 6.14

Domain (GenRocket)

One "thing" you want data for. For a database it is a table; it can also be a file, message, JSON or XML document. Section 6.3

Domain Referencing Wizard (GenRocket)

Sets parents and siblings for many domains at once, with a diagram that redraws as you click. Section 6.15

Domain variable (GenRocket)

A named domain setting, global.DomainName.variableName, that generator parameters can use. Every domain has id, loopCount and seed. Section 6.16

EdgeCaseGen (GenRocket)

Slips tricky values, such as a negative age every fifth record, into otherwise normal data. Section 7.6

Encrypted scenario file (GenRocket)

The design sent from the cloud web platform to the customer side as an encrypted file (.grs), which the runtime executes to write data inside the customer's network. Section 6.5

Enforce Type/Limit (GenRocket)

Makes a generator keep values within the attribute's declared type and size. Section 6.18

EvalCaseGen (GenRocket)

Evaluates one equation using up to five variables and returns a true or false value. Section 7.6

FixedFileReceiver (GenRocket)

Writes fixed-width columns padded to set lengths. Section 6.24

FlexibleDateRangeGen / DateDeltaGen (GenRocket)

Date generators: one produces dates in a range and format, the other the gap between two dates. Section 7.10

G-Case / Test Data Case (GenRocket)

Changes components inside a scenario so one scenario gives many permutations for different test cases. Section 3.11

Generator (GenRocket)

The recipe that decides what value an attribute gets, such as a name from a list or a counter. Generators only generate; receivers format. Section 6.18

Generator parameter (GenRocket)

A setting on a generator, such as startRange. Required ones carry an asterisk. Section 6.13

Generator tag (GenRocket)

A rule: if an attribute name matches this text, assign this generator. Set per project or organisation. Section 6.18

Generator Tuning Wizard (GenRocket)

Step 3 of the XTS wizard: adjusts the generators behind each attribute across a whole project version, with statistics on how well they match. Section 6.18.3

GenericSQLInsertReceiver (GenRocket)

Inserts generated rows straight into a table through JDBC; a truncate option can empty the table. Section 6.24

GenRocket Runtime (GenRocket)

Java programs on your own machine that read a downloaded scenario and generate data inside your firewall. Section 6.6

G-Portal (GenRocket)

A self-service platform where requesters search for, request and download test data. Section 3.11

G-Repository (GenRocket)

The component that keeps scenarios and configuration files in sync across a company's machines. Section 6.5

.grs file (GenRocket)

The downloaded, encrypted scenario file you run with genrocket -r. Section 6.22

Import from DDL / XTS (GenRocket)

Two ways to create many domains from a schema: paste CREATE TABLE text, or extract structure from a live database. Section 6.14

Linked generators (GenRocket)

Several generators in one attribute, run left to right; later ones can use earlier values. Section 6.18

ListGen (GenRocket)

Picks from a fixed list of values, in order or at random. Section 7.5

Loop count (GenRocket)

How many rows a domain generates. A child's count is per parent row. Section 6.25

Masking receivers (GenRocket)

Receivers that take an existing file and write a new one with targeted values replaced. Section 6.24

Master project (GenRocket)

A project option for sharing master domains with other projects. Section 6.8

Model, Design, Deploy, Manage (GenRocket)

The four work phases of GenRocket's methodology: import the model, design the data, generate and deliver it, manage versions. Section 6.4

Offline certificate (GenRocket)

A file letting the runtime run scenarios without internet; organisation-specific and valid 24 hours. Section 6.6

Organization resource (GenRocket)

A named folder setting, such as resource.output.directory, each user fills with their own path. Section 6.23

Output format (GenRocket)

The shape of the result: delimited, fixed-width, JSON, XML, Excel, SQL statements and many more. Section 6.22

Parent, child and sibling domains (GenRocket)

A child has exactly one parent whose key it uses; a "describing" lookup table is marked a sibling. Section 6.15

PermutationGen (GenRocket)

Generates all possible combinations of the values it is given. Section 7.6

Preview (GenRocket)

Sample generated values shown in the web platform so you can check before downloading. Section 6.13

Primary attribute (GenRocket)

The attribute marked as the key, which children refer to. Section 6.13

Primary domain and root domain (GenRocket)

The primary domain is the one a scenario is built for; the root is the first parent at the top of the chain. Section 6.22

Project and project version (GenRocket)

A project holds the data model for one application or database; a version is one release's copy of it. Section 6.8

Project type (GenRocket)

Standard (default), Micro (domain-limited, such as files) or IPM (in-place masking of databases). Section 6.8

QueryOnceGen (GenRocket)

A query generator that reads real data from a database once, for example the current maximum id. Section 6.18

Quick Scenario (GenRocket)

Builds a scenario named after a domain, adding its parents and siblings for valid keys. Section 6.25

RangeGen / RandomGen (GenRocket)

Number generators: RangeGen counts up (or down); RandomGen picks a random number in a range. Section 6.18

Receiver (GenRocket)

The component that turns raw generated values into a usable output: file, SQL, message and more. Section 6.23

Receiver parameter (GenRocket)

A setting for the whole receiver, such as where to write; a star marks required ones. Section 6.22

Reference parameter (GenRocket)

A parameter value pointing at another attribute or generator, so one value is built from others. Section 7.14

ReferenceGen / ProxyReferenceGen (GenRocket)

The foreign-key pair: the proxy marks "a parent key goes here" on the domain; the real ReferenceGen replaces it in a scenario. Section 6.18

Scenario chain (GenRocket)

Linked scenarios run in order by one command; a chain set links chains. Section 6.25

Scenario domain (GenRocket)

A scenario's copy of a template domain; template changes flow down unless locked. Section 6.13

Scenario (GenRocket)

A saved instruction sheet: which domains to generate, how many rows, in what order. Running it makes the data. Section 6.25

Scratch Pad (GenRocket)

A way to create a domain from a domain name and a list of attribute names, optionally with type and size; generators are assigned automatically. Section 6.14.3

Seed (GenRocket)

A starting number for random generators; the same seed gives the same "random" data. Every domain has a seed variable. Section 6.18

Segment-and-merge receivers (GenRocket)

Pairs that build nested JSON or XML: each domain writes segments, a merge receiver combines them. Section 6.24

SimplePatternGen (GenRocket)

The fallback generator making values like name1, name2. Treat it as a to-do marker. Section 6.18

SQLFileInsertReceiver (GenRocket)

Writes a file of SQL insert statements without touching a database; a safe first choice. Section 6.24

Stateful scenario (GenRocket)

A scenario that remembers generator positions between runs, so a counter continues. Section 6.25

Synthetic Data Replacement (GenRocket)

GenRocket's masking method: replacing sensitive values with synthetic ones. Section 6.24

Template domain (GenRocket)

A domain as defined in a project version, the master copy scenarios copy from. Section 6.14

Test Data Automation (GenRocket)

GenRocket's phrase for defining test data once as components and generating it automatically, whenever a test needs it. Section 6.4

Test data case suite (GenRocket)

In the 2022 demo, a suite of unit, negative, load and integration cases built by a self-service module, with volume set per domain and rules controlling the output. Section 6.4.2

Test Data Engineer (GenRocket)

A trained person who models test data projects and designs the data for others. Section 3.9

Test data project (GenRocket)

The data model for one application or database (domains, attributes, generators, receivers, scenarios) with no customer data; also the unit of licensing. Section 6.8

Test data rules, G-Rules (GenRocket)

Condition-and-action rules attached to cases rather than single attributes, suited to complex if/then/else logic. Section 6.18.5

Test plan (GenRocket)

A set of scenarios run with one command, as when a Jenkins job runs GenRocket against a test plan. Section 6.25.10

User profile and server profile (GenRocket)

A .grp file in the .genrocket folder that ties a person, or a CI/CD server, to a licence. Section 6.6

Visible (GenRocket)

An attribute setting; if false, receivers do not see it, so it works as a helper. Section 7.14

Web platform (GenRocket)

GenRocket's cloud web application, where you model and design. Also called GenRocket Cloud. Section 6.1

WeightGen / MultiWeightGen (GenRocket)

Percentage-based choice: WeightGen splits between two values, MultiWeightGen among any number. Section 7.5

XTS (GenRocket)

Extract Table Schema: a runtime option that writes a live database's structure, not data, to an encrypted file. Section 6.14

10.30 Delphix

Algorithm (Delphix)

The recipe that replaces a real value with a safe one. Profiling only chooses it; the masking job runs it. Section 8.39

Algorithm framework (Delphix)

A kind of algorithm you configure into instances, such as Secure Lookup or Segment Mapping. Section 9.1

Algorithm instance (Delphix)

A named framework plus settings, such as dlpx-core:FirstName. This is what you assign to a column. Section 9.1

Algorithm key (Delphix)

A secret value inside most algorithms; changing it changes every output. Section 9.1

Algorithm syncability (Delphix)

Copying algorithms between engines so both mask alike. Non-deterministic ones cannot be synced. Section 8.35

Application (Delphix)

A tag naming the system whose data you manage; create one before an environment. Section 8.16

ASDD profiler (Delphix)

Automated Sensitive Data Discovery, the current profiler, using classifiers instead of the legacy search expressions. Section 8.39

ASDD Standard (Delphix)

The recommended built-in profile set, with path, type, regex and list classifiers. Section 8.43

Assignment threshold (Delphix)

The minimum confidence before the profiler writes a domain and algorithm into the inventory. Section 8.39

Async Task (Delphix)

A background task whose ID you can search under Monitor, Async Tasks. Section 8.4

Character Mapping (Delphix)

A keyed one-to-one swap of characters within groups you define; unlisted characters stay. Suits key columns. Section 9.4

Checklist (Delphix)

An action checking that every table in a rule set has a primary key, an indexed identity column or a logical key. Section 8.34

Classifier (Delphix)

One recognition rule tied to one domain, such as a column name that looks like ssn. Section 8.39

Classifier framework (Delphix)

A kind of classifier: PATH (table and column name), TYPE (data type and length), REGEX (data) or LIST (values in a list). Section 2.7

Collision (Delphix)

Two different real values masked to the same fake value. Section 8.7

Confidence (Delphix)

A 0 to 100 score for how sure the profiler is about a match. Section 8.39

Connector (Delphix)

Saved details the engine uses to reach one database or set of files. Section 8.17

Containerized engine (Delphix)

The engine run as a Kubernetes pod of three containers; meant for ephemeral use, and without FTP file masking. Section 8.8

Continuous Compliance engine (Delphix)

The product that discovers sensitive data and masks it; also called the masking engine or Compliance Engine. Section 8.1

Continuous Data engine (Delphix)

The virtualization product that creates VDBs; never run it in the same machine as the masking engine. Section 8.23

Copybook (Delphix)

A rule set type for mainframe data sets described by a copybook. Section 8.30

Date Shift (Delphix)

Moves a date within a range, never back onto itself. Fixed shifts are deterministic; variable ones are not syncable. Section 9.9

Dependent Date Shift (Delphix)

Masks two related dates together, keeping their order and interval. Section 9.4

Domain (Delphix)

A named kind of sensitive data, such as FIRST_NAME, with exactly one default masking algorithm. Section 8.1

dSource (Delphix)

The engine's compressed copy of a source database from which VDBs are made. Section 8.23

Encoding (Delphix)

How characters become bytes. ASCII and UTF-8 for most file types; mainframe data must be EBCDIC. Section 9.17

End-of-record (Delphix)

The characters ending a line: LF on Linux, CR+LF on Windows. Section 9.15

Environment (Delphix)

A folder-like container inside an application holding connectors, rule sets and jobs. Its purpose is Mask or Tokenize/Re-Identify. Section 8.16

Extended connector (Delphix)

A connector on an uploaded JDBC driver, for databases not supported natively. Section 8.15

File connector and file rule set (Delphix)

The connector says where files are; the rule set lists which files or name patterns and which format each uses. Section 9.15

File format (Delphix)

A small uploaded description of a file's field names (and lengths for fixed width). Metadata only. Section 9.19

Free Text Redaction (Delphix)

Blanks sensitive words and patterns inside notes columns; needs expertise to configure. Section 2.32

Identity column (Delphix)

A column that numbers rows automatically; the engine can use one as the key or add a temporary one. Section 8.27

In-place / on-the-fly (Delphix)

In-place changes data where it sits; on-the-fly reads a source and writes masked data to a target. Section 9.11

Inventory (Delphix)

The table of every column or field in a rule set with its domain and algorithm: profiler output, masking input. Section 8.39

JDBC (Delphix)

Java Database Connectivity. The engine uses a JDBC driver per database and a JDBC URL to say where to connect. Section 8.15

Job (Delphix)

A saved runnable task: profiling, masking, tokenization or re-identification. Section 8.1

Logical key (Delphix)

A unique, non-null column (or columns) you tell Delphix to treat as the row identifier; the database is unchanged. Section 8.33

Lookup file (Delphix)

A text file with one replacement value per line; the algorithm picks a line from the input. Section 9.1

Mapping (Delphix)

You supply replacement values; each input gets a distinct output, stored encrypted. Needs enough values. Section 9.9

Masked VDB (Delphix)

A VDB whose data was masked by a masking job during provisioning; it cannot be unmasked. Section 8.23

Masking engine (Delphix)

The Continuous Compliance engine, where connectors, rule sets, profiling jobs and masking jobs are defined. Section 9.30

Masking job (Delphix)

A saved set of options to apply a rule set's inventory, with a method, threads, memory and scripts. Section 9.1

Masking user (Delphix)

A dedicated database account for the connector, with only the permissions masking needs. Section 8.15

Match strength (Delphix)

A weight on one classifier match, such as 0.7 for a dashed SSN; several weak clues combine. Section 2.7

Meta Data Source (Delphix)

The connector screen grouping: Database, File or Mainframe. Section 8.15

Min Max (Delphix)

Pulls extreme values toward the middle, since the top salary may reveal a person. Section 9.4

Multi-Tenant (Delphix)

A job option letting one rule set serve identical schemas through different connectors chosen at run time. Section 8.23

Non-conformant data (Delphix)

A value not fitting the expected format. By default it stays unmasked and only a warning is recorded, so check job warnings. Section 8.7

Out-of-the-box instance (Delphix)

An instance shipping with the engine; it cannot be edited or deleted. Section 9.1

Payment Card (Delphix)

Keeps the first digits and the card's Luhn validity, masking the rest. Section 9.4

Profile set (Delphix)

A bundle of classifiers; choosing one decides which kinds of sensitive data a job can detect. Section 8.39

Profiling (Delphix)

Scanning column names and optionally data to find sensitive columns. Also called sensitive data discovery. Section 8.39

Profiling job (Delphix)

A saved instruction to scan a rule set using a profile set. Section 8.39

Record type and qualifier (Delphix)

When one file mixes layouts, a record type names each layout and up to three qualifiers recognise it. Section 9.20

Role (Delphix)

A set of allowed actions on object kinds; each user has one role and a list of environments. Section 8.9

ROWID (Delphix)

An Oracle pseudocolumn holding each row's address; recommended as the logical key for speed. Section 8.27

Rule set (Delphix)

The list of tables or files of one connector that jobs may look at. Four types: Database, Semi-Structured, Flat Files, Copybook. Section 8.30

SDD (Selective Data Distribution) (Delphix)

Replicating a masked VDB to another engine in non-production without sending unmasked data. Section 8.15

Secure Lookup (Delphix)

Picks a replacement from a lookup file by hashing the input, so output is consistent. Collisions are possible. Section 8.7

SecureShuffle (Delphix)

Moves each value to a different row; the values stay real and the result is not syncable. Section 2.32

Segment Mapping (Delphix)

Masks short values by segments with no collisions, if the allowed set is big enough; suits SSNs and keys. Section 8.7

Snapshot and TimeFlow (Delphix)

A snapshot is a dataset's state at one moment; the TimeFlow is the timeline of those states. Section 8.23

Stream (Delphix)

One parallel lane of work; more streams let the engine process several tables at once. Section 9.1

String Algorithm Chain (Delphix)

Runs two to eight string algorithms one after another. Section 2.32

Text enclosure and escape (Delphix)

The enclosure (often a double quote) wraps a value that may contain the delimiter; the escape writes a literal enclosure. Section 9.15

Tokenization (Delphix)

The only reversible family, using AES-128 and Base64; output is longer than input. Reversing it is re-identification. Section 9.9

Update threads (Delphix)

Parallel threads writing to the target database; too many can deadlock and each table needs an index. Section 9.11

VDB (virtual database) (Delphix)

A full read-write copy of source data provisioned from a dSource or another VDB, created in minutes. Section 8.23

Virtual appliance (Delphix)

A ready-made machine image of the engine imported into a hypervisor or cloud. Section 8.8

Whole-file masking (Delphix)

Sending a file to one algorithm in one piece, using a format with one field of length 0. Section 9.26

Definitions are drawn from the guide's own sections; see each linked section for its sources.