How to represent foreign key in an ER diagram?

Many years later, please mind the different notations of ER diagrams, the question is thus not precise enough.

Have a look at all answers at

https://stackoverflow.com/questions/48191228/is-erd-considered-a-kind-of-uml-diagram#48198083

and

Which one is an ER diagram?. One answer here even states that the Chen notation is the ERD, while Crow Foot notation is said to be an EAD (Entity Attribute Diagram), see @JoshuaGuttman.

The Chen notation does not show explicitly the FK relations, as the accepted answer already explains, while other notations can do this.

If you take for example the Crow Foot or Baker's notation instead, you might take the "most precise" answer of @dlink where the lines lead exactly to the FKs. Then it is still unclear what to do with composite FKs leading to composite PKs, and probably because of that, professional programs simply do not graphically link the line endings with the FKs. Then, naming is all you can refer to, which is enough anyway if you keep strictly to a naming convention (like CustomerID to Customer.ID, or other rules). See for example Visual Paradigm at https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagram/

I prefer this format, using "crows feet" to illustrate the many-to-one joins

This page, by LucidCharts has a nice write up on how ERD should look.

Under Physical ERD Symbols, it shows how to represent keys.

[https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning]

When drawing ER diagrams, I have used the following graphical convention: Label the relationship lines with the foreign key column name(s), like so:

This makes it clear which column in the child table is the foreign key to the parent table. Indicating primary key status can be done by underlining the attribute in question.

What may be more useful than this is a naming convention that makes it clear what is the primary key of a table (easily done if you use surrogate keys by convention) and what is a foreign key column.

Some relational model diagrams also include a key participation label to the left of the column names in the list of columns (e.g. "PK", "FK1", "FK2",...) which can help especially if you have composite keys.

ER Diagrams were originally used only to represent the ER model. The ER model does not use foreign keys to represent relationships. It uses lines between boxes. The lines have some kind of indicator for cardinality at either end or both ends. Sometimes, a relationship will be indicated separately by a diamond.

Today, more than half of the ER diagrams floating around are really diagrams of a relational model, and not of an ER model. A relational model has the foreign keys included in the tables, and these serve to implement the relationships which the ER model identifies. And a relational model will have an extra table, often called a "junction table" between two entity tables that are linked by a many-to-many relationship. This junction table contains two or more foreign keys.

There are many ways to represent a relational model. Perhaps the simplest is the "Relationship Diagram" that MS Access can produce from a completed database. This will be fairly complete, if the database builder has identified the foreign keys.

There are many tools that are more sophisticated than MS Access for making diagrams on a larger scale. Some of these are used before building the database. Some are used after.