DSXchange

The database schema is usually defined using a job parameter so that the value can be changed at runtime. This should be the only place where you need to change anything.

ArndW is probably talking about the schema name in the FROM clause and I think you are talking about each column derivation being fully qualified with the schema.table.columnname. Realistically, this schema string can only be changed two ways once it is imported into a job;
1. Manually in Designer.
2. Export the job into a .dsx and do a global search and replace in your favorite editor.

The Table definition as it exists in the repository is NOT dynamically linked to any job. Changing one will have no effect on the other. Usually when importing Table definitions, I do not fully qualify the table names to avoid the problem you are experiencing.

1. I usually import via the Table definitions => Import => Plug-in Metadata Definitions as I am currently at an Oracle and Teradata Server shop. You might not have this option. After connecting to the database, there is a checkbox for Fully Qualified Table Names. I uncheck this box. I also verify the Table definition is correct before I use it in a job and if necessary I would remove/tweak anything necessary for the obvious reason that once it is in the job, it is much harder to effect a change.
2. I never export executables and so don't think I can give a good explanation beyond that I find it extremely valuable, even fundamentally a necessary Best Practice, to compile a job in the environment in which it will run. I think importing executables is for importing into a protected project that is really locked down tight and re-compiling goes against policy.