Object-Oriented Concepts and Translating to the Physical Design

Until now we haven't needed to translate what we modeled with UML into something that isn't object-oriented in order to implement the application. Making the transition from the class diagram to a relational view requires some additional analysis.

The next several sections deal with many aspects of this transition. We assume that the repository being used as the persistence layer is some type of RDBMS. Most issues addressed here don't come up if the persistence layer will be an object-oriented database management system (OODBMS). OODBMSs are still by far the minority (although I encounter them more and more often in my consulting practice). Most applications that utilize an OODBMS are also using C++, Java, or SmallTalk as their language implementation, primarily because OODBMS vendors usually directly support bindings between their products and those languages. We also find that the traditional RDBMS vendors are transforming their products to take on more object features. Many of these products are referred to as object-relational database management systems (ORDBMSs). However, the mainstream Java development being done today is against an RDBMS.

Before progressing down the translation path, we need to visit each class and ensure that we completely identify all of the attributes for each one, specifying their unique data types. We've already identified many along the way, but now we need to apply more rigor to the process because soon we will be generating relational tables to support them.