Data Modeler Meets Objects

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!

2 thoughts on “Data Modeler Meets Objects

  1. Anonymous


    Very insightful post. I look forward to these posts…it’s now August…do you have anymore wisdom to dispense?

Comments are closed.