Cuando aprendemos el modelo relacional, el cual es el mas conocido en teoría de datos; normalmente se nos enseña que existen 4 tipos de relaciones:
- Uno a uno (1 a 1)
- Uno a muchos (1 a N)
- Muchos a muchos (N a M)
- Muchos a uno (N a 1)
Lo que pocas veces se nos explica claramente es que el modelo relacional solo es válido durante la fase de diseño del modelo conceptual, que nos permite documentar y definir un modelo de datos solo a nivel de concepto, así pues, no todos los tipos de relaciones del modelo relacional son válidos para un modelo de base de datos lógico o físico. Pasamos a explicar lo anterior:
Relación uno a uno (1 a 1)
Las relaciones uno a uno No deben existir en una base de datos pues eso denota inmediatamente que se hizo un mal trabajo de normalización. Ya que cada tabla representa una entidad de la base de datos. Una relación uno a uno, significaría que cada tabla es 'media' entidad o dos tablas representan un asunto o entidad. Lo correcto seria fusionar las columnas de las dos tablas en una sola.
Las relaciones uno a uno No deben existir en una base de datos pues eso denota inmediatamente que se hizo un mal trabajo de normalización. Ya que cada tabla representa una entidad de la base de datos. Una relación uno a uno, significaría que cada tabla es 'media' entidad o dos tablas representan un asunto o entidad. Lo correcto seria fusionar las columnas de las dos tablas en una sola.
Siendo poco estrictos es verdad que existen relaciones uno a uno en situaciones especiales (desnormalización planeada) por convenir así; por ejemplo: si un campo de una tabla se actualiza constantemente y queremos disminuir el riesgo de colisión en bloqueos, se puede aislar ese campo en una tabla que lo contenga y esté relacionado con una llave primaria idéntica a la llave primaria de la primera tabla.
Tabla normalizada
Producto
|
* ID
|
Codigo
|
Descripcion
|
Costo
|
Precio
|
UltVenta
|
Tabla desnormalizada con relación uno a uno
Producto
|
* ID
|
Codigo
|
Descripcion
|
Costo
|
Precio
|
Producto2
|
* ID
|
UltVenta
|
Concluimos que una relación uno a uno No es una relación normal y comúnmente no debería existir en una base de datos.
Relaciones uno a muchos (1:N)
Las relaciones uno a muchos son las mas comunes y en realidad es la 'única' relación válida para una base de datos, así; un Cliente puede tener muchas Facturas, una Población tiene muchos Clientes y una Venta puede incluir muchos Productos.
Relaciones muchos a muchos (N:M)
Las relaciones muchos a muchos definitivamente son un tipo de relación que no existen en una base de datos por una simple razón... son imposibles de implementar a menos que se haga un terrible trabajo de diseño y por supuesto de normalización, ya que implicaría que un mismo registro se repitiera para cada relación.
Por ejemplo, para un Producto hay muchos Proveedores y para un Proveedor hay muchos Productos.
Este tipo de relaciones solo se implementa de manera eficiente si se crea una tabla intermedia que relaciona ambas entidades, para este caso crearíamos la tabla ProductoProveedor de la siguiente manera:
ProveedorProducto
|
* IDProducto
|
* IDProveedor
|
A este tipo de Entidades se les conoce como Entidades débiles, ya que no representan un asunto u objeto de la realidad que intentan resolver. Dicho sea de paso, este tipo de Entidades son las únicas que llegan a cuarta o quinta forma normal.
En el modelo físico las relaciones muchos a muchos se descomponen en relaciones uno a muchos a uno.
Relaciones muchos a uno (N:1)
Bueno, este tipo de relaciones solo es importante en el modelo conceptual, ya que en el modelo lógico y físico, normalmente da la misma distancia de ida que de vuelta, es muy sencillo deducir que es la misma relación 1 a muchos vista desde la derecha.
Las relaciones muchos a uno se tratan de una relación uno a muchos vista desde el otro lado.
* Recomiendo estudiar de manera independiente las 3 etapas del diseño de bases de datos, iniciando por el modelo conceptual, pasando al modelo lógico y finalizando con el diseño físico definido por el manejador de base de datos a utilizar.
Al llegar al modelo físico es importante comprender y utilizar adecuadamente las reglas de normalización, así como hacer un análisis correcto de cuando es conveniente saltarse alguna regla por ser conveniente a la funcionalidad del sistema o manejo de datos.
Conclusión: Siendo estrictos y siguiendo al pie de las letra las reglas de normalización, nos quedamos con la relación uno a muchos, y eliminamos la relación muchos a uno simplemente moviendo la tabla inicial de la relación a la izquierda y cambiando la relación por uno a muchos
