The main point is not to refactor so much that your model changes beyond all recognition. Even with iterative development you should really be building on top of existing stuff and not refactoring it to pieces.

This gives you 2 main options to handle big changes when they come: the first is to build the DB layer as an API, use stored procedures so they can be changed to suit the client without changing the underlying data schema.

The other way is to replace tables with a bit of data migration. When a large scale change is required, you create the new schema and implement a set of scripts to take the old data and massage it into the new format. It costs time to do this which is why you rely more on cheaper methods of modifying the access to the data (eg via SPs) as a first choice.

So:

1. try to think ahead with design so you don't need to change things.

2. Rely on wrappers or APIs so change is limited or can be hidden inside an isolated component

3. Take the time to upgrade properly if you have to.

These steps apply to everything, not just databases.