Hi,
As I think this question comes up pretty often, I'll try to write my 2 cents worth.
The data of the EA model is stored in tables. A quick peak into these table can be found by invoking the built-in search (CTRL+f) , choosing a search that begins with Find ( some others may do) and click on the Edit Search icon. You may also copy the search. This allows you to edit and save it.
All the tables start with t_, so if you have a SQL Server based repository, you can find a list of tables by writing the following SQL:
select * from sys.objects where name like 't_%'
Lets take the t_object table as an example where t_object.Object_Type = 'Class'.
It has a Object_ID which is unique in the t_object table, it has a GUID, and a Package_ID. It also contains a ParentID for the case that it's an inner class.
If there is any other table that relates to an instance of t_object, we would assume that it would use the ObjectID as the reference to this object.
This is true in most cases where we have a normalized database.
The exception to this rule is where we would want a table to contain a reference to many "Types" of tables. Then we use a dirty trick of using two column, one contains the Table Name and the second contains the value of the ID (Class ID which is usually a string and object ID which may be an integer).
If the ID always has the same name and Type, this is relatively easy. Since in EA this is not the case, the designers use the GUID as the "object ID" in these (at least in most) cases.
In any case where we don't use normalized relationships, the database cannot enforce the integrity of the relationship. Even if I have record pointing to an object, if I delete this object, the relationship may still exist. It is the responsibility of the Application to "clean up" relations that are logically dangling. EA does this MOST of the time.
As far as searches are concerned, things get even more complicated, when the designers of the application try to "squeeze" more than one object into one relation. For example, if I have a DATA-FLOW that contains more than one object, the list of these objects will be a list in the Description field of the t_xref table.
Before deleting orphaned objects based on a search, always back up your database, and visually (and logically) verify that you are deleting orphan objects.
Sincerely,
Shimon
