Fundamentos del diseño de bases de datos relacionales: tipos de relaciones y cómo establecerlas

Una parte fundamental en el diseño de una base de datos relacional es dividir los elementos de datos en tablas relacionadas. Una vez que estás listo para comenzar a trabajar con los datos, dependes de las relaciones entre las tablas para juntar los datos de manera significativa. Por ejemplo, la información de un pedido no sirve de nada a menos que sepas qué cliente realizó ese pedido. A estas alturas, seguramente te das cuenta de que no almacenarás la información del cliente y del pedido en la misma tabla. En cambio, guardarás los datos de los pedidos y los clientes en dos tablas relacionadas y luego utilizarás una relación entre las dos tablas para ver cada pedido y su información de cliente correspondiente al mismo tiempo. Si las tablas normalizadas son el fundamento de una base de datos relacional, entonces las relaciones son la piedra angular.

Serie de diseño de bases de datos relacionales

Estás en medio de la serie de diseño de bases de datos relacionales de Builder.com. Los artículos anteriores de esta serie son:

• "Bases de datos relacionales: La inspiración detrás de la teoría"
• "Bases de datos relacionales: Utilizando formas normales para crear bases de datos"
• "Bases de datos relacionales: Aplicando la Primera Forma Normal"
• "Bases de datos relacionales: Logrando la normalización"

Punto de partida

Para la demostración en este artículo, se utiliza la siguiente información de datos. El proceso de normalización de los datos a través de la Forma Normal de Boyce-Codd (BCNF) produjo siete tablas relacionadas:

• Libros: {Título*, ISBN, Precio}
• Autores: {Nombre*, Apellido*}
• Códigos postales: {Código postal*}
• Categorías: {Categoría*, Descripción}
• Editoriales: {Editorial*}
• Estados: {Estado*}
• Ciudades: {Ciudad*}

Ahora es el momento de establecer cómo se relacionan esas tablas entre sí.

Tipos de relaciones

Tienes muchas relaciones con los miembros de tu familia. Por ejemplo, tú y tu madre están relacionados. Tienes solo una madre, pero ella puede tener varios hijos. Tú y tus hermanos están relacionados, puedes tener muchos hermanos y hermanas y, por supuesto, ellos también tendrán muchos hermanos y hermanas. Si estás casado, tanto tú como tu cónyuge tienen un cónyuge, el uno al otro, pero solo uno a la vez. Las relaciones de la base de datos son muy similares en el sentido de que son asociaciones entre tablas. Existen tres tipos de relaciones:

• Uno a uno: Ambas tablas pueden tener solo un registro en cada lado de la relación. Cada valor de clave primaria se relaciona con solo un (o ningún) registro en la tabla relacionada. Son como cónyuges, pueden o no estar casados, pero si lo están, tanto tú como tu cónyuge tienen solo un cónyuge. La mayoría de las relaciones uno a uno son impuestas por reglas comerciales y no fluyen naturalmente a partir de los datos. En ausencia de esa regla, generalmente puedes combinar ambas tablas en una sola sin romper ninguna regla de normalización.
• Uno a muchos: La tabla de clave primaria contiene solo un registro que se relaciona con ninguno, uno o muchos registros en la tabla relacionada. Esta relación es similar a la que tienes con tus padres. Tienes solo una madre, pero tu madre puede tener varios hijos.
• Muchos a muchos: Cada registro en ambas tablas puede relacionarse con cualquier número de registros (o ninguno) en la otra tabla. Por ejemplo, si tienes varios hermanos, tus hermanos también tienen varios hermanos. Las relaciones muchos a muchos requieren una tercera tabla, conocida como tabla de asociación o enlace, porque los sistemas relacionales no pueden acomodar directamente la relación.

Estableciendo relaciones

