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.
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):
- 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
- 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
- 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
- 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!