Hey all,
James here! I ‘m a senior solutions consultant at Nifty. I wanted to share a real life example of a relational data model diagram. Yes - that sounds boring and complex, but I promise it’s not! And it is an important part of building a scalable solution.
A lot of the time you can just begin by building what you need and feeling your data structure out. Other times you may need a bit more planning, especially if you want to build something scalable that still holds together a year from now. That’s where data modelling comes in.
Ultimately, the purpose of a data model is to visualise and plan your tables. Once you have an idea of the workflows your Airtable needs to address, a data model helps you plan what tables need to exist, and how they relate to each other. Doing a quick data model is a great way to normalize and reduce the amount tables you need, and quicken up the build. Think of it as setting your ingredients out before cooking some complex Ottolenghi dish.
This example shows the foundational data layer for a major broadcaster that creates 29,000+ assets that market 8000+ games a year.
- Games (Chelsea vs Man United) relate to a Season (EPL 2026) which relate to a Property (EPL)
- Each Task (e.g. TV Graphic or IG reel) relates to a Game
- Each Task is briefed and completed by the various marketing teams
- Each Task and Game is synced to Dates - the universal broadcasting calendar
- Every Team consists of Players who are related to Seasons and Games
- All Tasks and Games and Seasons roll up to reporting dashboard for leadership to review
This visualisation practice helped me simplify the data model (reduce the amount of tables to manage) whilst also ensuring it could combine the work of 8 different teams in a scalable way.
Highly recommend giving it a go!
Curious if anyone here has done this for their builds?
