And this I think is best not done in SQL/ the relational-data paradigm. It's better to understand the problem in terms that do not tie you in to a specific technology. And once you have a clear picture of what need to be built, then choose persistence tech; if that happens to be SQL, you can then translate your solution to SQL.
In my experience, SQL sorely misses sum-types. So I need to find a way to serialize the sum-types of my domain model to SQL.
They tried teaching us this relational algebra (or whatever you call it) in university but most of it went over my head because it was too abstract. Using weird mathematical symbols. But when we started writing actual SQL, all of that made sense to me.
I think it might be easier to see it in action and then go back and understand the fundamentals of how/why it works.
That's the difference between academia (like to make simple things look complex -- but very correct in wording/modelling/approach) and engineering (like to make complex stuff look easy -- sometimes cutting some corners).
In my experience, SQL sorely misses sum-types. So I need to find a way to serialize the sum-types of my domain model to SQL.