El paso fundamental en un esquema relacional es listar las tablas que una base de datos tendrá. Aquí la representación gráfica no es tan importante como en los diagramas entidad/relación. No obstante, lo normal es utilizar una sintaxis de la siguiente forma:
Nombre_de_tabla (clave_primaria, campo1, campo2)
El nombre de la tabla no debería contener espacios o caracteres especiales. Tras el nombre de la misma, entre paréntesis se listaría cada columna separada por comas. La clave primaria va subrayada.
Cada tabla con sus columnas iría en una línea de texto distinta. Al convertir un diagrama entidad/relación en esquema relacional, por lo general, cada entidad se convertirá en una tabla del mismo nombre.
En relaciones tipo uno a uno son posibles dos opciones: crear dos tablas y relacionarlas entre sí de manera estándar o crear una superentidad que englobe los campos de ambas y crear una sola tabla. Ambas soluciones son correctas y es cuestión del analista informático decidir qué es lo mejor.
Lo normal es unir ambas entidades en una tabla para evitar complejidad. Si las dos entidades son muy grandes por sí solas, sí puede convenir mantenerlas separadas. Un ejemplo puede ser el de dos entidades de usuarios y currículums, donde ambas tablas tendrían muchos atributos y podría ser interesante dejarlas separadas.
En relaciones de muchos a muchos, se necesitará crear una tabla extra de relación entre las entidades involucradas. Siguiendo el ejercicio antes propuesto de “Determinar la cardinalidad en la relación entre noticias y categorías”, en este caso la respuesta era que la cardinalidad era de muchos a muchos, puesto que una noticia puede tener muchas categorías y una categoría puede tener muchas noticias.
Se crearían las tablas noticia (noticia_id clave primaria) y categoría (categoría_id como clave primaria).
Tendría que crearse la tabla noticia_categoria (noticia_id, categoria_id clave primaria). De esta manera, al utilizar la base de datos, para saber a qué categorías pertenece una noticia, basta mirar la tabla noticia_categoria.
Por lo general, cada atributo de cada entidad se convertirá en una columna de la tabla. Debe especificarse si la columna admitirá valores nulos o no. También debe especificarse qué columnas formarán la clave primaria subrayando su nombre.
No se permiten nombres de columna repetidos.
Por ejemplo, utilizar como prefijo de cada columna el nombre de la tabla, utilizar todos los nombres en singular, que la clave primaria aparezca al principio, etc.
No hay estándares fijados para esto, pero es conveniente utilizar el mismo criterio siempre.
Para crear las relaciones entre tablas, habrá que crear columnas adicionales para poder identificarlas. Estas nuevas columnas recibirán el nombre de claves foráneas y contendrán el valor de la clave primaria de la tabla con la que se relacionan.
Esta es una regla de transformación al modelo relacional. Cuando la cardinalidad de una relación no sea N: M, habrá que crear columnas que contengan el valor de la clave primaria de la tabla referenciada. De esta manera pueden relacionarse los registros de una tabla con otra. Simplemente, habría que consultar los registros cuyo valor de la clave primaria de B sea igual que el valor de la clave foránea en A.
En una relación de uno a muchos entre productos e imágenes, tendrían que crearse las siguientes tablas:
producto (producto_id, producto_nombre, producto_precio).
imagen (imagen_id, imagen_url, producto_id [clave foránea de producto]).
De esta manera podrían relacionarse productos con imágenes. El valor de la clave primaria de la tabla producto pasaría a la tabla imagen. Si se quisiera obtener la lista de imágenes de un producto, tan solo habría que usar el valor de la clave primaria en la tabla de imágenes.
Se debe tener cuidado, porque hay que mirar a ambos lados de la cardinalidad. Por ejemplo, en una relación entre usuarios y comentarios donde se permitan comentarios anónimos no realizados por usuarios, aparecería una relación de 0: N en el lado de los comentarios y una de 0: 1 en el lado de los usuarios. En este caso, se llevaría la clave primaria de usuarios a la tabla de comentarios, pero debería permitir que admitiera valores nulos, puesto que no todos los comentarios estarán escritos por usuarios.
Relación entre usuarios y comentarios. La columna “usuario_idusuario” de “comentario” admitiría nulos, porque se permiten comentarios anónimos.
Recuérdese que además, las relaciones pueden ser reflexivas: una tabla puede relacionarse consigo misma. En este caso se procedería de la misma manera, añadiendo las columnas extra a la tabla. Por ejemplo:
Tabla categoría (categoria_id, categoria_nombre). Piense en un menú desplegable de navegación por categorías. Una categoría puede tener categorías hijas y categorías padre. Una categoría hija solo tiene un padre. Sería una relación de 0: N por parte de la categoría padre y de 0:1 por parte de la categoría hija.
En ese caso la tabla se quedaría como categoría (categoria_id, categoria_nombre, categoria_padre_id [permite nulos, clave foránea de categoría]). Se añade un campo con el valor de la clave primaria del otro registro que se corresponde a su categoría padre. Puesto que habrá categorías que no tengan padre, deben permitirse nulos. Dado que la clave primaria ya tiene un nombre y no pueden repetirse nombres de columna, habrá que utilizar otro que sea parecido e identifique un poco el tipo de relación que tiene.
En este caso un usuario puede haber creado otros usuarios. Un usuario puede haber sido creado por otro o no (en caso del administrador, por ejemplo). La columa usuario_creador admitiría nulos.