On the Agile Modeling forum, there was a great post by a Data Modeler requesting help on how to interpret an Object Model in terms of Data Modeling concepts.

My reply:

Some DM people “get it” and others remain stymied by the OM world 😉

Biggest issue is that the relationships in OO can often be “backwards” to many in the DM camp. Conversely, in SQL, you can usually get at any data that you want, regardless of the “direction”… A Client can have Address(es). Or, you can look at an address and probably tell me which clients are at that address.

You should endeavor to think in Objects. And, object models are often in the eye of the beholder. The perspective for a given model needs to be understood. That is, what did the modeler intend to convey?

Cutting to the chase (you get what you pay for here):

• Classes
• Class == Table
• (non-transient) Attribute == Column
• Normally i come up with standards for column width for

  various strings in the model

• Names are varchar 125
• URLs are varchar 416 (making this up )
• Descriptions are Text
• etc.
• Associations
• typically are whole-part or containment concepts. A Client——-0..* Address.
• if you see a filled-in diamond, think “Cascade Delete”
• other associations are simply relationships
• Association Class
• This is simply an unfinished portion of the model — or a short cut.
• It means that there is more “information” to be stored than

  simply the pure association

• For example: Insurance Agent ——– Agency can have an

  association class like “Registered” that shows the dates

  when the agent was active (employed) at the Agency.

• You have to eventually implement the Association class as a

  class/table in between, and connect the classes with the

  proper cardinality.

• Generalization
• do not bother doing LDM for this (kind of like unary operators should be avoided)
• parent has some attributes, children probably add more
• you have a choice of the following:
• one superset table with parent and child columns. for

  different child classes, you may have unfilled

  columns. a porous table so to speak.

• use joins of child tables to parent tables. suffer the

  cost of a join

• you can determine which is better based on projected

  usage and run some plans both ways with loaded sample

  data and representative queries and measure

  performance to make up your mind which way is best for

  your specific application

• Implements
• This is for an interface, which is purely behavior (methods)
• You may be able to ignore completely
• Or, if it is being used in an association (like a one class

  holds a collection of things implementing the interface),

  then you have to pay attention to it:

• It can serve as a “reference” to many other classes

  that implement that Interface

• You may have to persist that association and figure

  out how all the underlying implementing classes/tables

  can be held in a collection (typically a join table

  sort of a thing suffices)

Hope this helps!