Los objetos brindan confiabilidad, flexibilidad y eficiencia a los sistemas de software, haciéndole frente a los diseñadores y a los arquitectos de hoy en día con muchas opciones. Desde el punto de vista de la tecnología, la opción esta generalmente entre orientación a objetos pura,  híbrido relacional-objeto, relacional puro, y soluciones basadas en los formatos de archivos abiertos o propietarios (ej. XML, el almacenamiento estructurado OLE). Oracle, IBM, Microsoft, POET ofrecen soluciones similares pero a menudo incompatibles.

Este articulo toma una de esas opciones, que es acordar un modelo orientado a objetos sobre una base de datos puramente relacional. Esto no implica que este sea la única opción, la mejor o mas simple solución, pero pragmáticamente es uno de los mas comunes.

Comenzaremos con un viaje rápido entre los dos dominios del diseño: primero el modelo de clases orientado a objetos según se presenta en UML, y segundo el modelo de base de datos relacional.

Para cada dominio miraremos solamente las características principales que afectan nuestra tarea. Entonces miraremos las técnicas y las ediciones implicadas en el mapeo del modelo de clases al modelo de base de datos, incluyendo persistencia del objeto, comportamiento del objeto, relaciones entre los objetos e identidad de los objetos. Concluiremos con una revisión del perfil de los datos de UML (según lo propuesto por Rational Software).
Una cierta familiarización con diseño orientado a objetos, UML y modelado de base de datos relacional es asumida.

El modelo de clase en UML es el artefacto principal producido para representar la estructura lógica  de un sistema de software. Captura los requisitos de los datos y el comportamiento de objetos dentro del dominio de modelo. Las técnicas para descubrir y elaborar este modelo están fuera del alcance de este artículo, por eso asumiremos la existencia de un modelo de clases bien diseñado que requiere mapeo a la Base de Datos relacional.