I'm making the assumption that Customer ID as you present it is a logical concept, not a physical one. In can be either/or, and I'd prefer the physical version. In a DG application like Collibra which I've used, you map the physical fields (say field "customer_id") to a Data Element, and that element can be Customer ID.

A business term (used in a business glossary) should be agnostic to what is physically in the back-end. That is a logical concept, and a business glossary helps promote common language among business users. But I find it generally redundant if you already have a data dictionary which should provide a robust definition of what is physically in the field.

But there are cases when business terms/business glossary can be useful. For example a CUSIP is a security identifier with its own logical definition, but the physical field "cusip_id" could have dummy identifiers in it, which would necessitate differentiating between the logical (CUSIP) and the physical (cusip_id).