In one of my early coding projects, I remember going through requirements meetings, hashing out a data model, drawing up a database design and submitting it to a DBA team for review and approval. When requirements change, or when stakeholders’ understanding of the data model evolve, or test data iterations produce different results, or scope-creep get into the project, we would start the data model —> database design —> DBA review/approval —> development creation process all over again.
While code refactoring can happen without data model refactoring, code is nearly always affected by changes to the underlying data model.
Data Refactoring for Databases https://thenewstack.io/do-we-need-data-normalization-anymore/, we used data sets for a coffee shop with sales receipts, products and customers.
By contrast, graphs remove the extra translation step between real-world data and database structure because they more naturally model data as it exists in the real world.