Letters can be transported multiple times perhaps? If so then a LetterTransport bridging table which includes the TransportID and LetterID might be necessary.

Yes, you're right, thank you. Also what about deliveries - is it ok that they are in relationship with warehouse (letters are taken from warehouse), because letters are already connected to warehouses via DateStorage?

Ok, I added more information, and changed this er diagram a bit.

Very good revision, +1! On the other hand, now there's a point that I consider requires more analysis: What is a Delivery Attempt? That means that a certain Delivery can be sent but not received?

Ok, I removed delivery attempts as this indeed complicates whole thing. Now, the whole process looks like this - Letters is collected from sender -> it goes to warehouse, then it could be transferred between warehouses, and at last letter is delivered to recipient

@Igor If a delivery attempt is an important aspect of your business context (and according to my understanding of the situation, it really is, but I am not sure if it is an entity prototype, or an attribute, or a set of attributes), then it must be depicted in the diagram (and, naturally, in the consequent database structure). I consider that you should analyze that concept more deeply, and edit the question with the relevant deliberations in this respect.

Now, it's important to note that there is a process which is relevant to the business context, but in order to create a database model, you should focus on the structure of the things of interest, rather than on the processes (much more relevant for an application program design). In this way, what are the attributes that pertain to a Letter? Only its Weight? There must be one or more that uniquely identify each Letter instance? Assuming that Letter.ID is a surrogate, it does not suffice to make every instance unique, so there should be a natural (meaningful) key over there.

Meaningful PRIMARY (and ALTERNATE) KEYs are of great importance when creating a logical model, as they are quite helpful to delineate a certain structure with its pertinent interrelationships. Surrogates should be taken into consideration once (a) a model is stable and (b) the implementation phase has started. In this way, knowing more about the attributes of the things of interest would be quite helpful to analyze your business domain more accurately.

Ok, there are some additional attributes for example Date of posting ,but still I can't think of any key (other than surrogate) that would uniquely identify 2 letters send by the same sender to the same recipient on the same date.

It looks as if there is a 1:1 relationship between a letter and a Collection. If a collection contains only a single letter, then perhaps the CollectionDate (and any other attributes of collection, such as the person who collects the letter) should be attributes of the Letter itself. Likewise with Deliveries.

@Igor (1) Can multiple letters be sent by the same person at the same date and time? (2) Won't there be any sequential letter number with meaning (as opossed to a surrogate that lacks business meaning)? (3) What happens when a letter is not located in any warehouse or, to put it some way, when it is being transported, would you like to keep track of that aspect? (4) What happens if a letter is rejected by a receiver at a certain warehouse? (5) What happens if a letter is sent, then it is transported, but never reached the destination warehouse?

(6) What happens if a letter spends several days (or weeks) being transported before it reaches the destination warehouse?

1. Yes 2. You're right. 3. Yes, at any time, I would like to know where the letter is - no matter if it is in some warehouse or it is being transported. 4. We can assume that if transport arrive to the destination warehouse, all letters are accepted. 5. That is another aspect which I don't know yet how to solve best. I edited my answer and put new diagram, which is I think more appropriate.