Para cuando llegas a establecer relaciones entre las tablas relacionadas, seguramente ya estás muy familiarizado con los datos. En consecuencia, las asociaciones son más evidentes en este punto que cuando comenzaste. Tu sistema de base de datos se basa en valores coincidentes encontrados en ambas tablas para formar relaciones. Cuando se encuentra una coincidencia, el sistema extrae los datos de ambas tablas para crear un registro virtual. Por ejemplo, es posible que desees ver todos los libros escritos por un autor en particular. En este caso, el sistema coincidiría los valores entre las tablas de Libros y Autores. Es importante recordar que la mayoría de las veces, el resultado es un registro dinámico, lo que significa que cualquier cambio realizado en el registro virtual generalmente se reflejará en la tabla subyacente.

Potenciando el acceso: Crea una interfaz para SQL Server con estilo

Esos valores coincidentes son los valores de clave primaria y clave foránea. (El modelo relacional no requiere que una relación se base en una clave primaria. Puedes usar cualquier clave candidata en la tabla, pero usar la clave primaria es el estándar aceptado). Ya aprendiste sobre las claves primarias en la Parte 2: una clave primaria identifica de manera única cada registro en una tabla. Una clave foránea es, simplemente, la clave primaria de una tabla en otra tabla. Por lo tanto, no hay mucho que hacer. Solo agrega el campo de clave primaria a la tabla relacionada como una clave foránea.

La única consideración es que un campo de clave foránea debe tener el mismo tipo de datos que la clave primaria. Algunos sistemas permiten una excepción a esta regla y permitirán una relación entre un número y un campo de autoincremento (como AutoNumber en Access o Identity en SQL Server). Además, los valores de clave foránea pueden ser Nulos, aunque la recomendación es que no dejes una clave foránea como Nula sin una razón muy específica para hacerlo. Es posible que nunca trabajes con una base de datos que requiera esta capacidad.

Regresa a tus tablas de muestra y comienza a ingresar las claves foráneas según corresponda. (Continúa trabajando con listas en papel, todavía es demasiado temprano para crear tablas en tu sistema de base de datos. Es mucho más fácil corregir un error en papel). Recuerda, estás agregando el valor de la clave primaria a una tabla relacionada. Solo recuerda las relaciones entre las entidades y el resto es fácil:

• Los libros están relacionados con las categorías.
• Los libros están relacionados con las editoriales.
• Los libros están relacionados con los autores.
• Los autores están relacionados con los códigos postales.
• Los códigos postales están relacionados con las ciudades.
• Las ciudades están relacionadas con los estados.

Este paso en particular no está escrito en piedra y es posible que encuentres más fácil agregar claves foráneas durante el proceso de normalización. Cuando muevas un campo a una nueva tabla, probablemente agregarás la clave primaria de esa nueva tabla a la tabla original como una clave foránea. Sin embargo, a menudo las claves foráneas cambian a medida que continúas normalizando los datos restantes. Es posible que encuentres más eficiente hacer todas las claves foráneas al mismo tiempo, después de que todas las tablas estén completamente normalizadas.

Avancemos primero por cada una de las tablas, comenzando con la tabla de Libros, que en este punto tiene solo tres campos. Específicamente, agrega las claves primarias de las tablas de Autores, Categorías y Editoriales a Libros. Cuando hayas terminado, la tabla de Libros tendrá siete campos:

• Libros
• Título (PK)
• ISBN (PK)
• Precio
• FirstNameFK (FK) Autores.Nombre muchos a muchos
• LastNameFK (FK) Autores.Apellido muchos a muchos
• CategoryFK (FK) Categorías.Categoría muchos a muchos
• PublisherFK (FK) Editoriales.Editorial uno a muchos

Recuerda, la clave primaria en la tabla de Autores es una clave compleja basada tanto en el nombre como en el apellido. Por lo tanto, debes agregar ambos campos a la tabla de Libros. Observa que los nombres de los campos de clave foránea incluyen el sufijo FK. Agregar este sufijo mejora la legibilidad y hace que se autodocumenten. Puede resultarte más fácil hacer un seguimiento de las claves foráneas si las identificas de esta manera en su nombre. No hay ningún problema si las claves primarias y foráneas no tienen el mismo nombre.

Descubriendo los secretos detrás de los Oracle buffer busy waits

