Diferencias

Muestra las diferencias entre dos versiones de la página.

--- bloque2:diseno [2022/02/14 14:18] – [Conversión de Modelo E/R a Relacional] fernando
+++ bloque2:diseno [2024/09/16 19:34] (actual) – editor externo 127.0.0.1
@@ Línea 229: / Línea 229: @@
-=== Claves Secundarias ===
+=== Claves Alternativas o Secundarias ===
 Se suele llamar de este modo a todos los campos que identifican a cada registro de forma inequívoca, es decir, campos que almacenan valores que no se pueden repetir en más de un resgistro de una misma tabla.
 En las imágenes del ejemplo anterior, el campo (matricula) de la tabla Vehículo, es un campo único por lo que se considera una clave secundaria. También podríamos tener un campo (dni) para la tabla Propietario que actuaría como clave secundaria.
-====Conversión de Modelo E/R a Relacional====
+====Transformación de Modelo E/R a Relacional====
 El paso de un modelo E/R a un modelo relacional se puede llevar a cabo, en gran parte, siguiendo una serie de reglas o pautas, que se enumeran a continuación:
@@ Línea 244: / Línea 244: @@
   * El **identificador único** de la entidad se convierte en clave primaria. Siempre que pueda, añadiré un campo //id// como clave primaria.
   * Los **atributos multivaluados** generan una nueva tabla con tres columnas: un //id//, el //id// de la tabla de la que surgen propagado como //clave ajena// y el valor del campo multivaluado. <code>(#id, -id_tabla_origen, atributo_multivaluado)</code>
 **Relaciones:**
@@ Línea 272: / Línea 273: @@
     * En la transformación de **relaciones 1:1** se tienen en cuenta las cardinalidades de las entidades que participan en ellas. Existen también diferentes soluciones:
-      - La transfomación tradicional consiste en que una de las tablas tenga una clave primaria que al mismo tiempo es clave ajena de la otra tabla. Solo se puede plantear si alguna de las cardinalidades parciales es (1,1). En ese caso se propaga la clave primaria de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1), en la que será clave primaria y ajena al mismo tiempo. Si ambas cardinalidades parciales son (1,1), no importa hacia qué lado se propaga.
+      - La transfomación tradicional consiste en que una de las tablas tenga una clave primaria que al mismo tiempo es clave ajena de la otra tabla. Solo se puede plantear si alguna de las cardinalidades parciales es (1,1). En ese caso se propaga la clave primaria de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1), en la que será clave primaria y ajena al mismo tiempo. Si ambas cardinalidades parciales son (1,1), no importa hacia qué lado se propaga. (Ejemplo 1)
-      - Otra solución más sencilla es transformarla como si fuera una relación 1:N. Si existe una entidad con cardinalidad parcial (0,1), su tabla tendrá una columna nueva que sería la clave primaria de la otra entidad propagada como clave ajena. Si las cardinalidades parciales son iguales da igual hacia qué tabla se propague la clave primaria. //Si usamos esta opción, al crear las tablas en el SGBD, la clave ajena debe ser una columna indexada sin repeticiones (''UNIQUE'')//.
+      - Otra solución más sencilla es transformarla como si fuera una relación 1:N. Si existe una entidad con cardinalidad parcial (0,1), su tabla tendrá una columna nueva que sería la clave primaria de la otra entidad propagada como clave ajena. Si las cardinalidades parciales son iguales da igual hacia qué tabla se propague la clave primaria. //Si usamos esta opción, al crear las tablas en el SGBD, la clave ajena debe ser una columna indexada sin repeticiones (''UNIQUE'')//. (Ejemplo 2)
-      - Transformarlo en una tabla. Se aplica cuando ambas entidades poseen cardinalidades parciales (0,1) y por lo tanto hay casos en los que no existe relación entre las tablas. La relación se convierte en una tabla de la misma forma que una relación N:M.
+      - Transformarlo en una tabla. Es un caso muy específico y solo se aplica cuando ambas entidades poseen cardinalidades parciales (0,1) y si solo unos pocos registros de ambas tablas están relacionados. La relación se convierte en una tabla de la misma forma que una relación N:M.
 Ejemplo: Un empleado solo puede tener un despacho, y un despacho pertenece a un solo empleado.
 {{ :bloque2:conversion11.png?600 |}}
