How does one map an entity from
an ERD
to a Java bean
(= Class)?
 | 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:
- From optionality to specialisation
- Analyse top level methods
- Combine classes
- Remove exise
- 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:
- Split Subscription into the superclasse
Subscription
and the sub class
StudentSubscription .
- Remove the 'SubscriptionsType'.
This attribute is obsolete.
The class will fulfill this role.
- 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
 | 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:
- Move all variables from the 'one' (Newspaper) to the 'many' (Subscription).
In the example: Newspapername, publisher, subscriptionPrice.
- Remove the 'to-one' variable (NewspaperObj).
- 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:
- Remove the link class
- 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,
Nut
|