Four hundred tables and not one of them is called Customer
Business Names Applied By The Tool, Not Remembered By People
November 3, 2026
An analyst asks a simple question: where does the customer data live?
Somebody opens a spreadsheet. The answer is KNA1 from the ERP, CUST_MSTR from the billing system, tblClient from the CRM, and a dimension someone built in 2019 called DimCust_v2. Four names for one idea. The warehouse kept every one of them because that's what the import brought in, and the import brought in whatever the source developers typed fifteen years ago.
None of this is anyone's fault. It's what happens to a warehouse that grows one source at a time.
How a naming standard turns into a wiki page
Every team that has hit this writes a naming standard. Entities in singular PascalCase, no prefixes, no abbreviations, a business name on every table. It's a good document. It lives on a wiki page.
Then the work starts. The first modeler renames carefully, because they wrote the standard. The second renames the tables they touch that week. The third is under deadline and leaves the source names alone, meaning to come back. Three people model the warehouse and it comes out three different ways, and the people who query it have to learn all three.
Fixing it later is worse. Four hundred tables at a few minutes each is a couple of weeks of renaming that nobody will ever put in a sprint. So the gap between the standard and the warehouse grows a little with every source you add, and each new person who joins learns the source names, because those are the names that are actually there.
The problem isn't discipline. Naming done by hand drifts the same way any hand-written boilerplate does. The standard needs to live where the work happens and get applied by the tool, not remembered by people.
Write the business vocabulary down where the model lives
BimlFlex generates a data warehouse from one metadata model: the sources, keys, rules and naming standards, kept in a database you host. The business side of the model lives in that same metadata, next to the physical side. In the app it sits under Design > Business Modeling, in three places.
Models are the business models themselves: the subject areas the organization actually talks about.
Entities are the things inside them, Customer and Order and Product, each with the attributes that describe it. A Customer has a name, a segment and a country, whatever the source tables happen to call those columns.
Taxonomy is how you sort it all: domains, subjects, entity types, classifications and tags. It's the part that lets a model with hundreds of entities still be navigable by someone who didn't build it.
Then you tie the physical to the business. BimlFlex calls each table in the model an object, and every object has a Business Entity field, so KNA1, CUST_MSTR and tblClient can all point at the same Customer entity. Columns map to business attributes the same way. The source names don't go anywhere. They stay as they are, because that's what the source is really called and the load still has to read it. But the model now knows that four tables mean one thing.
One click, four hundred tables
This is the part that replaces the two weeks of renaming.
Objects and columns each get their own grid in BimlFlex, and both grids carry an Apply Business Name button. Select the rows you want (fifty, or every object in the project) and click it. BimlFlex fills in the Business Name for every selected row in one go.
Where the name comes from is predictable. If the object points at a business entity, it takes that entity's technical name. If it doesn't, BimlFlex takes the object's own name and formats it with your naming convention, which is a setting (PascalCase out of the box). Columns work the same way against their business attributes. So the standard that used to be a paragraph on a wiki is now a rule the tool runs, and two modelers running it on the same tables get the same names.
When one table really does need a different name, you set it yourself. The object screen has a Business Name field under Business Overrides, so the exception is written down next to the object it belongs to, not in someone's memory.
What it's like when the next source arrives
The real test of any naming approach is source number twelve, not source number one.
With names done by hand, the twelfth source is where the standard quietly loses. It's a new team, a deadline, and two hundred tables with names like ZSD_ORD_HDR.
In BimlFlex it's the same routine as the first. Run Import Metadata against the source and its tables and columns come into the model. Link the new objects to the entities you already have, because a customer is still a customer. Select them, Apply Business Name. If a lot of rows need the same entity linked, use Bulk Edit. It's a grid for changing metadata many rows at a time: it shows every pending change and whether it's valid before anything is written, then saves once.
Then check your work without hunting for it. BimlFlex opens on a health check of the model, and its checks cover exactly this kind of drift: objects missing a business name, objects not mapped to any business entity, columns not mapped to a business attribute, names that break the naming convention. Each finding links to the place where you fix it.
Why this beats a better wiki page
You could write a stricter standard and review every pull request against it. Plenty of teams do. It works until the reviewer is on leave.
The difference with BimlFlex is where the standard lives. Your business vocabulary is data in the same model that generates the warehouse, so it's versioned with the model, visible to every modeler, and applied by a button instead of by memory. When the convention changes, you don't open a renaming project. You change the convention, select the rows and apply it again.
And the analyst's question gets a one-word answer. The customer data lives in Customer.
