Yes, Data Models and Class Models are virtually interchangeable for capturing Entities and Relationships, so I am a strong believer in "if it works for you, do it".
...but I have some follow-up thoughts and experiences (of course!)
I worked with a development team once that was adamant that a Class Diagram was their model for software design and architecture, and I should not use it for requirements. This was a very object-oriented team, and they were also struggling with how to model persistent data. The key disconnect was that their Class Diagrams usually had the Class of interest, like a Product Order, as the 'parent' to all other Classes, like the Customer who made the order. This made sense from a software viewpoint, as an instantiation of the Order for use in a program only cared about the one Order, but from a database view, you want to know other things, like how many Orders a Customer has made. This led to the definition of data-holder/getter classes that mirrored the data model, and were used to get data from the database. The developers were originally antsy about these classes, as they had no methods of interest, and that felt so wrong to them...but they got past that.
So, I personally avoid Class Diagrams if there can be any confusion about whether they are data diagrams or software diagrams. Further, when I use Data Models (and the local methodology I am using supports this), I clearly move the model through stages of Conceptual, Logical and then, working with the DBA, get to a Physical model. I have found the business people can see this transformation and understand why it is done, so expectations can be managed.