Think about behavior, not data

Databases are implementation details! Considering the database should be deferred as long as possible. Far too many applications are inextricably tied to their databases because they were designed with the database in mind from the beginning. Remember the definition of abstraction: the amplification of the essential and the elimination of the irrelevant.

Robert C. Martin, "The Payroll Case Study: Iteration One Begins", in Agile
Software Development: Principles, Patterns, and Practices, 194.

The point is that, as far as the application is concerned, databases are simply mechanisms for managing storage. They should usually not not be considered as a major factor of the design and implementation. As we have shown here, they can be left for last and handled as a detail. By doing so, we leave open a number of interesting options for implementing the needed persistence and for creating mechanisms to test the rest of the application. We also do not tie ourselves to any particular database technology or product. We have the freedom to choose the database we need, based upon the rest of the design, and we maintain the freedom to change or replace that database product in the future as needed.

Sometimes the nature of the database is one of the requirements of the application. RDBMSs provide powerful query and reporting systems that may be listed as application requirements. However, even when such requirements are explicit, the designers should still decouple the application design from the database design. The application design should not have to depend on any particular kind of database.

Robert C. Martin, "The Payroll Case Study: Implementation", in Agile
Software Development: Principles, Patterns, and Practices, 249.