Looking at the Digikam database (SQLite version):

• Photos are identified with unique IDs
• These ids are linked to a file name and an "album", and a "hash"(*)
• An "album" has among other things a relative path and a root

So it's not as simple as it looks (even though it makes perfect sense to a programmer like me, this is a rather plain relational database).

Experimentally:

• I created a "Marker" tag
• I attached it to an existing picture
• I exited Digikam
• I created a directory (under Digikam's "root")
• I move the picture to it
• I restart Digikam and:
  1. The new directory and picture are there
  2. The picture still has the tag.

Looking at the database contents, the moved picture still has its original ID, so Digikam detected that it was moved. Given the presence of the hash in the image data, this is not surprising.

More experimentation:

• Behing Digikam's back, I move the file out of its reach
• I open Digikam, check that the file isn't there, close Digikam
• Inspect the database again, the image is still there, but is not associated to an album
• Move the image back under Digikam's root
• Open Digikam: the image is there and still has the "Marker" tag
• Looking at the database contents, it is still the same image id, but it now has an album.

So, all in all, Digikam data seems fairly resilient to file manipulation done outside of it.

Tests done with Digikam 7.5.0.

(*) A hash is a (large) number derived from the file contents (checksum on steroids). Two different files are very unlikely to have the same hash, and if you are given a file, you can compute its hash, and see if you have any other files with the same hash. If not, the file is new, if yes, you only have to compare it with the very few that have the same hash to identify it.