Hi Docformat!

Here is the approach that I take when deciding how to deliver a data model.

1. Does the team with have a preference?  If you are equally familiar with both techniques...use the one that will help communicate with the least amount of explanation to the audience.
2. Is there an anticipated delivery platform?  Allow physical platform for implementation to influence the choice of modeling technique.  If you are implementing through an object oriented database, the OO model might be more easily translated.
3. Is there particularly gnarly data requirements?  If so I'd suggest that you use ER modeling purely because it is a more mature technique, use it to design your 'data at rest" or static data storage.  Then elaborate in specific OO models for the "data in motion" ...but blend that with a DFD to get a stable understanding of the scope/context/impact of the data flow changes.

Hope this helps!

Loretta

For me,  a data model is the shorthand that I use to document what I hear about data requirements.  I create the model in the "scribbles" in my notes from the very first meeting I attend.  Modeling is an activity, that starts in my head...then translates to paper or a white-board, and finally gets formalized in a tool.

My suggestion is to start modeling with the first word...model the way that makes the most sense for you.  Let the problem domain drive the decision of the initial technique that you use.