Event Data Modeling, Part 2

A Quick Guide to Modeling Event Data

Here’s Part 2 of Event Data Modeling. Part 1 is here.

This is a quick guide to event data modeling. The main takeaway is to think of data modeling as a process for continuously flowing data. This approach differs from modeling data for database tables, and I’m guessing some of you might be uncomfortable with this shift. But, given how ubiquitous events are in almost every technology you use today, they’re inescapable.

I have a few other parts I’d like to add to this chapter, but I need to mull them over for a bit. This chapter (Parts 1 and 2) is already 20 pages long, so length is also a consideration.

As always, comment where you wish. If you find errors, please submit them here.

Thanks,

Joe

---

Modeling Event Data

Modeling event data is similar to what we’ve covered so far in this book. As with all data models, you’re modeling something that needs to represent something in the business, using the business’s vocabulary. That said, there are some important departures from traditional modeling, mainly in how you need to think about and structure your events, and the performance impacts of these decisions.

Event-First and Entity-First

Earlier, we discussed how events are not just about “what is” but about various other things. An event can describe what happened, when it happened, what caused it, who did something, and so on. This differs from the entity-first approach we’ve seen throughout this book. When you model events, you have two options: event-first and entity-first.