Engineering and Development
Data Modeling
Poorly designed data becomes “two customers with the same tax ID,” reports that disagree with cash, and integrations that delete the wrong rows quietly. Viscale models for real operations: names the business recognizes, rules the database helps enforce (no duplicate orders, no silent deletes), a clear split between operational and analytical data when needed, and a migration plan that does not take the store offline overnight.
We start with vocabulary: what “paid order,” “active customer,” or “net revenue” means in your company — one definition per concept, written for both managers and developers. Only then do we sketch tables, keys, and relationships. The goal is that reading the model explains the business, not only internal acronyms.
Examples of what we model
Same customer in CRM and billing
A canonical record with clear links, not tripled addresses.
Dashboard sales match the register
Same rules for discounts, cancellations, and refunds everywhere.
History of who changed what
Readable audit: date, actor, and before/after values.
Personal data separated from the rest
Fewer people see tax IDs and emails; the rest of the app stays nimble.
Spreadsheet rules without hacks
Imports with validation and clear ownership when files change hands.
Orders and payments with clear states
Stages advance only when allowed; idempotency where it matters.
Fast catalog search
The right indexes for name or SKU without locking up at scale.
Migration without closing the shop
Short windows, checks between steps, and a safe rollback story.
BI model without bad duplication
Facts and dimensions aligned with what operations already trusts.
Retention and archival
What deletes, what anonymizes, and what must stay for compliance.
Schema change is handled carefully: expand before contract, test against data that resembles production, and keep a rollback path when things go wrong. For personal data we agree on minimization, masking in non-production, and retention timelines — aligned with legal and operations without needless technical drama.
When dashboards appear, we design the data path: where values originate, how often they refresh, and who owns discrepancies. Product and finance argue less with shadow spreadsheets, and everyone knows which number is “official.”
Portfolio of Data Modeling
Deliverables
Versioned model artifact
Diagram plus scripts or description in the repository.
Data dictionary
Column name, meaning, owner, and examples.
Business glossary
Shared definitions across departments.
Migration plan
Steps, order, and success criteria per phase.
Integrity rules list
What the system must block automatically.
Personal data map
Where it lives, who accesses it, retention policy.
Indexing strategy
Critical queries and how to avoid degradation at scale.
Test or validation scripts
Post-migration checks or reconciliation routines.
Integration notes
Payload contracts and stable keys for APIs.
Staging data guide
Realistic fictitious data without leaking personal info.
Handoff session
Questions with whoever maintains the database daily.
Improvement backlog
Prioritized follow-ups after go-live.
Execution methodology
-
Business glossary
Concepts and definitions everyone signs off on.
-
Source inventory
Spreadsheets, legacy systems, and data owners.
-
Conceptual model
Entities and relationships in accessible language.
-
Logical and physical model
Tables, keys, indexes, and types for expected volume.
-
Rules and integrity
What the database enforces vs the application layer.
-
Privacy and classification
Sensitive fields, access, and retention with legal input.
-
Migration plan
Expand, backfill, validate, then contract the old shape.
-
Data tests
Scenarios proving nothing vanished or doubled.
-
Living documentation
Diagram and prose onboarding can read in a day.
-
Analytics alignment
If a BI team exists, the same metric definitions.
-
Team training
How to evolve the schema without fearing production breaks.
