El Diagrama de Clase presenta un mecanismo de implementaci�n neutral para modelar los aspectos de almacenado de datos del sistema. Las clases persistentes, sus atributos, y sus relaciones pueden ser implementadas directamente en una base de datos orientada a objetos. Aun as�, en el entorno de desarrollo actual, la base de datos relacional es el m�todo m�s usado para el almacenamiento de datos. Es en el modelado de este �rea donde UML se queda corto. El diagrama de clase de UML se puede usar para modelar algunos aspectos del dise�o de bases de datos relacionales, pero no cubre toda la sem�ntica involucrada en en el modelado relacional, mayoritariamente la noci�n de atributos clave que relacionan entre s� las tablas unas con otras. Para capturar esta informaci�n, un Diagrama de Relaci�n de Entidad (ER diagram) se recomienda como extensi�n a UML.
El Diagrama de Clase se puede usar para modelar el estructura l�gica de la base de datos, independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos de clase representando columnas. Si una base de datos relacional es el m�todo de implementaci�n escogido, entonces el diagrama de clase puede ser referenciados a un diagrama de relaci�n de entidad l�gico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades l�gicas y a sus atributos; el modelador dispone de varias opciones sobre c�mo inferir asociaciones en relaciones entre entidades. Las relaciones de herencia son referenciadas directamente a super-sub relaciones entre entidades en un diagrama de relaci�n de entidad (ER diagram).
Ya en el Diagrama de Relaci�n de Entidad, el modelador puede empezar el proceso de determinar c�mo el modelo relacional encaja; y qu� atributos son claves primarias, claves secundarias, y claves externas basadas en relaciones con otras entidades. La idea es constriur un modelo l�gico que sea conforme a las reglas de normalizaci�n de datos.
Al implementar el dise�o relacional, es una estrategia encaminada a hacer referencia al diagrama de relaci�n de entidad l�gico a un diagrama f�sico que represente el objetivo, el RDBMS. El diagrama f�sico puede ser denormalizado para lograr un dise�o de base de datos que tiene tiempos eficientes de acceso a los datos. Las relaciones super-sub entre entidades se resuelven por las estructuras de tablas actuales. Adem�s, el diagrama f�sico se usa para modelar propiedades espec�ficas de cada fabricante para el RDBMS. Se crean varios diagramas f�sicos si hay varios RDBMSs siendo 'deployed'; cada diagrama f�sco representa uno de los RDBMS que son nuestro objetivo.