Building Java Enterprise Applications

Data Modeling

A final couple of words on entity beans are merited before moving on. The Office bean has remained very simple so far, allowing you to overlook a few problems related to dealing with entity beans in a large application. This simplicity exists for two reasons: first, the bean stands on its own, and second, it is a frequently changed object. These two facts are discussed in the following sections.

Independent and Dependent Data Objects

The fact that an office is a complete entity means that it is an independent data object. In other words, a Forethought office does not depend on any other data to be complete. Additionally, an office has meaning on its own. A states table, for example, might not have this quality; for our purposes, a state’s name and abbreviation are not really useful on their own, and the state has purpose only within the context of another entity that references the states table. In this case, you would want the client to deal with the overall office entity, perhaps setting its name, and the bean would then use the states bean to work with that entity. In that way, the states entity becomes a dependent object. On the other hand, the office entity is an independent object.

It is also important to understand that just because an entity is used by another entity, it is not necessarily dependent. The office entity is again a perfect example: it is referenced by the users entity, specifying the office the user works in. But the office entity is not dependent, ...