You can effectively alias a table to another table by creating a view which just does SELECT * from the other table. This is however, not a good thing to do:
- It confuses future code maintainers by having a view which is really another table (They can of course, look at your view in the source code**)
- It is possibly inefficient in some cases in the optimiser
- It is not the right way of refactoring things.
However, depending on how easy it is to test those "50 scripts" and how critical they are (Hint: very critical code which is difficult to test can put a real brake on effective development), creating the view MIGHT be a pragmatic thing to do in the short term (And short term solutions generally stay in place for years, or forever, in real applications).
I urge you, if it is in any way feasible, to change the "50 scripts" and carry out all the testing necessary to release such a change. In our team we have carried out changes (in a single release) which modified a lot more than "50 scripts", but testing did of course prove challenging (or at least time-consuming).
As applications become larger and more complex, regression testing becomes more difficult. It is vital to think about it as much as possible, because refactoring WILL become necessary (assuming the app gets developed or maintained AT ALL), and because regressions are bad.
** All your tables, views etc, ARE scripted and in your source code management system, of course!