sábado, 5 de noviembre de 2011

Diferencia entre Identifying y Non-Identifying Relationship

Hola a todos...

Estoy empezando a usar el MySQL Workbench y creando un diagrama EER me surgió la duda de que diferencia habia entre una relacion identificadora y una relación no identificadora.

Despues de googlear bastante y de leer mucha info en inglés me he topado con una explicació de Leonardo R que en mi opinión es muy facil de entender.

'Copipasteo' literalmente su explicación:

Una relación identificadora (identifying relationship), es una relación de uno-a-muchos, en la que la clave primaria de una entidad fuerte es absorbida por una entidad débil. Se dice que es una entidad débil, porque por sí misma no tiene modo de identificarse de forma única (no tiene clave primaria).

Un ejemplo: tenemos una aplicación que registra el ingreso de los empleados a las instalaciones de la organización. he aquí el modelo:

empleado { id_empleado, nombre, apellido, departamento, cargo }
ingreso_a_instalaciones { id_empleado, hora_ingreso, puerta }

En este caso, existe una relación identificadora porque cada registro de ingreso_a_instalaciones *requiere* que se especifique la id_empleado. De no especificarse, no se podría saber quién ingresó a las instalaciones. Eso convierte a cada ingreso_a_instalaciones en una entidad débil, que depende de la existencia de otra entidad (el empleado)

--

Una relación no identificadora (non-identifying relationship) es una relación de uno-a-muchos donde una entidad no depende de la existencia de otra, porque tiene su propia clave principal.

Un ejemplo: tenemos una aplicación que lleva la nómina:

empleado { id_empleado, nombre, apellido, cargo, departamento, id_empleado_jefe }

En este caso, yo puedo usar la clave foránea id_empleado_jefe para establecer qué otro empleado es jefe de un empleado en particular, pero en sí, cada empleado tiene su id_empleado, por lo que la relación con el *empleado jefe* no tiene para nada que ver con la existencia del empleado común.

6 comentarios:

  1. entendi algo pero podrias ayudarme con otro ejemplo gracias

    ResponderEliminar
    Respuestas
    1. Fíjate bien en los ejemplos...

      En el primero la tabla "ingreso_a_instalaciones" no tiene indices ya que ninguno de los campos puede ser UNIQUE... Se podría formar un índice y usarlo como clave principal con la unión de "id_empleado, hora_ingreso". La hora de ingreso en sí no nos dice nada si no sabemos quien ha ingresado a esa hora, por lo que "hora_ingreso" es una entidad débil que depende de la relación con la otra tabla.

      En el segundo ejemplo muchos tuples (filas) de empleado pueden tener un mismo "id_empleado_jefe" pero no se requiere de ese campo para la descripción unívoca de esa fila, ya que queda perfectamente descrita solo con su clave primaria "id_empleado".

      Espero te se a ayuda... Suerte!

      Eliminar
  2. Muchas gracias :), instructor si lee esto, no era yo, me hackearon :V

    ResponderEliminar
  3. Bien!, sintetizado y con nitidez!

    ResponderEliminar