Single responsibility principle and building a tree of objects

Let a class Rel denotes a kind of SQL relationship between two tables (that is Rel may be HasA or HasMany, etc.)

Will it contradict single responsibility principle ("class or module should have one, and only one, reason to change") if instance objects of this class will be also nodes of a tree of relations of SQL tables? A node would include table name, list of fields for a SELECT query, etc.

I think, it will, because both modifying tree structure (say adding possibility to add ORDER BY to subqueries in the tree) and modifying the relation (say allowing/disallowing NULL relations) are reasons of change.

Then if it is a violation of single responsibility principle, I assume that relations should have class methods only and the nodes of the tree (each node having a table and a list of fields to retrieve from SQL) should be mere parameters of the methods, not objects or classes on its own. Right?

However, with nodes of the tree being instances of relationships classes, the syntax is short:

$Node->unfoldWHERE() (to return the WHERE part of an SQL query build from the root node $Node of our tree)

If $Nodes are no more objects of this class, this function call could become longer:

$Node->{CLASS}->unfoldWHERE($Node) (here the field CLASS is a reference to a relationship class, or in languages not supporting passing a class, an object of this class)

Is there any way both not to break basic OOP principles and make this code short and easy to understand?