Be aware of the object-relational impedance mismatch (like here).Simply converting the ER diagram into a class diagram, and then implementing your system on top of it is not healthy for the application. This approach tends to create very brittle designs, where behaviour is scattered in many unintuitive places and/or contains a lot of duplication (especially with code trying navigate the object model as if it was the relational model).
The steps below describe a (very simplistic) approach to work around the mismatch, but you can find a lot more about this by searching for the impedance mismatch.
- Start by modelling your objects in terms of the expected behaviour of the system. Here you can use use cases, activity, sequence and state diagrams, if you wish.
- If necessary, use ORM frameworks to skip the "manual labour" of packing/unpacking data in and out of your database, but don't think of these objects as real objects, think of them as just data structures without behaviour.
- Finally, create a simple and thin "bridge" layer between your behaviour-centric object model and your data-centric database model (or ORM framework).
This way the application's code can be organised around the observed behaviour, hence allow you to place the code in the most intuitive places.