The textbook case would be student IDs in a university database where each row corresponds to a single student. However some universities view the student id as sensitive information (kind of like a ssn in the US) and so in that scenario it should be aliased to some other key to prevent the student id from being present in multiple tables as a foreign key.
I am almost entirely convinced that there is actually no such thing as a natural key.
When I buy a car they record my name, my date of birth, the time of the sale and some details about the car, such as the VIN, which is its name. That provides enough information to form a natural key to identify the sale.
At no point does a database actually have a concept of who I am really, only the relevant data points to satisfy its own relational model.
Any database that means to track information about people would be able to construct a natural key from my name, my mothers name and some information about my birth, such as the doctor, hospital and time.
The thing is to qualify as a natural key I think it has to be precisely recoverable just from first principles wherever you encounter the artifact it references. The birth details aren’t inherent to the person, they’re datapoints about them.
All the identifiers you propose to make up mnatural’ keys are synthetic keys from some other authority for identifying things. VINs obviously are synthetic identifiers, but so are names, dates, hospital addresses.
As you rightly say, a string is a natural key for itself; likewise a number.
The only other ‘natural key’ I can think of is atomic number for identifying chemical elements.
By your definition there are no natural keys. But since that definition isn't useful we instead use one that is. The natural key is the identifier by which the thing is already known.
And your name, you said.
> The natural key is the identifier by which the thing is already known.
And then you change your name.
Yes! Or if it is now, there's a future scenario where that will have proven to have been a poor decision.
You seem to be conflating format and value. 1,234,567 and 1234567 are the same number. 19-Jun-21 and 2021-06-19 are the same date. Databases already handle this.
Dhuʻl-Qiʻdah 9, 1442 AH
9 Tamuz 5781
Congratulations, you just created another synthetic key for describing dates.
Aside from the fact that you have very limited knowledge of calebdar systems, I’m not sure what this is supposed to prove. “Natural” in “natural key” doesn't mean “exists in nature outside of human invention”, it means “exists outside the database as part of the data in the data model, rather than being created solely to have a ubique key in the database ubder design".
The date in whatever particular calendar system is used in the data model is a natural key for a calendar table.
“Student IDs” are an example of surrogate keys, though they may be surrogate keys in a system predating and outside of the DB.
(And if the mapping between them and actual students are managed by an error-prone process outside of the DB, they probably aren’t good primary keys for a table of students.)
It is ironic, given that the whole reason to have a student ID is for it to be a primary key in some database somewhere.