Conversion of simple ERD to Table: is the solution below any good?
Looking at Relationship 1 as an example.  The primary key of this table is ID_PhoneNumber and ID_Company.  The CompanyName, however depends only on ID_Company alone.  The table is not in second normal form.  For the design to be normalised it would have to be:

Company (ID_Company, CompanyName)
Relationship1 (ID_Company, ID_PhoneNumber)


The same argument holds for Relationship 2 and 3.

Telephone has only two columns - the ID and the number.  I'd suggest quite strongly that it would be an error to have two rows in this table with the same number.  So a unique contraint on the number would be appropriate.  The ID column, which is the primary key, will have a unique constraint, too.  So we have a table where each row consists of a unique number (ID) paired with a unique number (the phone number).  It seems to me one of these is redundant.  You may choose to retain the ID as a surrogate key since an integer (the most likely data type) will be shorter than a full international telephone number, especially with formatting characters embedded.  Adopting this would give the table

Relationship1(ID_Company, PhoneNumber)


I would be inclined to use call it CompanyPhone at this point.

I know I'm mixing logical and physical arguments.  I'm assuming your intention is to implement a system and not simply derive an abstract model.

One thing I haven't covered, and isn't mentioned in your question, is whether a phone number can relate to a company or an employee or a supplier i.e. are the relationships mutually exclusive.