Cada tabla normalizada representa una entidad o clase de negocios. Por lo tanto, un diagrama de clases se puede convertir en una lista de tablas normalizadas. Asímismo, es posible dibujar una lista de tablas normalizadas como un diagrama de clases. Técnicamente, las entidades en un diagrama de clases no tienen que estar en la 3NF (o posterior). Algunos diseñadores utilizan un diagrama de clases como resumen, o imagen general de los negocios, y dejan fuera algunos detalles normalizados. En esta situación, tendrán que convertirse las clases a una lista de tablas normalizadas.
Relaciones uno-a-muchos
La regla más importante al convertir diagrama de clases a tablas normalizadas es que las relaciones se manejan al colocar una columna común en cada una de las tablas relacionadas. Esta columna suele ser una llave en una de las tablas y este proceso es fácil de apreciar con las relaciones uno-a-muchos.
Para convertir una relación uno-a-muchos debe agregarse la llave primaria del lado uno a la tabla del lado muchos. Esa llave agregada a la tabla del lado muchos no formará parte de su llave primaria, sino que será una columna común.
Relaciones muchos-a-muchos
Los diagrama de clases resumidos suelen contener relaciones muchos-a-muchos. Sin embargo, en una base de datos relacional, las relaciones muchos a muchos deben dividirse en dos relaciones uno-a-muchos para llegar a la BCNF.
Cada una de las dos entidades iniciales (con una relación muchos-a-muchos) se convierte en una tabla. El paso siguiente es crear una tabla nueva, que contiene las llaver primarias de las otras dos tablas. Esta tabla representa la relación muchos-a-muchos. Debe verificarse que las tres tablas estén en la 3NF, donde cada columna que no es una llave depende de la llave completa y sólo de la llave.
Asociaciones enarias
Las asociaciones enarias se representan con un diamante. Esta asociación con un diamante también se vuelve una clase. En cierto sentido, una asociación enaria es un grupo de varias asociaciones binarias. La nueva clase de asociación contiene la llave primaria de cada una de las otras clases. Siempre y cuando las asociaciones binarias sean uno-a-muchos, cada columna en la nueva clase de asociación será parte de la llave primaria. Si por alguna razó una asociación binaria es uno-a-uno, la columna correspondiente no sería una llave.
Generalización o tipos secundarios
Al convertir este tipo de diseño a una base de datos relacional, existen 2 métodos básicos.
- Si los tipos secundarios son similares, puede ignorar las clases secundarias y comprimirlas en la clase principal, la cual contendría todas las propiedades de cada una de las clases secundarias.
- En casi todos los casos, un mejor método es crear tablas separadas para cada clase secundaria. Cada tabla contendrá la llave primaria de la clase principal (superclase o clase padre). Además deberán agregarse atributos específicos a cada uno de los tipos secundarios.
Asociaciones reflexivas
En ocasiones, una entidad puede vincularse consigo misma. Para hacer la conversión, se crea una tabla con los atributos de esta entidad como columnas, y agregar como otra columna el nombre dado al vínculo en la asociación reflexiva.