Спасибо за отсылку к South.
Однако, насколько я понимаю, он также служит целям трансформации изменений модели классов в схему БД, а также создания процедуры миграции со старой схемы БД на новую. Также, как я понял, вопросы применения различных стратегий трансформации остаются на стороне пользователя, а перенос изменений из схемы БД в структуру классов не предусматривается (осмотрел очень бегло, так что, возможно, неправ).
Информация, необходимая для принятия решений о той или иной стратегии трансформации, как Вы верно сказали, будет иметь вид метаданных. Однако, при грамотном подходе и реализации механизма принятия решений это позволит более-менее сносно трансформировать модели различными способами и не приведет к созданию большого количества метаданных.
По крайней мере можно использовать показатели, характеризующие использование тех или иных структур данных (насколько часто данные извлекаются, модифицируются и т.п.) — я думаю, этого будет вполне достаточно.
Что касается вопроса об изменениях в структуре классов, то, разумеется, если использовать текстовое представление модели, то будет сложно понять, что же произошло. Использование визуального редактора, по крайней мере, поможет различить операции переименования и создания/удаления. Кроме того, этот вопрос важен лишь для данных в БД, но не для самой схемы БД.