3 tables... please!
Database 1. "information which is broadly what is on your passport already"
i.e. who you are
Database 2. "There is the one that holds the fingerprints and facial image, the biometric data"
i.e. how to prove who you are
Database 3. "and the third bit is the one that links the two,"
i.e. the very important bit.
if i want to search for/browse/aggregate information on people I just need access to database 1
if i am the police and i want to verify a given identity (stop and search) I just need access to database 2
if i want to trawl for a fingerprint match I need access to all 3, so that i can work back to the record in 1, by getting a match in 2, via 3
access can be controlled based on functional area, with reduced need around access.
- council uses the database as its source on people in the area (or FKs its own database from it) and only for this.
no connectivity at all needs to be setup to databases 2 and 3, hence "mr. council person" can't look at the biometric data (if he wanted to!) even if he "borrows" his good friends "mr. policeofficer"'s login.
database 3: "the one that links the two"
it will be an awful lot easier (design, development and especially TESTING) to add links to databases 4, 5, 6 etc. in future with the link info. split out.
also, as the biometric data is hidden away in another database to which access can be totally independently controlled, why do databases 4-6 have to be government databases.
- UKGOV PLC can supply uniqueIDs for everyone in the country, to commercial organisations, (theoetically) without UKGOVs own data being accessable.