Sample Selection

UML Class Diagrams for Data Modeling

A class diagram shows the structural model of a system with packages, classes, and relationships. Any data modeler familiar with entity-relationship modeling will recognize the basic elements of a class diagram, except for packages.

Architecture Packages: Schemas

A package is "[a] general purpose mechanism for organizing elements into groups. Packages may be nested within other packages." [OMG] In data modeling, packages serve two functions: organizing classes into architectural schemas and making names unique. Architectural design, in the context of data modeling, breaks down the data into subsystems called schemas. An ANSI SQL schema contains a name, an owner, a default character set, and a set of components [ANSI]. Most database management systems have schemas in one form or another as the basic container for database components such as tables, views, and stored procedures. These physical structures may or may not correspond to the schemas you model in your data model.

Breaking down a system into subsystems lets the designer isolate components of the system from change. By keeping references from one schema to another limited, you can limit the impact of changes to one schema, or at least to a small number of schemas. For example, consider a sales productivity application. Many data modelers would start by creating a data model in one large diagram that contains all the tables you need for the application. Instead, consider breaking down the data model into schemas, as this diagram shows.

Figure 1 shows the breakdown of the system into subsystems and the relationships between the subsystems. The Sales application has one subsystem for contacts, another for leads, a third for customers, and a fourth for call tracking. Contacts, leads, and customers all refer to a higher-level package, Entity, which represents the shared elements of people and organizations. Each package refers to other packages as needed: for example, call tracking uses contacts, leads, and customers, while each of those packages is independent of the others. That means, for example, that no table in the Contacts schema has a foreign key to any tables in Leads or Customers. If you change an attribute in Contacts, you need only look at the Entity schema to see if the change affects anything. Again, logical schemas may not reflect your physical implementation. You can allocate objects from all the logical schemas to a single database system schema, for example, to…

© 2005 Robert J. Muller, IEEE