Hi Jon,
[This is a bit wordy, but follow along and there might be a few things you can use.]
The bad news is that you do know what the answer will be: there is no such diagram.
The good news is that you can create one yourself, though there won't be any associated documentation.
You seem to be asking about two things here. First there is the EA API itself. This is independent of the DBMS (or EAP) structure that EA uses to store the actual model. EA is a COM application. This is a somewhat dated (though still common and certainly workable) Microsoft paradigm for application interfacing.
Fortunately Sparx has provided a .Net 'wrapper' for the EA interface. Even though .Net would do this for you, the standard version provided by Sparx makes some (but not all) development tasks a bit easier. It also has a nifty side benefit in your case: it is a .Net executable file and thus may be imported into an EA model.
So, look up the Import Binary Module feature in the EA help. Create a model and use this function to import the wrapper file. The default location for this file is your EA installation directory; the name should be Interop.EA.dll (note that there are two periods in the name). If you want to be absolutely sure about the name you can use the References dialog in any .Net project to hunt for the file.
The second thing you seem to be asking for is the structure of the EA project schema. This can be diagrammed in EA by connecting to an EA project - not the one you have open, but another one - and importing the database from ODBC (or OLEDB, but the menu option is the same). Once again, look up how to import a schema in the EA help.
Finally, a word about how the EA 'engine' accesses its projects. Remember that EA uses both EAP files and DBMS databases as ways to store projects. Because of this EA uses a 'lowest common denominator' approach to handling storage. Although the engine is certainly aware of which database it is using - EAP files use the Microsoft Jet engine, the same one as used by MS Access - it does not rely on any functionality that is not present in all the databases it supports. Not only that, but the DBMS support in EA goes back several years, so EA was developed when several of the DBMS back ends had more limited functionality than today.
The end result is that EA does not make use of stored procedures - some DBMS back ends had very limited support, and Jet does not really handle these. Nor does it use some data types - data types like Boolean are not universally supported, but things like character codes are common. Still, the bottom line is that EA handles things in a 'plain vanilla' way; there's nothing along the lines of stored procedure calls.
David
PS: Although it is completely unsupported by Sparx (after all, how could they), you can actually tweak the DBMS back end a bit. Thus far EA has been fairly tolerant of this, just so long as you don't mess with any of the structure that EA defines. You and add your own stored procedures and triggers - once again I repeat the warning about messing with EA's own structures and add a caution about changing anything that EA would handle in the same transaction. You can even add additional fields to some - perhaps all, you will have to check and test each case - tables, or add new tables for your own functionality. Of course there are no promises here; in future Sparx might make changes that would invalidate some or all of what you do. So protect your work, and set up some kind of backup mechanism where you can extract the core (i.e. EA-specific) parts of the database. XMI export and a baseline of the entire model might work in many cases, but play around a bit and see what works best for you.
