A customer should have just one address. When I checked the models done by our designer, I found something like this:
I am not a technical person but would it not mean that many customers have one address? I understand that is is normnalization so the address is tied to customers using FK.
On
ER diagrams have nothing to do with normalization.
Assessing the normal form of a logical design requires all the applicable functional dependencies to have been spelled out. ER diagrams are not a logical design (they are a conceptual design, and that's a different beast), and most of all they offer no way at all to specify the applicable FD's.
That said, the design you're facing satisfies the requirement that "each customer has just one address". But this is not the only possible design that satisfies the given requirement. A single-table design (Customer, ID, Address) has exactly the same property, so as far as the given requirement is concerned, both are equally good.
Where they differ is when you consider what will -most likely (*)- happen when you start changing/updating Customer addresses. If a customer currently has an address that he shares with some other customer, and you update the address for the former, do you want the address also to be changed automatically for the latter ?
In the design you're facing, this side-effect is very likely to occur. In the single-table design, it won't. Ask yourself whether you want it or not.
(*) it is always possible to address problems by throwing in extra code. But extra code means extra hours for the programmer to write and test it, and extra bills for the customer to pay.
This means that a customer has only one address, while an address can belong to many customers. The foreign key will be in the customer table.
So yes, many customers can share an address.