Осилил...
Но так и не понял - какую функциональность обсуждаем.
Исходная задача стояла (если я правильно понял): по некоторому набору сущностей выдать SQL-запрос, возвращающий все их поля, объединив все эти таблицы (и возможно промежуточные их связывающие).
В силу ряда неучтенных при постановке задачи факторов (названия полей, множественные связи, циклические ссылки и др.) задача перестала быть понятной вообще.

Автор темы пытается решить задачу методом создания некой э... библиотеки чтоли, используя которую можно было бы методами ООП организовать построение требуемых запросов.

Т.е. в процессе программирования, например этого:
автор
builder1.addColumn(Person.NAME.name(), V_Person.PR_NAME.name());
builder1.addColumn(Person.AGE.name(), V_Person.PR_AGE.name());
builder1.addJoin(Person.WORKPLACE1_ID.name(), Tables.WORKPLACE1_VIEW.name());
builder1.addColumn(COL_ID, V_Person.PR_1_ID.name());
builder1.addColumn(Workplace1.TYPE.name(), V_Person.PR_1_TYPE.name());
builder1.addJoin(Person.WORKPLACE2_ID.name(), Tables.WORKPLACE2_VIEW_JOIN.name());
builder1.addColumn(V_Workplace2.W2_TYPE.name()+"||"+V_Workplace2.W2_TYPE.name(), V_Person.PR_2_TYPE.name());
builder1.addColumn(V_Workplace2.W2_SIZE.name(), V_Person.PR_SIZE.name());
builder1.addJoin(Person.WORKPLACE2_TWO_ID.name(), Tables.WORKPLACE2_VIEW_JOIN.name());
builder1.addColumn(V_Workplace2.W2_TYPE.name(), V_Person.PR_2_TWO_TYPE.name());
builder1.addJoin(Person.OTHER_PERSON_ID.name(), Tables.PERSON_VIEW.name());
builder1.addColumn(Person.NAME.name(), V_Person.PR_OTHER_NAME.name());
String sql1 = builder1.build(Tables.PERSON_VIEW_JOIN.name());

Автор собирается продумывать - а что ему на самом деле нужно! Т.е. какие данные (поля и колонки) ему нужно получить конкретно в этом месте.
Причем, замечу, пишется код клиента (я не ошибся?)
Т.е. вряд ли этот код постоянно будет правиться, только при изменениях БЛ (ну и баги конечно).

Возник вопрос: А зачем все это нужно?
Варианты ответов:
1) Автор плохо дружит с SQL и хотел бы придумать ему замену, то это одно.
2) Автор хочет используя какой-то инструмент себе (разработчику) облегчить жизнь по формированию простых запросов.
3) Автор придумывает инструмент для пользователя

я все варианты учел?

1) Дело не благодарное и никому, в том числе автору (если он еще этого не понял) не нужное
2) Автор мог бы воспользоваться одним из многих построителей запросов или написать свой. Либо - см. далее, т.к. программист - он тоже немного пользователь :))
3) Тут все зависит от интерфейса. Вариантов можно навыдумывать много.

Предложу следующий (с кучей проблем, но простой):
На экране слева - дерево, справа - результат (либо данные запроса, либо SQL-запрос, либо - оба)
Дерево - на первом уровне содержит сущности. Открывая сущность T1 видим все ее поля. Можем включить поля в запрос. Для FK-полей - можно раскрыть - увидев поля связанной таблицы, которые тоже можно включать или нет, но можно снова раскрыть ее FK-поля и т.д. Проблем с вложенностью циклических запросов - нет, т.е. сколько нада - столько открываем.

Уточнения:
1) Сущности: результирующий запрос будет включать в себя все сущности от первого уровня - до сущности самого нижнего уровня (в каждой ветке), поля которой включены в запрос.
2) Связи: Со связями вопросов не возникает - они строятся по дереву, между конкретными полями конкретных экземпляров сущностей
3) Список полей в результате: все "отмеченные".
4) Именование сущностей (алиасы таблиц): При выборе полей из данной сущности или "нижних" - проверка на уникальность экземпляра. В случае нарушения - переименовать в уникальный, спросить у пользоватея в конце концов.
5) Именование полей (алиасы полей): При выборе полей - проверка на уникальность имени (алиаса). В случае нарушения - переименовать в уникальный, спросить у пользоватея в конце концов.
6) Вычисляемые поля - это такое же поле в списке, как и все остальные (метаданные нужно создавать под результат)

Результат:
Что делать с результатом - решать тому, кто использует.
- Программист может сформировать VIEW, ХП, просто скопировать запрос, сохранить в XML или еще куда.
- Пользователь что-то будет делать с данными (аналитика, печать? и т.д. и т.п.)

Что для этого нужно:
1) Репозитарий метаданных (+инструмент по его формированию)
2) Руки - для програмирования, немного мозга - для фантазии по развитию темы
3) Пиво