Data Models and Data Quality

Wrong data, however fast you retrieve it, is still a wrong answer

Part 6 of 12 in "Databases for Non-Developers". This part covers a problem no database choice lets you escape — what goes inside the database. It is also the heart of the entire series.

---

One customer can show up as three different people in a system. The first order says "Jaehee Song," the second says "Song, Jaehee," and the third was entered with a different email address. Conversely, two different people with the same name can get merged into one.

No matter how fast and reliable a database is, if the meaning and standards behind the data are unclear, it won't lead you to sound decisions.

Garbage In, Garbage Out — put garbage in, and garbage comes out

One of the oldest sayings in computing history is GIGO (Garbage In, Garbage Out). Passed down since the 1950s, this simple phrase still proves true again and again.

Feed bad data into a system, and even the best system will produce bad results.

One fact must be stated here above all. A database is storage, not truth. A database never judges for itself whether data is accurate. It only checks whether the format is right. If a birth date field receives a wrongly typed date in the correct format, the database will faithfully store that wrong date, retrieve it quickly, and back it up perfectly. The system works flawlessly — and the content is still wrong.

So "managing a database well" actually means two different things at once.

1. Managing the container — performance, backups, security, failure response (the topics of Parts 1–5 and 9–11)
2. Managing the contents — whether the data is accurate, complete, consistent, and up to date (the topic of this part)

Most organizations invest in the first while neglecting the second. The result: "wrong data, stored fast and safe."

What GIGO actually costs you

• Tens of thousands of direct mail pieces sent to wrong customer addresses → total loss of printing and postage, plus damage to brand image
• Retention analysis that fails to recognize duplicate customers as the same person → wrong marketing budgets built on the illusion that "customers are leaving"
• Revenue data with mixed currencies (KRW/USD) → executive report numbers corrected only months later
• Automated purchasing running on stale inventory data → stockouts and overstock happening at the same time

The scary thing about bad data is that it doesn't look scary. A server failure sets off alarms, but data contamination is silent. Decisions pile up on contaminated numbers until someone finally notices something is off. And as we'll see in Part 12, this problem gets amplified in the AI era — because AI hands bad data back to us far faster than any human, in far more convincing sentences.

A data model is a map of reality, redrawn

A data model is the design that decides which items and relationships will be used to record real-world people, things, and events. Just as a map doesn't draw every tree and stone, a data model doesn't contain everything in reality. It selects what the purpose requires.

For an online learning service, you might distinguish users, courses, enrollments, payments, and progress. And here, important questions arise.

• Can one user take multiple courses?
• Should a refunded enrollment be deleted, or just have its status changed?
• Should progress store only the last position, or the full learning history?
• How should parent and student accounts be distinguished and linked?

These questions are closer to business rules than to technology. That's why data modeling is not just for developers. If the people who do the actual work aren't involved, the system ends up drawing a map of a different business — and every report and decision gets made on top of that map.

The six criteria of good data

Data quality isn't judged by accuracy alone. It's usually assessed on six criteria.

Accuracy

Does it match reality? Addresses, balances, and birth dates must correspond to the real thing. Bad example: sending an important notice to an address the customer left two years ago

Completeness

Is anything needed for the business missing? This doesn't mean filling in every field — it means checking that the items required for the purpose are there. Bad example: 40% of customers have no contact channel on file, so they're left out of marketing targets

Consistency

Do all systems use the same meaning and values? Bad example: one system says "active customer" while another says "paid user," each applying a different standard

Timeliness

Is it fresh enough when it's needed? Bad example: taking today's orders based on yesterday's inventory numbers

Uniqueness

Is the same subject duplicated unnecessarily? Bad example: like the customer in the opening, one person existing as three different IDs

Validity

Does it follow the defined formats and rules? Bad example: "unknown" typed into a phone number field, or a date that doesn't exist

Managing quality means turning these criteria into measurable indicators (like "mandatory-field omission rate below 5%") and establishing procedures to fix anything that falls short.

Quality problems often start at the input screen

If you let users type freely and expect clean statistics later, you're in for a rough time. When "WA," "Washington," and "Wash. State" all come in, someone first has to normalize them into one value. Input design — dropdown lists, date pickers, address confirmation, duplicate warnings — has a huge impact on data quality.

If the constraints from Part 2 are the checkpoint at the door, input screen design is the signage that keeps people from getting lost in the first place. That said, forcing every input into rigid limits can hurt usability or fail to capture real-world exceptions. The key is splitting structured, required fields from free-form descriptions in the right proportion.

Prevention is cheaper than cleanup

Once bad data has piled up, cleaning it is hard because the original meaning may be impossible to verify. The person in charge may have left, or the source documents may no longer exist. These preventive measures help:

• Write down definitions and input examples for important fields
• Define the list of allowed values and how exceptions are handled
• Agree on the criteria for detecting duplicates (name? email? phone number?)
• Decide who is allowed to edit what
• Establish a procedure for reporting and fixing quality problems
• Keep a path for human review of automated check results

There's one rule of thumb. The cost of a data error grows the later it's discovered — if it's 1 at the input stage, it's 10 at the reporting stage, and 100 once it's influenced an executive decision. That's why "we'll clean it up later" is the most expensive choice you can make.

Where is the "source of truth"?

If the same customer information lives in the CRM, the payment system, and the email tool, which one is the standard? You don't have to cram all information into one system, but you do need to decide on a system of record for each item. Payment status comes from the payment system; marketing consent comes from the consent management system — that kind of thing.

If no source of truth is defined, you can't answer the question "so which number is right?" And an organization that can't answer that question will find its data — for analytics, for AI, for anything — hard to trust.

Key takeaways A data model is a map of reality drawn to fit a purpose, and data quality covers not just accuracy but completeness, consistency, timeliness, uniqueness, and validity. A database is only a container — it guarantees no truth. Garbage In, Garbage Out. Quality is not a cleanup job for later; it must be prevented through definitions, input screens, and business procedures, and errors get more expensive the later they're found.

Questions to think about

• Which numbers cause the most arguments in our organization?
• Are the terms and formulas behind those numbers documented anywhere?
• What is the system of record for customer, product, and employee information, respectively?
• When did we last measure the quality of the data in our database?

Next: the roles and rules for managing data well — data governance. How to make good data a matter of system, not luck.

---

Series contents

1. What Is a Database — How Is It Different from an Excel File?
2. How Databases Protect Accuracy
3. What Kinds of Databases Are There?
4. Databases, Data Warehouses, and Data Lakes
5. Why Choosing the Right Database Matters
6. Data Models and Data Quality ← You are here
7. What Is Data Governance?
8. Personal Data: Less Is More, Only What You Need
9. The Basics of Data Security
10. Why Do Data Breaches Happen, and What Should You Do When One Does?
11. Cloud and Serverless Databases
12. Databases in the AI Era