I would suggest considering ORM classes as only having responsibility for representing the shape/structure of underlying database records (from tables, but potentially also views/queries/stored procs/etc) rather than trying to include any behaviour in those classes.
Database persistence and Object-Orientation seek radically different goals and therefore require fundamentally different ways of thinking, so instead of thinking about coupling, I'd suggest avoiding the trap of mixing these mindsets together. That is to say, by avoiding including those methods you describe within the ORM classes, concerns around coupling should cease to matter.
The reason loose coupling is preferred in the Object-Orientation mindset is that it allows methods/behaviour to be replaced, overridden or mocked -- this is an important goal for OO because it implies testability, extensibility, flexibility, code reuse, and coherent structure for the behaviour of a program.
For classes which have only data and no methods, coupling generally stops being a useful concern, where the goals of 'OO' are either non-applicable or already satisfied by virtue of lacking any methods.
In the database persistence mindspace, the closest equivalent to coupling would be relationships and constraints between tables, which are typically a good thing because they guard the integrity of the underlying persisted data.
From an application perspective, methods which perform queries would typically exist in separate classes instead; rather than adding methods into the same classes which represent underlying records. This would often be achieved using patterns such as Repository or Data Access Object (DAO), for example:
class UserRepository {
public function getUsers($groupId) {
// TODO - query and return list of users for $groupId
}
}
class GroupRepository {
public function getGroups($userId) {
// TODO - query and return list of groups for $userId
}
}
