One way is to design your models before you design your database. When designing your models, the focus is on capturing the business logic and meanings within the problem domain. This should be captured in a way which makes sense to the business, including more than just entities and data fields. Some data elements are interpreted from others, some are contingent upon others, etc. Additionally you'd add to this model any basic logic you need, such as how an object internally responds when a certain element is set to a certain value.
It's entirely likely that you'll end up with something that's 90+% identical to how you end up persisting the data. That's fine. It can be completely identical without being coupled.
Note also that modeling the domain in a fog of true persistence ignorance is a bit of a holy grail for software design. If you can do it, fantastic. But if the problem domain is at all significant and has any complexity to it then it's still a good idea to step back from the domain modeling from time to time in order to do a sanity check on data persistence to make sure you haven't painted yourself into a corner.
Just remember the actual roles of the various components and keep those roles separated when you design them. For any given design decision, ask yourself if any of those roles are violated:
- Database - Store the data, maintain the integrity of the data, maintain the data at rest.
- Models - Contain the business logic, model the problem domain, maintain the data in motion, respond to business-level events, etc.
- Views - Present data to users, perform user-side logic (basic validation before true validation is performed in the models, etc.).
- Controllers - Respond to user events, pass control to models, route requests and return responses.