Existen tres relaciones presentes: Libros a Autores, Libros a Categorías, y Libros a Editoriales. Lo que puede no ser tan evidente para ti son los problemas con dos de estas relaciones:

• Libros a Autores: Un libro puede tener más de un autor.
• Libros a Categorías: Un libro puede tener más de una categoría.

Estas dos relaciones representan relaciones muchos a muchos. Como mencionamos anteriormente, las tablas no pueden acomodar directamente estas relaciones y requieren una tercera tabla de enlace. (La relación Libros a Editoriales es una relación uno a muchos y está bien tal como se afirma actualmente).

Ambas relaciones muchos a muchos recién descubiertas requerirán una tabla de enlace que contenga la clave primaria de cada tabla como clave foránea. Las nuevas tablas de enlace son:

• BooksAuthorsmmlink
• TitleFK (FK) Libros.Título uno a muchos
• ISBNFK (FK) Libros.ISBN uno a muchos
• FirstNameFK (FK) Autores.Nombre uno a muchos
• LastNameFK (FK) Autores.Apellido uno a muchos

No se necesitan cambios en las tablas de Categorías, Autores o Editoriales. Sin embargo, debes remover las claves foráneas FirstNameFK, LastNameFK y CategoryFK de la tabla Libros:

• Libros
• Título (PK)
• ISBN (PK)
• Precio
• PublisherFK (FK) Editoriales.Editorial uno a muchos

Ahora, pasemos a la tabla de Autores, que actualmente tiene dos campos. Cada autor se relaciona con un valor de código postal en la tabla de Códigos postales. Sin embargo, cada código postal puede relacionarse con más de un autor. Para acomodar esta relación de uno a muchos, ingresa la clave primaria de la tabla de Códigos postales en la tabla de Autores como clave foránea:

• Autores
• Nombre (PK)
• Apellido (PK)
• ZIPCodeFK (FK) Códigos postales.Código postal uno a muchos

En este punto, estás listo para abordar los componentes restantes de la dirección. Es extraño verlos separados en tablas, pero ese es el resultado de normalizar correctamente los datos a través de BCNF. Cada valor de código postal tendrá un valor correspondiente de ciudad y estado. Cada valor de ciudad y estado se ingresará solo una vez en su tabla correspondiente. Las tablas de Códigos postales y Ciudades requieren campos de clave foránea para acomodar las relaciones:

Cómo ahorrar espacio en disco utilizando campos calculados en una base de datos

• Códigos postales
• Código postal (PK)
• CityFK (FK) Ciudades.Ciudad uno a muchos

• Ciudades
• Ciudad (PK)
• StateFK (FK) Estados.Estado uno a muchos

• Estados
• Estado (PK)

En resumen, tienes nueve tablas: Libros, Autores, Categorías, Editoriales, Códigos postales, Ciudades, Estados, BooksAuthorsmmlink y BooksCategoriesmmlink. La Figura A muestra una representación gráfica de la base de datos de muestra, al final de este proceso. Es difícil imaginar que una tabla simple de datos se divida en nueve.

Figura A

La tabla original ahora requiere nueve tablas.

Debido a la simplicidad del ejemplo, podrías preguntarte en qué ayuda todo este asunto de la relación. Parece que aún estás almacenando datos redundantes, solo de manera diferente, en forma de claves foráneas. Eso se debe a que nuestras tablas tienen solo algunos campos en este momento. Intenta imaginar una tabla con una docena de campos. Es cierto que aún debes almacenar la clave primaria de esa tabla como valor de clave foránea en una tabla relacionada, pero eso probablemente constituya uno o dos campos adicionales como máximo. Compara eso con la alternativa de agregar todas las entradas de esa tabla para cada registro.

Ventajas y desventajas de las bases de datos ISAM frente a las bases de datos relacionales

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Gestión de datos, allí encontraras muchos artículos similares a Fundamentos del diseño de bases de datos relacionales: tipos de relaciones y cómo establecerlas , tenemos lo ultimo en tecnología 2023.