You need (preferably automated) integration / system tests too, apart from unit tests, precisely to verify that changes like your example don't break existing - seemingly unrelated - functionality in your system as a whole.
UI testing is much more difficult than unit testing, but there are tools which can help at least somewhat. For web pages, e.g. HttpUnit or Selenium are recommended by many. If you tell more about the type of your system, we may be able to give more precise advice.
An intermediate path may be to write subsystem tests, which are technically like bigger unit tests, possibly involving the DB too. DbUnit is a tool which can help you in this. Subsystem tests may allow you to verify dependencies / assumptions like the one you describe, so that if you change the data source of table T, some test for code X will fail, forcing you to update that code too.
The underlying problem is that you apparently don't understand how your system works. This is sadly common for legacy apps, but your descriptions seems to suggest that this system has been built by your team from the start - in which case there is a fundamental problem with the way you work. You must absolutely learn to document dependencies within your system - and you must also work on reducing and controlling these dependencies. Pay attention to coupling and cohesion in your architecture, in order to divide your system into independent modules/components which only affect each other in well defined ways.