So if you have an order with many line items, you cannot have a field in the order that refers to the line items. Objects don't have this limitation and it's natural for objects to have collections of references to other objects. So not just do we have to correspond between keys and references, we also have to handle collections of references and correctly handle them in the database. The starting point to this structure is to save the database key in the object and to provide a lookup mechanism so that you can find an object when you know its key. This field is the natural key to use for a Identity Map .
Relational databases can use either one or several fields as a key.
To make it easier to do the mapping to objects it's better to have a single field for the primary key to use in the Identity Field . The database can have other keys for database lookup and enforcing uniqueness rules, but a machine generated surrogate key usually works best for the relationship to objects. Since many tables may refer to the incorrect id, updating the database can become a saga. So most of the time the id is never seen by a user. You can have keys that are unique to the table, or database wide unique keys.