Monday, 4 February 2002
How does one map an entity from an ERD to a Java bean (= Class)?

OO model after mapping of relationships
OO model with mapped relationships
Last week you read the preparing step, map ERD relationships to variables in a Java bean.

The week the continuation, mapping of the entities, in 5 steps:

  1. From optionality to specialisation
  2. Analyse top level methods
  3. Combine classes
  4. Remove exise
  5. Use caching

1. From optionality to specialisation

An optionality can be a clue leading to specialisation. Look for properties such as:
  • attributes with names like 'type', 'kind'
  • optional attributes
  • optional relationships, especially optional one-to-one relationships.
See if such an optionality is a characteristic of a subclass that does not change during the lifecycle of an object.

The given simple example does not have any optional attributes. But Subscription could have had a subscriptionType, with an optional discount percentage only applicable for students. In such a case:

  1. Split Subscription into the superclasse Subscription and the sub class StudentSubscription.
  2. Remove the 'SubscriptionsType'. This attribute is obsolete. The class will fulfill this role.
  3. The optional attribute discountPercentage will be a mandatory attribute in the subtype StudentSubscription.

2. Analyse top level methods

Data analysis will provide sufficient stability in 99% of the cases. Yet, it is still theoretically possible that a subclass has reason to exist solely because of special functionality that wasn't obvious from the data side.

An abundance of conditional processing, If ... THEN ... can also be a clue for possible sub types. Use polymorphism to cut down the jungle of IF statements.

3. Combine classes

optimised OO model
Het resultaat:
Optimised OO model
Look for In the example
  • Subscription belongs to one Newspaper.
  • But a Newspaper does not know the related Subscriptions.
Such a one way street can be a reason to combine classes:
  1. Move all variables from the 'one' (Newspaper) to the 'many' (Subscription). In the example: Newspapername, publisher, subscriptionPrice.
  2. Remove the 'to-one' variable (NewspaperObj).
  3. Remove the 'one' classe (Newspaper).

Remark: This step is comparable with combining tables in physical database design.

4. Remove exise

Some 'link' classes may still be present, rudiments from the second normal form.

An OO model does not need link classes, unlike a physical database:

  1. Remove the link class
  2. Simply implement two 'to-many' relationships, on both sides.

5. Use caching

Use caching to improve performance. Save CPU time by keeping the right collection of objects at runtime.

Remark: This step is comparable with creating indexes in physical database design.

Till next week,