The structures of a relational database are very simple. You have tables, and you have tables. Unless you want to create a table, of course. This simplicity has one negative effect: it complicates the process of representing complex objects. The trick in moving from a UML data model to a relational schema is to make the simplicity of the relational table work for you instead of against you.

To illustrate the process, Figure 11-1 shows a UML model for the Person subsystem of the commonplace book, and Figure 11-2 shows a UML model for the Organization subsystem. Both of these subsystems are part of a third subsystem, the Entity subsystem. Figure 11-3 shows the architecture for the package.

The Person subsystem contains the Person class and the Identification hierarchy that belongs to it. I've chosen to use the inheritance version of Identification rather than the interface version. People connect to organizations through a three-way relationship to the Role class in the Organization package. The scope notation (Organization::Role) identifies classes that are not a part of the Person subsystem.

The Organization subsystem contains the Organization hierarchy, which includes the CriminalOrganization class. It also includes the Role class and the relationships between Role and Organization. Organizations connect to people through a three-way relationship to Role.

The Entity subsystem contains three elements: the two subsystems Person and Organization plus an abstract class, Entity. The Person and Organization classes in their respective packages inherit from that class. In the future, Entity...