Creating the Data Model

More often than not, projects may be forced to use an existing data model, perhaps from a legacy system. In this situation, there is no other option but to start with the existing data model and build your domain model around it. A comprehensive analysis should be undertaken to map domain objects to existing database schema and determine if the new application's processes fit into the model. It's a challenging architectural feat—you must be careful not to bring over the legacy tables wholesale because the tables may contain columns that may not belong in the context of the domain model. However, in the context of our sample application, we can start designing the data model from scratch. For the domain model of Figure 6-1, we define the data model using the ER diagram of Figure 6-2. Please note that the data model of Figure 6-2 uses IDEF1X notation. Using this notation, an optional non-identifying relationship is drawn as a dashed line with a solid dot on the child end and a diamond on the parent end.

Note

In a non-defining relationship, the foreign key becomes a non-key attribute in the child entity.

The data model in Figure 6-2 contains the ADMIN table that maintains the relationship between the portal-alliance administrators and NPO administrators with their corresponding portal-alliance and NPO objects. Later we review the implementation that establishes these relationships using container-managed persistence (CMP) and container-managed relationships (CMR). The ADMIN table is related to the NPO table through an NPO_Admin relationship. The ADMIN table is also related to the PORTAL_ALLIANCE table through a PortalAlliance_Admin relationship. Please note that both the profile and registration information for portal-alliances are kept in the PORTAL_ALLIANCE table; the same is true for the NPO table.

Figure 6-2: Data model for Site Administration and Manage Campaigns use case packages

The PORTAL_ALLIANCE table is related to the CAMPAIGN table through PortalAlliance_ Campaign relationship. This is an optional relationship, which means that a Campaign may or may not exist for a given Portal-Alliance. The CAMPAIGN table is related to the NPO table through a NPO_Campaign relationship. This relationship mandates that each campaign be associated with an NPO.

Once we have designed the data model and decided the table names and column names, we can implement the domain objects as entity beans with container-managed persistence. The table names and columns will be referred to in the deployment descriptors for the entity beans. The container will provide the implementation for getting and setting the values of the table columns using accessor methods for each column declared as container-managed. This concludes the initial setup required for arriving at a suitable domain-model and the corresponding persistence strategy. Note that for many-to-many relationships, you will probably want to use an associative table, but no such cases were present for our sample use cases.

Note

The ID column in the CAMPAIGN table is populated using the sequence number generation facility of the database. This usage is associated with vendor-specific deployment descriptors, which we address later in this chapter.