A customer wants a new field on the order form — a priority flag, an extra reference number, whatever. It sounds like a five-minute change: one text box, one dropdown. Whoever owns your ERP promises "sure, we'll have it this week," and then the estimate quietly slips into a month of testing and fixes nobody asked for. This is not incompetence. It happens because "the ERP" is never one flat thing — it is three layers stacked on top of each other, and a change that looks like a single click at the top can force changes at every layer underneath.
Three layers, not one system
Database architecture (the ANSI/SPARC model) splits any system like your ERP into three layers:
- External layer — the views and forms that a specific user or application actually sees: the order screen, the invoice report, the dashboard a manager checks each morning.
- Conceptual layer — the logical schema: the full data model of entities, relationships and constraints that describes the business (customers, orders, articles, stock) independent of any single screen.
- Internal layer — the physical schema: how the data is actually stored on disk, which files, which indexes, which block layout the database engine uses to make queries fast.
Why the layers are supposed to move independently
The whole reason for splitting a system this way is so each layer can change without forcing a rewrite of the others. This is called data independence, and it comes in two flavors:
- Logical data independence means you can change the conceptual schema — add a field, split a table, tighten a constraint — without breaking the forms and applications built on top of it, as long as the mapping between the logical schema and those views is adjusted.
- Physical data independence means you can change how data is stored — add an index, reorganize files, move to faster storage — without touching the logical schema or the applications above it at all.
Where "just add a field" actually breaks
In a well-built system, that new priority field on the order form is exactly the kind of change data independence is designed for: add it to the logical schema, adjust the mapping, and the rest of the ERP keeps working. In practice, it breaks this cleanly only when the three layers were actually kept separate to begin with. One field ripples into rewritten queries, re-tested reports, and a reindexed database when:
- The order screen was built with shortcuts that assume the exact shape of the underlying table.
- Other reports already reference that table directly.
- The physical storage was never designed to absorb new fields without a rebuild.
Any one of these turns a five-minute request into the month-long estimate, explained.
The practical takeaway for a workshop is not to chase perfect database theory. It is to ask, before the next "just add a field" request goes to whoever maintains your ERP: does a change like this touch one screen, or does it touch the shared model every other screen depends on? If nobody in the workshop can answer that question with confidence, that uncertainty — not the field itself — is the real cost sitting inside your system.
Nguyễn Hải Minh
I build custom software and data solutions for manufacturing ERP systems, including INFOR, for clients in Germany. As a Staatlich geprüfter IT-Techniker (Fachrichtung Informatik) and Informationselektroniker, I combine deep technical skill with business-systems thinking to help manufacturers automate operations and optimize cross-border import and export.
More about the author →