As with most of the code I have refactored over the years, the database refactorings I've done involved mostly stored procedure code that needed to be decomposed into more focused chunks, decoupled, generalized (introduce parameters, extract constants), and clarified (rename variables).
If you have a good DBA and/or database designer and relatively well-defined entity-relationships, then you probably have a decently normalized database design that is amenable to changes. Adding columns to an existing table is usually a trivial exercise when you have a normalized database. Other kinds of changes may require you to write some data migration scripts but those are usually straightforward if you have a normalized db. Just like the problems posed by duplication and tight coupling in code, a poorly normalized database hinders your ability to make changes and
you should try to address those kinds of issues first.