4.2 Paradigms

It's important to note, that, if you are using UML for database design, you aren't automatically modeling classes. This is because of the paradigm which is "behind" the model. While you take the object-oriented model as granted for UML, the paradigm can be exchanged, e.g. with the relational paradigm. You also assume the relational model for ERDs, but you can also use the object-oriented paradigm behind ERD modeling anytime.

Paradigms and notations can be used independently of each other, that is switching them are two distinct operations. Mixing notations with other, non-natural paradigms will result in rather unusual models, but it can be done. Consequently, it's fairly easy to translate ER diagrams to UML and vice versa as long as the paradigm is retained. Changing the notation is like changing the "view" on the model, but the content itself is untouched.

Of course, the paradigm determines the elements you are modeling. When using the object-oriented paradigm with ERDs, there's no point in modeling primary keys. Vice versa, using the relational model with UML still requires you to model primary keys, at least on the logical and physical levels. In UML, non-object-oriented constraints can be added by using property strings for attributes, like {PK, FK}. For conceptual models, you can also assume no paradigm at all. The ERD and UML notations are sufficiently abstract to support that statement. Just imagine omitting the primary keys in a conceptual ERD: you won't lose any conceptual information.

The following table gives an overview of the main characteristics of modeling paradigms per level:

Per-Level Characteristics of Paradigms
LevelRelational ParadigmObject-Oriented Paradigm
ConceptualMany-to-many, primary keys, relationshipsMany-to-many, object identifiers, references
LogicalNo many-to-many, primary keys, foreign keysMany-to-many, object identifiers, references
PhysicalNo many-to-many, primary keys, foreign keysMany-to-many, object identifiers, references

I cling to remember a source which stated, that all relational models must contain only normalized entity types. You have to differentiate that, because it doesn't make sense for all modeling levels. It's true for logical and physical relational models, but not conceptual ones. Strictly speaking, normalization is a foreign key issue, which are only applicable to the logical and physical levels. I think the original statement relates to avoid tables, which actually represent two or more entity types, which would be correct.

Another source once stated, there was no need to model primary keys in UML. I don't see why this should be the case. In the end, omitting the primary keys in UML would mean, that a change of notation and not the paradigm would affect the content of the model.

The conceptual level doesn't necessarily require a paradigm, but you have to decide for a specific paradigm for logical and physical models, that is either relational or object-oriented. While the similarities and differences between notations and paradigms were (hopefully) made clear, I will omit the object-oriented paradigm for the rest of this work and focus on the relational paradigm in conjunction with ERDs on all modeling levels. As stated before, you can translate the discussed material to UML fairly easily (see references).

References for Modeling Notations and Paradigms:

Last updated: 2010-10-13