In ER Modeling, relationships/associations are on entities. In the relational model, relationships/associations are on values. (Many so-called ER diagrams don't actually show entities & relationships, but instead show their tables.)
Binary relationships have cardinalities. A table represents a relationship. Eg the relationship Sent(sender, message) "user sender sent message message". Which is 1 to many because each sender in it is paired with 1 or more messages in it. Eg the relationship Received(sender, message) "user receiver received message message". Which is 1 to many because each receiver in it is paired with 1 or more messages in it. Sometimes one relationship can be expressed in terms of others. Eg you have relationship Message(sender, message, receiver) "user sender sent message message to user receiver"; it is Sent(sender, message) AND Received(sender, message). It's non-binary; it doesn't have a binary cardinality; it has those other two binary relationships/cardinalities associated with it.
Eg: For "User to Message" where "a message row is linked to two rows in the user table" you seem to mean the relationship Involved(message, user) "message involved user user". In terms of the first two relationships, this is Sent(user, message) OR Received(user, message). In terms of the ternary relationship it's "FORSOME receiver, sender (Message3(user, message, receiver) OR Message3(sender, message, user))". It is 1 to 2 because each message in it is paired with 2 users in it.
Tables (base variables or query results) hold the rows that satisfy their relationships. A base table's rows are returned by a query that is its name. Relationship builders like AND, OR, FORSOME, renaming etc get their rows calculated by relation operators like JOIN, UNION, PROJECT, RENAME etc. Eg Involved is calculated per its first predicate expression above by the relation expression (RENAME sender\user Sent) UNION (RENAME receiver\user Received). Is there any rule of thumb to construct SQL query from a human-readable description?
FK (foreign keys) constraints get called "relationships". (But they are not.) They also get called "links". Each is associated with a statement expressible via its source and target tables' relationships. A FK is from a table column list to a table column list that forms a CK (candidate key). It says values in the first appear in the second. This happens when if a value satisfies the source table's relationship then it satisfies the target table's relationship. Eg for you, if sender sent message to receiver then sender is a user, and receiver is a user; so there are two corresponding FKs to User, one from {sender} to user and one from {receiver} to user. A FK from a first to a second table is many to one. (The cardinality of a certain relationship per its tables & lists.)
There are extended ways to talk about cardinalities. (Eg "0-or-1" to whatever. Eg look-here vs look-across.) When there are non-binary relationships there are generalized ways to express cardinalities. (Eg 1-to-M-to-N.) Methods account for SQL NULL cardinality 0 in different ways. Just as with tables, these are based on the binary relationship case above. Terminology depends on the modeling/diagramming method/product/style you are using. Find out about yours.
Find some academic textbooks/presentations/courses. The Wikipedia entry on Entity-Relationship Modeling currently isn't too bad. It addresses some confusions/misconceptions embodied by variant methods. Unfortunately most Wikipedia relational model references are poor.
PS I haven't used "model" because sometimes it means class, type, record, table, row, entity or relationship. You have to figure out what someone is saying. You have to make clear what you are saying if you use it.
