The key to a refactoring is to not break the interface. A database has a second concern of not losing the data as well. If your sql server database is primarily tables, you can assign the actual tables to a different schema (probably one that is more descriptive than dbo) and then create a view with the old schema.TableName.
Now you have a way to buffer changes being incrementally made to the application from the old to the new system.
Example: Unused field elimination.
Start with the part(s) of the app that modify data. If this field has no modification code, you can drop the field from the table (the one with all nulls), but in the view:
Select Null as OldFieldName from NewSchema.OldTableName;
I consider this view, to start being self-documenting code. If you're going to start documenting column names, why not start the process of giving them meaningful names?
Example: Rename Column
It wouldn't be that difficult to rename the column in the table, but maintain the old name as an alias name in the view.
Select NewColumnName as OldColumnName from NewSchema.OldTableName;
No reason you couldn't do the same with tables.
The application can now be incrementally modified to transition from the old table names and columns (The View) to the new table and new columns (unless dropped). The view can then be dropped with the code in your source control history if anyone wants to see what the old table looked like.
Moving columns to a different table can be handled in the view, but with sql server a view is not considered updatable, if it attempts to modify data in more than one table at once. One way around this is to keep the old column, but put a trigger on the table to automatically copy any data from this column to the new column in the other table. After all the app code has been modified to use the new column, the old column and the trigger can be removed.
Remember, there's more to the database than the schema, so you have to account for data changes as well.
Taking responsibility for your database without breaking how it is being used is a tough job. I think this method gives you the change to have more control and understanding of the database as you give things appropriate names and coordinate a strategy with the dev team to get rid of things you no longer need.