Sure, but you probably don't want to.
Just to get some terminology straight: As you say in the question, hash tables are commonly used to implement mappings. A thing that implements a mapping is commonly called a map. Depending on the programming language that you are writing that thing in, a map might be an abstract data type, a class, or something similar. (For example, in Java, java.util.Map is an interface.) Since I don't know what language you're in, I'll just say ADT/class. Since you're asking about using hash tables to implement things other than mappings, I assume we're defining "hash table" as the raw data structure with the buckets, not a higher-level abstraction that limits you to map operations.
Nothing prevents you from using hash tables to implement things other than mappings. It's just that mappings are what hash tables are good at.
You say you want to implement a relation, which is defined as a collection of ordered pairs. The obvious way to implement that would be to make an ADT/class to represent an ordered pair, then store instances of them in a set, assuming you already have an ADT/class to represent a set.
But you are right that there is overlap between that and a map implemented using a hash table. As you know, hash functions have collisions in the general case, so code that implements a map using a hash table has to store a set of (key, value) pairs for each hash code (or for each bucket, to be more precise). And if (let's say) "find me all the elements in T that are related to a given element in S" is going to be a common operation it might make sense to implement a relation using a hash table, as you describe. The trick is, the code for that findby(s) operation will have to return a subset of the (key, value) pairs in the bucket where key = s, in contrast to a map (which would return the first and only (key, value) pair where key = s) or the raw hash table itself (where the bucket is a collection of (key, value) pairs where truncate(hash(key)) = truncate(hash(s))).
The problem is, other operations like "find me all the elements in S that are related to a given element in T" are going to be more difficult. And getting the semantics of a relation right will be hard enough without dealing with the idiosyncrasies of hash tables.