Sparx Enterprise Architect for Data Modelling
TL;DR
Use Sparx Enterprise Architect as the source of truth for your schema. Model first, generate DDL second. Normalisation isn’t academic—it reduces redundancy and improves performance when done properly.
I don’t use Enterprise Architect for diagrams—I use it for database modelling.
The model is the system.
From that model:
Tables, keys, and relationships are defined once
Constraints are explicit
The DDL is generated, not hand-written
This flips the usual approach. Instead of “design drifting from implementation”, the implementation is derived from the design.
Why model-first works
You’re forced to think in entities and relationships, not tables
Normalisation becomes natural (not an afterthought)
Referential integrity is designed in, not patched later
Changes are intentional and visible
A good model is a proof of structure—not just a suggestion.
On normalisation
There’s a tendency to treat normalisation as optional or “theoretical”.
It’s not.
A properly normalised model:
Eliminates data duplication
Prevents update anomalies
Keeps data consistent by design
And yes—done properly—it’s often more performant, not less.
Less redundancy means less data to maintain, fewer inconsistencies, and clearer indexing strategies.
Where Enterprise Architect fits
Enterprise Architect is strong here because it:
Enforces structure and relationships
Makes dependencies explicit
Generates consistent DDL across environments
Keeps the schema aligned with the model over time
Used this way, it’s not documentation—it’s infrastructure definition.
My take
If your database is designed directly in SQL, you’re skipping the hard part.
The model is the design.
Everything else should come from it.