An Overview of Mapping - Beginning Hibernate: From Novice to Professional - page 81

Based on this, the following questions arise:

• Is a unique customer identified by their customer ID, or their customer reference?

• Can an e-mail address be used by more than one customer?

• Should the relationship be represented in the Customer table?

• Should the relationship be represented in the Email table?

• Should the relationship be represented in some third (link) table?

Depending upon the answers to these questions, your database tables could vary consid-
erably. You could take a stab at a reasonable design, such as that given in Figure 5-3, based
upon your intuition about likely scenarios in the real world.

Figure 5-3. Tables in which the customer is identified by customerId . Here, e-mail address entities
can only be used by a single customer, and the relationship is maintained by the Email table.

As soon as you take away the context provided by the variable and class names, it
becomes much harder to form any useful decision about these classes (see Listing 5-4).
It would be an impossible task to design an automated tool that could make this sort of
decision.

Listing 5-4. A Class Identical in Structure to Listing 5-3, but with All Contextual Information
Removed

public class Foo {
int x;
int y;
String s;
Bar bar;

}

public class Bar {
String a;

}