Is having hundreds of tables a sign something's wrong?

Not on its own. Applications often need that many. The problem is when business users are expected to work directly with them. That's what a modeling layer is for.

What is a business entity?

A table that represents something the business actually talks about: a customer, a patient, an order, a product. It combines everything about that thing from the system tables into one place, in plain terms.

What kinds of data tests do you run?

Checks that values are in the expected format and range, that required fields aren't empty, that IDs aren't duplicated, and business-specific rules we learn from your team, like which countries you actually operate in.

Who fixes the errors the tests find?

Usually the team that owns the source data, since fixing it at the source keeps it fixed. Our job is making sure the right people find out quickly.

Your Data Isn't Messy. It Was Built for a System.

Quick answer

A lot of data that looks messy isn't actually wrong. It's organized the way an application needs it, with join tables, lookup tables and IDs, not the way people think about the business. Modeling that data into business entities like customer, patient and product makes it simple enough for teams to use on their own. Adding tests on the way in keeps it honest as people keep entering data.

Key takeaways

Operational systems store data for the software, not for business users. That's not a mess, it's a different purpose.
Modeling into business entities turned one client's 165 system tables into eight tables their team could actually use.
When three teams each reshape the same customer data, you get three answers. Model it once instead.
Tests catch the small data entry mistakes that quietly skew numbers over time, and alert the team while it's still easy to fix.

Messy, or just built for a system?

When a company tells us their data is messy, we usually find something different. The data is fine. It's just organized for the system that created it. An app needs join tables, status codes and lookup tables to run. Business people don't want to see any of that. They want to see customers, orders, patients, products.

We worked with a client whose system had around 165 tables. The first job wasn't technical. It was understanding what actually mattered to the business. Then we joined and summarized those tables into entities the team recognized: customer, patient, product, manufacturing. We ended up with eight tables that directly mirrored how the business works.

Because it was that simple, the team finally had clarity. They could answer their own questions without waiting on an analyst. That's usually what builds a data-driven organization, not more tables.

One model, many reports

When reports point at business entities instead of raw system tables, maintenance changes completely. If the definition of an active customer changes, you update it in the model once, and every report built on it picks it up. You don't go hunting through dozens of dashboards to fix the same logic in each one.

Three teams, one version of the customer

This is also where a lot of process improvement hides. Say three teams all work with customer data. Each one pulls it and reshapes it their own way to get the results they need. Now you have three versions of the customer, and a lot of alignment calls to figure out why they don't match.

What we do: understand the pains and goals of each team, have one or two alignment calls, then model it once and document it. From there, everyone uses the same data. It'll need to evolve, every model does, but once the first version exists, evolving it is way easier than starting from three. This is the same root issue as why your sales and finance teams disagree on revenue.

From the team

Is your data organized for your app instead of your team?

We'll map what your business actually needs and model your data into tables your team can use without a translator.

See how fractional works →

Tests keep the model honest

A clean model only stays clean if what flows into it is correct. Take a CRM. Lots of people have access, and most of them do a good job filling it in. But mistakes happen. Someone puts a country in a field where it doesn't belong. One wrong entry doesn't matter much. A few hundred over a year can skew your numbers without anyone noticing.

So when we bring data into the platform, we test it. We test the main business rules, plus anything we discover along the way. When something fails, the right team gets an alert in time to correct it at the source. If people don't know an error exists, they'll never go back and fix it. We go deeper on how we think about testing in data is water, we're the plumbers.

How to tell if this is you

Business users need someone technical to explain which tables to join.
The same entity, like a customer, is calculated differently by different teams.
You've found data entry errors in reports long after they happened.
Your reporting tool points straight at your app's database tables.

This is what we build

We learn how your business works, then turn system tables into a small set of business entities your team recognizes, with tests and alerts on what comes in. The goal is a model simple enough that people use it without asking for help. See how it works.