3. Declare a relationship stored as Name or String

Goal: Declare a relationship that a Name field alone does not express.

Before you start: The practice tables; download the additional table and profile.

The idea you will use

A Name or String may be a label or key. A profile declares when to resolve it against another table.

Predict before running

Will editing Label fix D2.TargetKey = Missing?

Build and check

Names and ordinary text can be labels. Declare explicitly which ones store keys from another table.

1. Download ConsumersByKey.csv and name-string-profile.json into Fixtures.
2. Create a User Defined Structure ST_ConsumerKeyRow with TargetKey of type Name and Label of type String. Create ConsumersByKey from it in /Game/RowTetherExample and import ConsumersByKey.csv.
3. Select Targets and ConsumersByKey, click Use selected DataTables, then load Fixtures/name-string-profile.json from References and game rules.
4. Wait for the review. The expected result is one ROWTETHER-ROW-MISSING on D2: Missing does not exist in Targets. D1 → T1 and D3 → T2 should resolve.
5. In ConsumersByKey, change D2.TargetKey from Missing to T3. Wait for the current review to finish before editing, then click Review tables again after the change.
6. Confirm Completed, sufficient coverage and that the finding disappeared because its source key changed.

The profile maps TargetKey to Targets; RowTether does not guess that a Name column is a relationship. You can use a String field with the same explicit mapping.

If D2 does not appear, check that TargetKey is a top-level Name property, the profile points to /Game/RowTetherExample/ConsumersByKey.ConsumersByKey and D2 contains Missing.

Check your reasoning

See the explanation

No. The relationship uses TargetKey. Change that key to an existing row.

Your turn: Locate T3 first, fix D2, run a fresh review and explain which evidence changed.

Ready to continue when: you can distinguish a label from a declared relationship.