Alternatives to SQL for describing data mappings

Question

Back story: I work for a startup which was acquired by a large Fortune 500 company. I'm the lead engineer on a project which aims to consolidate duplicate data stored by both companies. Our new corporate overlords have a mature RESTful API (written in Java) exposing all their data which happens to live in a Oracle DB under the hood. Our startup codebase has similar data living in a MS SQL DB with no real nice API and a hand-rolled access layer written in C#/F#.

Part of my job is to come up with a mapping between these two data stores so a translation layer can be written. I'm happy to work at any level of abstraction and the most obvious one to me is translating POJOs <> C# entity objects.

My problem is that this mapping gets quite convoluted, and I need product managers with much more domain expertise than me to sanity-check what I'm doing. That's great, except the only way of expressing data they understand is SQL, to the point where they'll rewrite my strawman proposals in some kind of pseudo sql format they feel more comfortable with.

Given the differences in data stores & tech stack and limited size of TPM's comfort zone, is there a better way of expressing mappings between a bunch of business objects that doesn't have a huge learning curve?

Answer 1

ERD diagrams seem like a pretty good way to accomplish this (especially if you ignore the links parts). Just looking at the names of the tables and the data in the fields corresponds pretty naturally to any other representation. The only thing that's hard to capture in a very sensible modeling neutral way is the hierarchy/relationship, but in this case, thats probably pretty easy too, because both existing systems already have been mapped down to SQL (so easy to generate ERD diagram for each).