If you're designing the services to be truly independent, then they're going to have to serve identity functions...ways to uniquely identify entities, so that they might be externally referred to. After all, the service is the boundary and you're not supposed to see through it to the underlying store. That identity really, really shouldn't change in the face of entity mutation - so it shouldn't be made up of mutable data - such as a customer's name or an employee name.
A particular application that uses the identity may map it or may use it as provided. Each application developed would be free to map-or-use the identity in a manner consistent with it's purpose. There is no reason to assume some kind of globalized/centralized mapping. If a centralized mapping feels right, then a centralized, relational store for all the microservices has got to feel even more right.
It gets complicated if the services need to support guarantees...like "I won't destroy this entity until you release it" - which could be a long- or short-lived promise. This is kinda like declaratively externalizing the idea of a foreign key. Applications would have to be able to release the protection on entities when all references are removed; and that can get complicated.
For example, imagine service s serving entity e, and application a wants to refer to e and wants a guarantee that e won't perish, then a needs an unique way to refer to the contextual protection of e. This way, a can inform s when e is no longer needed. Reference counting (in s or in a)isn't good enough.
Possibly, s can simply deprecate e and not destroy it - maybe mark it as logically deleted. This obviates the complexity of externalizing the foreign key relationship but makes data live longer than it might have to otherwise.
Another strategy a might employ is just getting over the fact that a referred-to entity is no longer there. That's not so simple either.
In short - applications relying on a multiplicity of microservices have their work cut out for them - the services may or may not play well in such an environment. One wonders if the joy of picking one's own data store when building a service is outweighed by the complexity visited upon the service's consumers. The strategies chosen are going to be dictated one's ability to tailor the service's behavior to the needs of applications. If we're talking about microservices from "out there", then the applications are going to have to be that much more robust, and may even decide to replicate substantial portions of the data provided by the service.