Initially he makes it sound like there is no translation into a different model but at the end of the article he takes it all back and for good reason:
Also it's important to keep a good decoupling between the events and the model structure itself. It may be tempting to come up with some automatic mapping system that retrospects on the event data and the model, but this couples the events and model together which makes it difficult to migrate the model and still process old events.
So, you're right that he doesn't envision a translation to a relational model but it's not just object structures either.
Right, but the event system in question could be built up nicely in a couple of hours most likely, and the level of "translation" would be minimal compared to OR mapping - no columns/rows/joins/tables/anything else like that.
With such an application I'd probably still be writing the events themselves to a relational database for archiving and potentially sending out report-oriented data as well. I'm not sure how all of that would work out re: ultimately the whole app needs to be stored in an RDBMS anyway for various reasons but it seems interesting to try.
Also it's important to keep a good decoupling between the events and the model structure itself. It may be tempting to come up with some automatic mapping system that retrospects on the event data and the model, but this couples the events and model together which makes it difficult to migrate the model and still process old events.
So, you're right that he doesn't envision a translation to a relational model but it's not just object structures either.