Skip to content
Request a demonstration

AutoDiscover

Understand a database, read only

Business data lives in systems whose structure only a few people understand.

Demonstration: Wexcombe Retail Group (fictional) · Retail. Fictional data and a scripted answer.

The situation

Organisation
Wexcombe Retail Group (fictional)
Who is asking
Data governance lead
Industry
Retail
What happened
The company is connecting a read-only copy of its sales database and must know which columns hold personal data before anything is analysed.

The question asked

Which columns in this database hold personal data, and which classifications are we sure of?

What it reads, and who can see the result

  • Schema and a small profile databaseTable and column names, types and statistical profiles from a read-only replica; no row content leaves.
Reads
The schema and aggregate profiles (counts, null rates, pattern types) through a read-only account on a replica.
Does not read
Individual rows' values at this step; nothing is written.
Permission
A read-only database role created by the data owner for the replica.
Who sees it
The data governance lead and the database owner.

Try it

Review each flagged record: confirm it or dismiss it. The totals and the answer below follow your decisions.

ColumnTypePattern foundRowsFindingDecision
orders.totaldecimalAmounts4,800,000MatchedNone needed
customers.emailtextEmail address pattern in 97% of rows610,000Looks like an email address
products.skutextCodes18,000MatchedNone needed
customers.postcodetextPostcode pattern610,000Postcode may identify a household
support.notesfree textNames and phone numbers appear in a sample240,000Free text: personal data appears in places and cannot be ruled out elsewhere
stores.manager_idintegerLinks to the staff table410A key that points to a person
orders.channeltextFive values4,800,000MatchedNone needed
Flagged
4 of 7 · 1,460,410
Personal data
0 · 0
Not personal
0 · 0
Undecided
4 · 1,460,410

The answer

Simulated answer. Written for this fictional case, not produced by a live model. Only the figures in it are computed, from what you decided above.

4 of 7 columns may hold personal data, covering 1,460,410 rows.

Discovery reads the shape of the data, not the values: pattern types and null rates are enough to flag an email-like column [S1]. A postcode, a person-linked key and a free-text field are less obvious, and the definitions in the policy decide how they are treated [S2].

You have classed 0 as personal data (0 rows) and 0 as not personal (0); 4 are undecided. A free-text column cannot be cleared by a sample alone.

Relies on: S1 · Replica schema and profileS2 · Personal-data definitions

Review and approval

The data governance lead decides. Approving records the classification used for every later analysis. It does not read any row values and does not change the database.

Not ready to approve. 4 flagged columns are still undecided. Confirm or dismiss each one first.

In the product this is a different person with the right permission. Here you play that role to see the rule.

What it produces

registerDraft, not approved

Column classification

  • Personal data: 0 columns, 0 rows.
  • Not personal: 0 columns.

Limits of this example

  • A pattern is a signal, not proof; a numeric column may still identify someone.
  • The replica must stay read-only; the connection can be revoked by the database owner.
  • This is a scripted demonstration on fictional data. No model was called and no real organisation, person or result is shown.