I have the dubious honor of having written the first ever book about UML data modeling (Oracle8 Database Design Using UML Object Modeling – 1998 Oracle Press). It was written to support the then new object extensions in Oracle8. Of course, no one ever actually used the object extensions in Oracle so the book also has the “honor” of perhaps being the worst selling Oracle Press book ever (although I may have to share that distinction with the Power Objects book).
The good thing about the book was that it got me to think really hard about how UML class diagrams can be used for drawing data models and then for generating databases.
A few years later, Dulcian’s BRIM® Objects was born and it used UML class diagrams to create the data models. Since then, we have been happily using UML class diagrams to draw data models and generate databases for over 10 years. At this point, I think I can safely say that it works pretty well.
That said, there are a couple of interesting things we had to do to make UML class diagrams work for data modeling:
- First, we used synthetic primary keys for everything. If the class is called “DEPARTMENT” then the physical primary key is “DEPARTMENT_OID”.
- Second, we auto-generated all of the foreign keys and referential integrity constraints. We allowed users to override the name of the foreign key column, but named them the same as the referenced primary key by default.
- Most importantly, we recognized that classes do not just turn into tables. When we drew a class diagram, we did not even think of it as a data model. We thought of it as a “structural business rule” repository. It indicated what stuff needed to persist and how it was structured. There were lots of interesting things in UML that did not even translate into tables.
Not forcing the class diagram to be “just” a data model allowed us to think about the best way to implement the diagram. Once we broke that link, it became obvious that the right solution was to use the class diagram to generate more than just tables. With each class, we generate a table and a view that sits on top of the table. Then we generate the getter and setter package to support Java EE (and other like-minded) developers.
Once the views were created, we started putting all sorts of cool things in them:
- Display functions for each class to provide a default display for each object in the UI.
- Bring in the display functions for all foreign key tables to provide a nice object name for each foreign key value in the view.
Rather than using hundreds of domain tables, we created a generic domain structure and then allowed designers to specify a “domain” instead of a datatype for a column.
We were able to support EXCLUSIVE OR, and generalization.
The result was that we had created a worthy successor to Oracle Designer, and we continue to use it to this day. I am amused that there is still debate about whether class diagrams can, should, and/or are able to be used for data modeling. They work pretty well… I promise. You just have to recognize that “How do you use a UML class diagram as a replacement for ERDs?” is not exactly the right question to ask and answer.
Leave a Reply