Diferencias

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

--- bloque2:diseno [2021/11/26 00:21] – [Primera forma normal 1FN] fernando
+++ bloque2:diseno [2024/09/16 19:34] (actual) – editor externo 127.0.0.1
@@ Línea 48: / Línea 48: @@
 {{ relacion.png }}
-Si consideramos que dos entidades A y B están relacionadas a través de una relación R, deberemos determinar lo que se conoce como //cardinalidad de la relación//, que determina cuantas entidades de tipo A se relacionan, como máximo, con cuantas entidades de tipo B. Además, resulta conveniente, en cada caso, calcular cuántas entidades de tipo A se relacionan, cómo mínimo, con cuantas entidades de tipo B (que normalmente será 0 ó 1). De esa manera podremos indicar la obligatoriedad o no de relación entre elementos de las entidades A y B.
+Si consideramos que dos entidades A y B están relacionadas a través de una relación R, deberemos determinar lo que se conoce como //cardinalidades de la relación//, que determina cuantas entidades de tipo A se relacionan, como máximo, con cuantas entidades de tipo B. Además, resulta conveniente, en cada caso, calcular cuántas entidades de tipo A se relacionan, cómo mínimo, con cuantas entidades de tipo B (que normalmente será 0 ó 1). De esa manera podremos indicar la obligatoriedad o no de relación entre elementos de las entidades A y B.
 ==== Relaciones binarias y ternarias ====
-Para evitar las dificultades que supone el uso de algunos aspecto del [[bloque2:diseno#modelo_e_r_extendido|Modelo Entidad/Relación Extendido]], como las //agregaciones//, trataremos de plantear siempre relaciones en las que participen **como máximo dos entidades** (Relaciones binarias). Es decir, trataremos en la medida de lo posible evitar //relaciones ternarias//:
+Para evitar las dificultades que supone el la transformación a tablas (Modelo Relacional) de algunos aspecto del [[bloque2:diseno#modelo_e_r_extendido|Modelo Entidad/Relación Extendido]] como las //agregaciones//, trataremos de plantear siempre relaciones en las que participen **como máximo dos entidades** (Relaciones binarias). Es decir, trataremos en la medida de lo posible evitar //relaciones ternarias//:
 {{ relaciones.png }}
@@ Línea 81: / Línea 81: @@
 ==== Cardinalidad de la relación ====
-Es una cardinalidad que nos hace ver rápidamente la participación de dos entidades en una relación. Es una cardinalidad igual que las vistas ahora pero se indica en el símbolo de la relación y se obtiene a partir de los máximos de las cardinalidades parciales de la realación:
+=== Cardinalidades parciales de una relación ===
+Son las cardinalidades que nos indican con cuantos elementos de una entidad participan los elementos de la otra entidad, cómo mínimo y como máximo. Cada entidad tiene su cardinalidad parcial, y a partir de ambas se obtiene la cardinalidad completa de la relación. Se separan mediante '','' y se encierran entre parentesis.
+=== Cardinalidad total de una relación ===
+Es una cardinalidad que nos hace ver rápidamente la participación de dos entidades en una relación. La cardinalidad de la relación se indica dentro del símbolo de la relación o debajo de la relación. Se obtiene a partir de los máximos de las cardinalidades parciales de la relación:
 {{ :bloque2:cardinalidad-relacion.png?600 |}}
+Se indica en mayúsculas y separada por '':''
 ==== Atributos de una relación ====
 Existen situaciones en las que a la hora de modelar ciertos requisitos, nos encontramos con que hay ciertos datos que debe almacenar la base de datos que no son características **realmente propias** de ninguna de las entidades que conforman una relación. En esos caso es probable que dichas propiedades pertenezcan a la relación en sí.
@@ Línea 106: / Línea 112: @@
-En el caso del ejemplo, existen dos tipos de empleados que se relacionan de forma diferente con otros objetos del sistema, pero que a su vez pueden tener gran parte en común. Por ejemplo, trabajan de forma diferente pero muchos de los datos personales que almacenaremos de ambos son comunes. Es por eso que el objeto //Empleado// se puede considerar una generalización de los dos tipos de trabajadores que hay en el sistema. Todos aquellos atributos y relaciones que tengan en común se podrá representar como atributos y funcionalidad del objeto //Empleado// y los atributos y relaciones que tengan como trabajadores especializados serán representados en la correspondiente entidad.
+En el caso del ejemplo, existen dos tipos de empleados que se relacionan de forma diferente con otros objetos del sistema, pero que a su vez pueden tener gran parte en común. Por ejemplo, trabajan de forma diferente pero muchos de los datos personales que almacenaremos de ambos son comunes. Es por eso que el objeto //Empleado// se puede considerar una generalización de los dos tipos de trabajadores que hay en el sistema. Todos aquellos atributos y relaciones que tengan en común serán atributos y funcionalidades del objeto //Empleado// y los atributos y relaciones que tengan como trabajadores especializados(Encargados o repartidores) serán representados en la correspondiente entidad.
 ==== Reflexividad ====
@@ Línea 223: / 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 233: / Línea 239: @@
 **Entidades y atributos:**
-  * Toda entidad se transforma en una tabla.
+  * Toda **entidad** se transforma en una tabla.
+  * Todo **atributo simple** o **derivado** se transforma en columna de una tabla.
-  * El identificador único de la entidad se convierte en clave primaria. Siempre que pueda, añadiré un campo //id// como clave primaria.
+  * Los **atributos estructurados** transforman los campos en los que se componen en nuevas columnas de la tabla.
+  * El **identificador único** de la entidad se convierte en clave primaria. Siempre que pueda, añadiré un campo //id// como clave primaria.
-  * Todo atributo simple o calculado se transforma en columna de una tabla.
+  * 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>
-  * 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.
-  * Los atributos estructurados transforman los campos en los que se componen en nuevas columnas de la tabla.
 **Relaciones:**
@@ Línea 271: / 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. Si una de las entidades posee cardinalidad parcial (0,1) y la otra (1,1), se propaga la clave primaria de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1). Si ambas cardinalidades son iguales, 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'').//
 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 325: / 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 ====