When I first started this book on data modeling, I felt like the data modeling world was stagnant and tribal. For the past few years, I’ve been giving talks around the world on data modeling, articulating it in various forms. Reflecting on my enthusiasm for combat sports, it finally dawned on me that Mixed Martial Arts already had the template for where the world of data was heading.
This chapter sets the stage for why the old ways of data modeling are failing and officially introduces the concept of Mixed Model Arts (the title of my upcoming book). Let me know what you think in the comments. Your feedback helps shape the final book.
Thanks,
Joe
I grew up in the 1980s on a steady diet of heavy metal, rap, trashy TV, and plenty of combat sports like professional wrestling, Kung-Fu movies, Bruce Lee films, and boxing. Like many kids then, I watched Karate Kid and Bloodsport, wore a Rising Sun headband, and joined my local dojo to learn karate and taekwondo. Soon, I was also wrestling and boxing, toughening my knuckles on my sand-filled heavy bag as I tried to copy Mike Tyson’s close-range hooks, uppercuts, and overhand rights.
Professional wrestling was hugely popular back then, and most people didn’t know it was staged. My dad took me to WWF matches in Omaha to see stars like Hulk Hogan, Randy “Macho Man” Savage, Jake “The Snake” Roberts, and Andre the Giant. I was hooked. My friends and I got way too into it, holding backyard wrestling matches where we jumped off tables, hit each other with chairs, and fought over a cardboard-and-black-Sharpie championship belt. I still have scars from some of those wild matches.
My friends and I also spent hours arguing about which fighting style was best. Was it boxing, wrestling, Kung Fu, Taekwondo, Karate, or maybe some secret style from a mysterious Chinese monk? We always wanted to know who would win. What if Bruce Lee fought Mike Tyson? Could a boxer beat a wrestler? Would karate come out on top? We obsessed over these matchups, each of us sure that our favorite style was the best.
Those arguments finally got an answer in the early 1990s.
The Dawn of Mixed Martial Arts
On November 12, 1993, a group of unusual fighters gathered at the McNichols Sports Arena in Denver, Colorado. The lineup included a Hawaiian sumo wrestler weighing over 400 pounds, an American catch wrestler in a red Speedo, a quiet but skilled Dutch kickboxer, a boxer wearing only one glove, and an American karate black belt known for powerful roundhouse kicks. Each fighter was sure his style was the best. This event, called the Ultimate Fighting Championship (UFC), was a no-holds-barred tournament created to finally answer the age-old question: which fighting style is truly superior?
The result surprised everyone. The boxer didn’t win, even with his powerful punches. The wrestler didn’t win, despite his control on the ground. Neither did the karate or kickboxing experts. Instead, Royce Gracie, a slim Brazilian jiu-jitsu fighter weighing just 175 pounds and wearing a Gi that looked like loose pajamas, came out on top. He didn’t overpower his opponents. Instead, he pulled them to the ground and made them submit with chokes and joint locks they had never seen before and couldn’t defend against. Art Jimmerson, the boxer with one glove, tapped out in total confusion. He had no idea what was happening as Gracie took him down and choked him into submission.
The lesson was clear: the one-dimensional specialist lost. It wasn’t because any style was bad—boxing is powerful for striking, wrestling teaches great body control, and karate builds speed and precision. The problem was that practicing only one style left big gaps. The boxer didn’t know what to do on the ground. The wrestler couldn’t defend against submissions he’d never seen. Each fighter was great in his own area, but struggled outside it.
Over the next decade, fighters absorbed this lesson. The sport evolved from a clash of styles into something entirely new: mixed martial arts (MMA). The best MMA fighters stopped calling themselves boxers, wrestlers, or jiu-jitsu artists. They became all those things, and more. They trained in striking, grappling, and submissions, learning to move fluidly between disciplines as the moment demanded. In MMA, the one-dimensional fighter became obsolete. Today, anyone who enters the octagon knowing only one discipline and thinking it’s superior to all the rest will predictably lose in a brutal and bloody fashion.
Data modeling is living through its own UFC moment. And most practitioners don’t realize it yet.
A Story You’ve Probably Lived
Here’s what this actually looks like in practice. You might have experienced something similar yourself.
At one company, the application team decided to model much of the product catalog as a massive JSON column stored in Postgres. Each product was a rich, nested JSON document containing descriptions, pricing, images, categories, and reviews. For the application, it was perfect—fast reads, flexible updates, no joins required.
The analytics team then needed to build a product revenue dashboard. They tried querying the JSON blob column and discovered that product categories were stored inconsistently—sometimes as arrays, sometimes as nested objects, and sometimes as strings. Prices had different structures depending on when the product was added to the catalog. Review counts didn’t match between the embedded review array and the separate reviews collection. The data engineering team spent three months building a fragile ETL pipeline to extract data from the application database. The resulting dashboard was perpetually wrong because every schema change in the application broke the pipeline.
Meanwhile, the ML team needed product embeddings for the recommendation engine. They built their own extraction pipeline from the same JSON column, making different assumptions about what constituted a “product category” than the analytics team. The recommendations did not match dashboard reports. Customers saw recommendations for products categorized differently from what they’d browsed. Three teams, three interpretations of the same data, three models that contradicted each other. Not ideal…
And this wasn’t just a technical annoyance. It delayed the launch of the personalization engine by 4 months, wasted thousands of engineering hours, and forced the VP of Product to explain to the CEO why their strategic AI initiative was being held hostage by a database decision made two years ago.
The real problem wasn’t that any team lacked data skills. It was that no one in the company could think across all three areas at once. No one was asking, “How does this application model affect analytics later? How will the ML team use this data? What definitions should we all share?” The company didn’t need three separate modeling experts. They needed at least one Mixed Model Artist who could see the big picture.
This is not an isolated story. I see some version of it at almost every organization I work with. The specifics vary, but the pattern is always the same: teams modeling in isolation, with no shared vocabulary, no coherent definitions, and no one connecting the dots across paradigms and data models.
The One-Dimensional Data Modeler
For decades, data modeling has been practiced in silos. Different communities developed powerful techniques for different problems, and each community gradually came to believe that its approach was the right one, or at least the most important one. If you’ve spent any time in the data world, you’ve encountered these camps. You may have grown up in one of them. You might be in one now.
Warning: We are going to move fast in this chapter. I’m going to expose you to the vocabulary of the entire data landscape—from relational theory to dimensional modeling and different types of databases—all at once. If you encounter unfamiliar terms, keep reading. We will dismantle and rebuild each of these concepts in the coming chapters. And if you’re not aware of these camps, their techniques, and the people involved, you’ll get a short introduction here and learn more about them throughout this book series.
Let me describe each group. I’m not criticizing them—each has produced truly impressive work. My goal is to show how working in isolation can create blind spots.
The Relational Camp
The most established school of data modeling traces its lineage to Edgar Codd’s relational model, published in 1970. The relational camp thinks primarily in terms of normalization. Practitioners of this discipline design the schemas for applications, operational databases, and transactions. Their focus is on optimizing for consistent, fast reads and writes while ensuring referential integrity and eliminating data redundancy. High normalization is their goal. And to be sure, it’s a great goal to have.
If you studied data modeling in a university course, you almost certainly learned this approach first. And for good reason. The relational model is the foundation of every relational database that powers applications, from banking systems to e-commerce platforms to hospital records. The techniques are rigorous, time-tested, and deeply connected to mathematical set theory and first-order predicate logic. I find the Relational Camp takes data modeling more seriously than anyone else in the data world—and often for good reason.
But there’s a limitation. Relational modelers can struggle when the challenge changes from “how do I store this correctly?” to “how do I analyze this efficiently?” A highly normalized schema that needs seven joins to answer a simple question might be correct on paper, but it’s a headache in practice. And when the data isn’t structured—like streams of JSON events, collections of images, or lots of unstructured text—the relational model doesn’t offer much help. The relational modeler is like a boxer: strong at striking, but vulnerable when the fight goes to the ground.
The Analytics Camp
In the 1990s, as businesses began to drown in transactional data and needed to make sense of it, the analytics camp emerged. My good friend Bill Inmon advocated the enterprise data warehouse—a centralized, subject-oriented repository modeled in third normal form, then sliced into data marts for departmental use. Ralph Kimball took a different path, proposing the dimensional model: star schemas built around fact tables and dimensions, designed specifically for query performance and business usability. Later, Dan Linstedt introduced Data Vault, designed for agility and auditing in large enterprise environments. Each approach has passionate advocates who will argue its merits at considerable length. There’s the infamous Inmon vs. Kimball wars. And I’ve seen firsthand the emotional attachment people have to their particular analytical modeling approach. They can get heated.
The Analytics Camp made an important discovery: the way you model data for transactions isn’t the same as how you model it for analysis. This changed the field. But it also led to a new kind of tunnel vision. Many analytics experts focus only on fact tables, dimensions, and bus matrices. If you ask them to model a real-time event stream, a graph of relationships, or a set of ML features, they’re out of their depth. The analytics modeler is like a wrestler: strong in their own area, but less effective when the fight stays standing.
The Application Camp
Then we have the Application Camp. The 2000s and 2010s brought the rise of web-scale applications and, with them, a rebellion against the relational and dimensional orthodoxies. Developers building consumer applications at companies like Google, Amazon, and Facebook needed speed, flexibility, and horizontal scalability. They didn’t want to spend weeks designing data model diagrams and getting sign-off from a data modeling committee. They wanted to ship FAST. The NoSQL movement—document stores like MongoDB, key-value stores like Redis, wide-column stores like Cassandra, graph databases like Neo4j, stream processors like Kafka—gave them what they wanted: schema flexibility, developer velocity, and the ability to model data in whatever shape the application required.
These developers model data around access patterns rather than abstract relationships. A MongoDB document might embed an entire order—customer details, line items, shipping information, payment method—in a single JSON object. A normalization purist would recoil, but the application developer can read everything in a single query with no joins. For their use case, it works beautifully.
But there’s a blind spot. Application developers often don’t consider the needs of teams that use the data later. Their models are built for a single application’s access patterns, so when analytics teams need to work with millions of these documents or ML teams need to extract features, the denormalized, app-specific model can get very messy. The idea of being “schemaless” can also be risky: JSON documents can lead to accidental, inconsistent modeling. Without careful planning, you end up with a tangle of nested structures that no one can understand. The application developer is like a kickboxer: quick and powerful, but lacking ground skills.
The ML/AI Camp
The ML/AI camp barely thinks of itself as doing “data modeling” at all. Machine learning, AI, and data science teams work with feature tables, embeddings, vector representations, knowledge graphs, and more. Their models are for a fundamentally different consumer: algorithms. A feature store organizes data for model training and inference. An embedding transforms a product, a sentence, or a customer into a point in a high-dimensional vector space, where proximity implies similarity.
With the explosion of large language models and generative AI, this camp is growing rapidly, reshaping the data landscape in the process. LLMs need structured and unstructured data for retrieval-augmented generation (RAG). AI agents need to navigate data models programmatically, issuing queries and interpreting results without human intervention.
But many ML and AI practitioners have never designed a relational schema, built a star schema, or thought about relational algebra or referential integrity. They are great at building ML models but often struggle with data modeling. An ML engineer who doesn’t understand data grain might accidentally cause data leakage between training and test sets. Someone who doesn’t know about entity resolution might train a model on duplicate records or the wrong data. The ML practitioner is like a jiu-jitsu expert: skilled on the ground, but not always able to get the fight there.
The Knowledge Camp
The fifth camp traces its lineage not to computer science but to the ancient disciplines of library science, philosophy, and knowledge management. For decades, this community was on the periphery of the data world, concerning itself with abstract concepts of meaning, classification, and taxonomy. But in the age of AI, the Knowledge Camp has become one of the most critical forces for coherence. Its practitioners—often called knowledge engineers, ontologists, or information architects—focus on modeling the relationships and meaning of data rather than its physical structure.
Their native tools are the ontology (a formal model of concepts and their relationships), the taxonomy (a hierarchical classification system), and the knowledge graph (which uses nodes and typed, directional edges to connect entities with semantic precision). They ask questions like: What is the formal, business-wide definition of a “Customer”? Is an “Order” an entity, a transaction, or a set of events?
But this group has its own blind spot. For much of its history, it has been very theoretical and struggled to connect abstract ideas to the messy, real-world data in transaction logs and data lakes. A well-designed ontology is useless if the data underneath is inconsistent. The knowledge modeler is like an old sensei: possessing a deep, philosophical understanding of fighting, but historically lacking the opportunity to compete. Now, with the rise of LLMs and AI agents, the sensei is finally stepping into the ring. We’ll see why in Wave 3.
The Problem of Isolation
Each of these camps has developed powerful, battle-tested techniques. The relational camp gives us rigor and integrity. The analytics camp gives us queryability and historical tracking. The application camp gives us flexibility and speed. The ML/AI camp gives us new forms of representation and machine-consumable knowledge.
The problem is that most people in these fields rarely learn skills outside their own specialty.
I’ve seen this repeatedly throughout my career. A data engineer who has never designed a relational model or built an application. A software developer using a key-value store who has never thought about slowly changing dimensions. An ML engineer who has never built a star schema or modeled a business process. A relational purist who dismisses anything that isn’t in at least third normal form. An ontologist who has never built a data warehouse or pipeline. They’re one-dimensional fighters, each excellent within their discipline but vulnerable outside it.
And today’s world doesn’t let you stick to just one discipline anymore.
Consider what a modern e-commerce platform actually requires—the kind of platform we’ll use as our running example throughout this book. It doesn’t fit a single paradigm. It has transactional data in relational databases: orders, customers, inventory, and payments, all normalized, consistent, and governed by strict business rules. It has event streams in semi-structured formats: clickstream data, shopping cart events, notification triggers, and payment webhooks, flowing in real time through systems like Kafka. It has unstructured content: product reviews, customer support transcripts, product images, user-uploaded photos, and marketing copy. It has analytical models: star schemas and dimensional models in the data warehouse, with slowly changing dimensions that track how customers and product categories evolve over time. It includes ML/AI artifacts —product recommendation embeddings, customer segmentation features, sentiment classification models, and fraud detection scores—organized for algorithmic consumption. And it has semantic metadata: product taxonomies, business glossaries, and ontologies that define what “customer,” “order,” and “revenue” mean across different teams—the connective tissue that keeps everything coherent, especially in the age of AI agents.
All this data exists simultaneously, and it all needs to be modeled. Someone who can only think in one way is as unprepared for this as a boxer who’s never learned how to defend against a takedown. The data world now needs Mixed Model Artists.
How We Got Here: Three Waves of Convergence
Over the past several decades, data modeling has seen different disciplines develop side by side, then sometimes clash. Let’s look at the three waves that led us to today.
Wave 1: Operations Meet Analytics (1990s to 2000s)
In the beginning—the 1960s through the 1980s—data modeling and database design were essentially the same thing. You modeled data to store it in a database. The hierarchical model (IMS) came first, followed by the network model (CODASYL), and then Codd’s relational model, which won over the data industry. For roughly two decades, “data modeling” meant “relational modeling,” and the primary consumer of a data model was the application.
Then businesses started asking questions their applications couldn’t answer. How are sales trending quarter over quarter? Which customer segments are most profitable? What’s our inventory turnover rate by region? Transactional databases weren’t designed for these queries. Running complex analytical queries against a production OLTP system would grind it to a halt—and in some cases, bring down the application itself.
The first wave of convergence was born: the data warehouse. Inmon told me he first developed the idea for the data warehouse in 1983 and later published “Building the Data Warehouse” in 1992. Ralph Kimball published the seminal book, “The Data Warehouse Toolkit,” in 1996. For the first time, data modelers had to think across paradigms. The source system was a normalized 3NF database. The target was something different—either Inmon’s enterprise data warehouse (still 3NF but subject-oriented) or Kimball’s dimensional model (star schemas optimized for querying). New techniques emerged to bridge the gap: ETL (Extract, Transform, Load), slowly changing dimensions, conformed dimensions, and the bus matrix.
This change was difficult for many people. Transactional modelers didn’t like denormalization because it went against what they had always been taught. Analytical modelers struggled with messy source systems rife with legacy exceptions and technical debt. The two groups often talked past each other, each sure the other was wrong.
But the practitioners who thrived were the ones who could speak both languages. They understood why the source was normalized and why the target shouldn’t be. They could explain to an application DBA why the warehouse needed redundancy and to a business analyst why the source data didn’t match the reports. They were the first Mixed Model Artists, though nobody called them that at the time.
Wave 2: The Big Data Disruption (2010s)
The second wave hit in the early 2000s and accelerated through the 2010s. The catalyst was the explosion of web-scale data. Google published its papers on Google File System and MapReduce. The Hadoop ecosystem emerged. Suddenly, organizations were dealing with data volumes, velocities, and varieties that didn’t fit the structured needs of relational databases or the batch-oriented paradigms of the data warehouse era.
JSON replaced XML as the lingua franca of data exchange. Event streams replaced batch files. Semi-structured and unstructured data—log files, social media posts, sensor readings, clickstreams, images, audio—flooded into organizations faster than anyone could model them. The three V’s of Big Data (volume, velocity, variety) became a rallying cry, and implicit in that cry was a challenge to the modeling status quo: existing approaches couldn’t handle this.
The response was the data lake: a vast repository where you could store anything in its native format and figure out the schema later (“schema-on-read”). NoSQL databases proliferated, each optimized for a different access pattern. For a while, it looked like traditional data modeling might become irrelevant. Some people explicitly argued this. “Just put it in the lake. We’ll figure it out when we need it.” I heard this refrain constantly during this period.
They were mistaken. The problem wasn’t the technology—Hadoop and object storage are impressive achievements that changed the world. The real issue was thinking that raw computing power could replace the need for data modeling. Data lakes without rules turned into data swamps: huge, confusing piles of files that no one could find, understand, or trust. Organizations that skipped modeling spent more time searching for and cleaning data than actually using it. As you’ll see in Chapter 3, the work you avoid at the start comes back as data debt later, with interest.
But something valuable emerged from this chaos. The practitioners who successfully navigated the Big Data era were those who could think across multiple paradigms simultaneously. They could model structured data in a data warehouse, semi-structured data in a document store, and streaming data in an event platform. They understood that different data forms required different modeling approaches—and that all of those models needed to coexist and connect. The second wave of mixed model thinking was born.
Wave 3: The AI Revolution (2010s to Present)
We’re now in the third wave, and it’s the biggest change so far.