I've found it best to always start by sketching out a logical domain model. This sort of model is independent of the implementation and focuses on identifying key concepts and their relationships. Eric Evan's "Domain Driven Design" is a great reference for this.
The next step is to design the implementation model. For this, a good rule of thumb is to determine the interface that clients will be using to interact with your model and start there.
For example, if you're building a new OLTP system using an ORM-based framework (such as Rails or Grails), your services and controllers will interact with the model using the ORM interface. Because of this, you'll want to start with designing the object model and let the data model follow from that. ORM frameworks each have their own preferred ways to model object-oriented concepts at the database level and following the framework's preferred way will be faster and less buggy. If you design the data model first and then map it to the ORM framework, you may end up having to jump through hoops to get it to work properly.
On the other hand, if you're building an OLAP system backed by a Kimball-style data warehouse, there will likely be a variety of clients accessing it, such as custom apps and BI tools. A common interface to use in this case is direct SQL access. It provides great flexibility and allows clients to leverage the full power of the database. So in this case, you'd want to focus on the database design first.