What is a proper way to separate data structure logic from its graphical representation?

It's more of a software design question, than strictly programming, so I'll paste UML diagrams instead of code for everyone's convenience.

Language is Java, so variables are implied references.

I'm writing an app, that helps edit a very simple data structure, that looks like this:

On my first trial run I've included all the drawing-related and optimization code into the data structure, that is, every Node knew how to draw itself and kept a reference to one of shared cached bitmaps. UML:

It was easy to add (fetch a corresponding bitmap and you're done) and remove (paint background color over previously mentioned bitmap). Performance-wise it was nice, but code-wise it was messy.

So on the next iteration I decided to split things, but I may have went to far and things got messy yet again:

Here data structure and its logic is completely separated, which is nice. I can easily load it from file or manipulate in some way before it needs to be drawn, but when it comes to drawing things get uncomfortable.

The classic way would be to change data then call invalidate() on drawing wrapper,but that's inefficient for many small changes. So to, say, delete 1 Tile Id have to either have Drawn representation be independent of Data and call deketeTile() for both separately, or funnel all commands to Data through Drawing class. Things get even messier when I try to add different drawing methods via Strategy pattern or somehow else. The horror:

What wis a clean efficient way to organize interactions with Model and View?