@Igor OK, so, to put question (13) in a different way: What are the attributes that you want to keep track of when an accident happens with respect to a letter? For instance, as per your response: What attributes would you like to store if a letter gets lost due to being involved in an accident? Which ones if it returns to the initial or the preceding wharehouse?

(17) I think that it would as well be necessary or convenient to store data about the fact that some person took a letter to the warehouse of origin, what do you think?

(18) How many warehouses would be involved in this scenario? What does the attribute named warehouse.capacity mean in this business context?

(19) On the other hand, I assume that any given person might come at different and separate opportunities to send one ore more letters. In this way, a certain person would have to register his/her name and (current?) address in each opportunity, each of which would pertain to a single letter. Is this assumption correct? Perhaps adding the storage of some sort of national identification number to the sender data would help to associate each letter with a single sender?

Or maybe that point is not particularly relevant regarding this specific project. Let me know your considerations about it.

Regarding your response to question (15) Does that mean that the adressee cannot pick up a letter directly from the destination warehouse and that the system would only cover the possibility of a courier delivering letters to the addresse location?

(20) What data would you like to store if, at a certain delivery attempt the courier didn't find the addressee and could not deliver the letter successfully? Can someone different from the addressee receive the letter? If yes, what information would be of significance regarding your database? What data is of relevance if the courier cannot find the location of the addressee and therefore the delivery attempt didn't succeed?

@Igor Yes, in order to define if a given diagram is correct or not, an analyst must know the business domain being modeled or represented. The objective of a database diagram should be that it reflects its business domain accurately, with precision. This requires identifying the entity types of interest, their attributes, and the pertinent interrelationships.

Since a system-generated surrogates are not natural qualities of the data, adding it to the tentative entity types complicates the analysis, as one should first understand the nature of the information being modeled.

System-generated surrogates hinder the understanding of a business domain. Once a stable model is obtained, one can easily define in which particular situations the addition of such an artefact may be convenient, as it is always an attachment, an extra element that requires especial management.

A system-generated surrogate does not make the definition and declaration of natural keys obsolete, which are required to provide real entity type instance uniqueness (or row uniqueness if stored in a SQL platform).

That's why one has to be cautious regarding their usage, which should always be well justified.

See this exceptional Stack Overflow answer by @PerformanceDBA for very important information about system-generated surrogates.

@Igor Once we solve these pending questions I will be able to start working on a proper answer.