What you have and what you can do
A first look suggests that you have a nice graph:
- Programmes, stored procedures and data structures, are all some kind of nodes. The first are processing nodes, the latter are storage nodes
- Read and write relations, are directed edges that show the flow of data between the nodes.
With such a graph, you can already:
- analyze the potential impacts of a change in a node, by looking downstream, just following the direction of the edges.
- analyse migration requirements, by going down and upstream (ignore direction of the edge).
- compute closure sets to identify "clusters" that should be migrated together.
How to represent your data ?
There are plenty of graphical standards that you could use. However, basically, what you have is a data flow graph, and the easiest way to picture it, would be to show a data flow diagram (DFD). Two popular representations are Yourdon&Demarco and Gane&Sarson: both DFD show little difference and basically they have processor nodes, storage notes and flow edges, exactly what you have.
DFD diagrams are a little bit outdated nowadays. This is because they represent a procedural view of the world, separating passive data from active processes. This is certainly why there is no real equivalent in UML which is build on the object oriented paradigm. The UML information flow diagram is a fair approximation (although it doesn't really have stores). The UML communication diagram is another approximation, if you consider programs and individual tables as object instances.
Addendum: The UML component diagram (see Doc Brown's answer) is also a viable approximation, if you consider your passive data as an active component (after all, it's behavior is ensured by the RDBMS engine). However the interface connectors that you will need (at least one for a read and one for a write, if you don't want to loose the direction of the edges), will make it less readable and more difficult to draw.
What's maybe missing in your toolset ?
I don't know INGRES. But if it's a RDBM with stored procedures, comes the question if there is any referential integrity mechanism (e.g. hidden procedures that could cascade deletion and changes), or any foreign keys that could give a better understanding of how tables are related between them. This could help you to further analyse your mesh by taking into account non obvious dependencies.
