AccessionSQL, one case at a time
#023Level 6 of 6 · Scenario 4: Provenance

The forgery

Scenario 4 · Provenance

A specialist has written to say that one object in the collection is not what its label claims, and that the proof is in the provenance rather than in the object. A genuine chain joins up: whoever receives a piece at one step is whoever sells it at the next. A fabricated one has a party inserted to cover a gap — someone who supposedly sold the object without any record of ever having acquired it. There are 180 objects and 339 transfers on file.

Schema · 3 tables
owners
  • idpkINTEGER
  • nameVARCHAR
  • countryVARCHAR
objects
  • idpkINTEGER
  • titleVARCHAR
  • wingVARCHAR
  • current_owner_idINTEGER
transfers
  • idpkINTEGER
  • object_idINTEGER
  • seqINTEGER
  • from_owner_idINTEGER
  • to_owner_idINTEGER
  • transferred_onDATE
  • document_refVARCHAR

Toolkit

SELECT
Choose which columns come back.
FROM
Specify which table to read.
WHERE
Filter rows by a condition.
ORDER BY
Sort the results by a column.
IS NULL
Test whether a value is missing.
INNER JOIN
Keeps only rows that matched.
self-join
Join a table to itself, to compare a row with another row.
<>
Not equal to.
Objective

Name the party that claims to have sold an object it has no record of ever receiving.

Your query

starting DuckDB…
loading editor…

The party in the gap

Results

No result yet.