A data model defines which entities a system represents, how they relate, and the level of detail recorded about them. In a digital twin, these schema choices come before storage formats, partitioning, and indexing: they shape what can be written, queried, and analyzed as the system grows. section 4.3
One customer, multiple records
A bank may hold checking-account and credit-card records in separate systems. One may say “Gregory” while another says “Greg,” and the records may lack a shared customer number. A model that needs a complete customer view must account for how those representations are linked. It should not assume that either record is a perfect description of the person. section 5.2.2
Listing 5.1 A simple example of fuzzily matching identifiers, used to link data records
from thefuzz import fuzz
identifiers = [ #1
"CUST-001234", "CUSTOMER-001234", "cust_001234",
"PROD-ABC123", "PRODUCT-ABC123", "Product ABC-123",
"EMP-789456", "EMPLOYEE-789456", "emp_789456"
]
print("Fuzzy Matches (score >= 80):") #2
for i, id1 in enumerate(identifiers):
for id2 in identifiers[i+1:]:
score = fuzz.token_set_ratio(id1, id2)
if score >= 80:
print(f"{id1:15} ↔ {id2:15} ({score})")
The Python listing compares pairs of identifiers with `thefuzz` and prints pairs scoring at least 80. It illustrates one way to find possible links between differently written records; the matching step does not, by itself, define the entities or relationships in the model. section 5.2.2
No single model or storage technology satisfies every digital-twin requirement. Choose structures for the data and access patterns at hand, while checking that the relationships needed for later analysis remain representable. Where systems must exchange data, domain data-model standards such as IFC or ISO 15926 can support semantic consistency. section 4.3 section 5.5.1
