Class Diagrams
The natural role for class diagrams in an integration project is in describing the schema of the various package databases. It is not unusual in an integration project for the bulk of the effort to be expended on getting all of the systems data synchronized. This can be done at a logical level using class diagrams. It is possible to use inheritance relationships to connect similar concepts across multiple databases. For example, in our call center example, the CTI server may store details about calling parties, and the CRM system may store details about accounts. These are both representations of something that we might call a "customer," and they can be shown as subclasses of the logical customer class. In this way, we can demonstrate how the two databases are linked at the logical level, which in turn can assist in building any data transfer code. It also means that we can build sequences and business data flows based on the logical entities and then translate these logical names into the specific tables used by each package as appropriate. A simple class diagram showing the logical structure of an incoming call contact event from a customer and the physical subclassing of the common data might look like the one in Figure 4.
){kind=link}
Customer Class Diagram
Of course, class diagrams are a superset of traditional ERDs and, as such, can also show all of the usual ERD type information about relationships, multiplicity, and so on.