Depends on how ugly it is, and how much control you have over the design and what interacts with it. I've had to interact with a number of ugly databases over the years at my current job, and here's how I've dealt with them:
There's the database that hold employee data. Its a vendor database, so I have no control over it. (Un?)fortunately, I don't have direct access to it. I get a DTS dump every morning.
Best I've been able to manage is to write a script that scrubs the input from the morning dump (yes that word choice was intentional) and migrate it into a more useful format, and work from the scrubbed data.
Even if I could change it, I probably wouldn't - only because there are a large number of other programs that rely on it being set up the way it is, and I can't force a change in them.
Online Training Data
This was a mess of my own design. I built it fresh out of college with no mentor to help me... I've since been fixing it a little bit at a time. Since I control the only program that accesses the data, as I upgrade portions of the site I'll "upgrade" the configuration of the database. I'll write a transformation script and test it vigorously on a copy so I can ensure that all the changes that need to be made get made.
Its been a long process, but its coming along nicely.
Classroom Training Data
My pilot project has been integrating data from 3 different databases, all designed slightly differently by my predecessor... who was a nurse educator that took a programming class or two.
That's been another slow process. Since I have full control over the programs that access the data, I've been changing it bit by bit like the online training data.
In retrospect, this would have been a prime candidate for starting clean... hind sight is always 20/20.
In the End...
I don't know how helpful this has been, and I can elaborate more (to a point, company legal yada yada and all). The final answer is "It Depends".