->Tablas empleados y despachos (opción 1)
+>Tablas empleados y despachos (Ejemplo 1)
+<code sql>
+-- Ejemplo 1: Clave primaria y ajena al mismo tiempo
-<code>
--- Opción 1
 empleados(#id, nombre, apellidos, direccion, dni, telefono)
 despachos(#(-id_despacho), cod_despacho, direccion, superficie)
--- Opción 2 (Transformación 1:N)
+-- Ejemplo 2: Clave primaria y ajena diferente (como 1:N)
 empleados(#id, nombre, apellidos, direccion, dni, telefono)
 despachos(#id, cod_despacho, direccion, superficie, -id_empleado)
 </code>
-  * Para los **atributos de las relaciones** existen dos casos:
+  * Las relaciones de **herencia** se transforman como relaciones 1:1 entre tablas padres e hijas. Aplicando las reglas anteriores, se ha de crear una tabla por cada entidad hija con sus propias columnas.
-    * Si la relación es 1:N, sus atributos se propagan a la tabla de lado N, junto con la clave del lado 1
+    - Para relacionarlas, la forma más directa es propagar la clave primaria de la tabla padre como claves ajenas en las tablas hijas; Las tablas hijas tienen como clave primaria el campo clave de la tabla padre (Ejemplo 1).
-    * Si la relación es N:M, sus atributos se transforman en columnas de la tabla generada por dicha relación
+    - La otra forma, menos común, es transfomarla como si fueran dos relaciones **1:N**: las tablas hijas tienen su propia clave primaria (id), y añadirán una columna nueva que es la clave primaria de la entidad padre, propagada como clave ajena. //En este caso, al crear las tablas hijas en el SGBD, las claves ajenas deben tener ser columnas indexadas sin repeticiones/duplicados (''UNIQUE'') y sin valores nulos (''NOT NULL'', o la propiedad ''requerido'' en Access).//   (Ejemplo 2).
-    * Las relaciones **1:1** no deberían de tener atributos, ya que en principio deben pertenecer a alguna de las dos entidades.
-  * Las relaciones de **herencia** se pueden transforman de varias maneras. Aplicando las reglas anteriores, se ha de crear una tabla por cada entidad hija con sus propias columnas.
-    - Para relacionarlas, la forma más sencilla es hacerlo como una relación **1:1** : Las tablas hijas tienen clave primaria el campo clave de la tabla padre, propagado como clave ajena.
-    - La otra forma, menos común, es transfomarla como si fueran dos relaciones **1:N**: las tablas hijas tienen su propia clave primaria, y añadirán una columna nueva que es la clave primaria de la entidad padre, propagada como clave ajena. //En este caso, al crear las tablas hijas en el SGBD, las claves ajenas deben tener ser columnas indexadas sin repeticiones (''UNIQUE'') y sin valores nulos (''NOT NULL'', o la propiedad ''requerido'' en Access).//
 Ejemplo: Una pista puede ser una pista_abierta o una pista_cerrada.
 {{ :bloque2:conversion-herencia.png?700 |}}
 >Tablas pistas, pistas_abiertas y pistas_cerradas
-<code>
+<code sql>
+-- Ejemplo 1: Claves primarias y ajenas al mismo tiempo
 pistas(#id, nombre, tipo, superficie)
 pistas_abiertas(#(-id_pista), fecha_inscripcion, fecha_alta)
 pistas_cerradas(#(-id_pista), razon_cierre, fecha_apertura)
-</code>
+-- Ejemplo 2: Claves primarias y ajenas diferentes (-id_pista es UNIQUE y NOT NULL)
+pistas(#id, nombre, tipo, superficie)
+pistas_abiertas(#id, fecha_inscripcion, fecha_alta, -id_pista)
+pistas_cerradas(#id, razon_cierre, fecha_apertura, -id_pista)
+</code>
   * Las relaciones **reflexivas**, se transforman antendiendo a su cardinalidad del mismo modo que hemos planteado en los casos anteriores:
-    * Si la cardinalidad es **N:M**, se crea una tabla nueva como el caso general de relación N:M. La clave primaria se comprone del id de la tabla.
+    * Si la cardinalidad es **N:M**, se crea una tabla nueva como el caso general de relación N:M. La clave primaria se compone de dos columnas que referencian al mismo id de la propia tabla.
     * Si la cardinalidad es **1:N**, se transforma como si se tratara de una relación 1:N, se propaga la clave primaria a la misma tabla como clave ajena.
-    * Si la cardinalidad es **1:1**, al tratarse de la misma tabla, se transforma como si se tratara de una relación 1:N. //Si usamos esta forma al crear la tabla en el SGBD la columna clave ajena no permitirá valores repetidos (indexada sin repeticiones, ó ''UNIQUE'')//.
+    * Si la cardinalidad es **1:1**, al tratarse de la misma tabla, se transforma como si se tratara de una relación 1:N. //En este caso, al crear la tabla en el SGBD la columna clave ajena no permitirá valores repetidos (indexada sin repeticiones, ó ''UNIQUE'')//.
 {{ :bloque2:reflexividad.png?400 |}}
 >Un empleado puede supervisar a varios empleados
-<code>
+<code sql>
 -- Relacion 1:N y 1:1
 empleados(#id, nombre, apellidos, dni, -id_empleado_supervisor)
@@ Línea 326: / Línea 332: @@
 empleados_supervisores(#(-id_empleado_supervisor, -id_empleado_supervisado))
 </code>
+  * Para los **atributos de las relaciones** existen dos casos:
+    * Si la relación es 1:N, sus atributos se propagan a la tabla de lado N, junto con la clave del lado 1
+    * Si la relación es N:M, sus atributos se transforman en columnas de la tabla generada por dicha relación
+    * Las relaciones **1:1** no deberían de tener atributos, ya que en principio deben pertenecer a alguna de las dos entidades.
 ==== Ejemplos de transformaciones a modelo relacional ====