Nueva pregunta

Pregunta:

Fecha: 10-10-2016 09:30:05 (En Español)

DER con MySQL Workbench: ¿Cuál es el significado de los iconos de relación? [Resuelta]

Hola a todos.

Estoy utilizando el software MySQL Workbench la funcionalidad de armar un diagrama (DER diagrama entidad relación).

Hay algunos iconos que no sé que funcionalidad prestan y en que casos serán utilizados.

Para ser más claro en mi consulta, he capturado la imagen de la barra de los iconos de las relaciones y la he enumerado para hacer referencia a cada uno de ellos.



Sabiendo que las relaciones entre entidades (tablas) posibles son:
Cardinalidades
1-1 de uno a uno (Iconos 1 y 3)
1-n de uno a muchos (Iconos 2, 4 y 6)
n:m de muchos a muchos (Icono 5)

El primer grupo de iconos de relaciones (1 y 2) tienen lineas discontinuas.
El segundo grupo de iconos relaciones (3, 4, 5 y 6) tienen lineas continuas.

Ahora, las dudas son:
Que diferencia hay entre las relaciones que tienen lineas discontinuas y continuas?
Es decir, ¿que diferencia hay entre estos grupos en cuanto a funcionalidad y en que casos prácticos serian utilizados?

Espero que me haya hecho entender bien en al formulación de la pregunta.

Muchas gracias.

Saludos.
Etiquetas: Base de Datos - DER - MySQL - MySQL Desarrollo - MySQL Workbench - Pregunta Votos: 4 - Respuestas: 8 - Vistas: 22 Compartir en: Google Facebook Twitter LinkedIn Link
 

Respuestas:

  • Fecha: 10-10-2016 17:45:11 Hola Walter, este tema requiere conocimiento conceptual de diseño de base de datos y fundamentos de modelado, al margen de lo dicho voy a tratar de resumir, lo cual no es lo óptimo para los que recien inician, pero servirá para quien ya tiene un conocimiento previo del tema.

    Este menú de opciones se utiliza para crear relacciones entre entidades (tablas), veamos cada una según tu numeración:

    Con las opciones 1 y 2 se establecen relaciones de claves foráneas (Non Identifying Relationship)

    Con la opción 3, 4 y 5 se establecen relaciones de identidad (Identifying Relationship)

    Con la opción 6 se establece una relación entre columnas existentes, tanto foránea como de identidad.

    * Una relación de identificación (Identifying Relationship) es cuando la existencia de una fila de una tabla secundaria depende de una fila de una tabla primaria, o sea, la tabla primara le “presta” su clave primara a la tabla secundaria, haciendo que los registros de la tabla secundaria solo puedan existir si existen los registros en la tabla primaria.
    Un ejemplo podría ser un producto que tiene múltiples imágenes, si no existe el producto en la tabla primaria “producto” no podría existir una o más imágenes en la tabla secundaria “productoimagen”. Este tipo de relación se definiría como Identifying Relationship 1-n (un producto puede tener múltiples imágenes).

    Y es aquí donde aparece otros dos conceptos “entidad fuerte” y “entidad débil”:
    Una entidad fuerte (también conocida como entidad regular) es aquella que sí puede ser identificada unívocamente por sus atributos. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad débil para que esta última se pueda identificar (para el ejemplo dado la entidad fuerte sería “producto”).
    Una entidad débil es aquella que no puede existir sin participar en la relación, es decir aquella que no puede ser unívocamente identificada solamente por sus atributos (para el ejemplo dado la entidad débil sería “productoimagen”).

    * Una relación de no identificación (Non Identifying Relationship) es cuando los atributos de clave primaria de la tabla padre no se convierten en atributos de clave primaria de la tabla hijo, sino en claves foráneas (atributos de relación).
    Un ejemplo podría ser un producto que esta asociado a un solo proveedor, la tabla “producto” tendría el atributo (clave foránea) “proveedor_id” perteneciente a la tabla “proveedor” (en producto, el atributo proveedor_id es una clave foránea, y en proveedor el atributo proveedor_id es clave primaria). Este tipo de relación se definiría como Non Identifying Relationship 1-n (un proveedor puede estar asociado a múltiples productos).

    Clave foránea: la clave foránea identifica una columna o grupo de columnas en una tabla (tabla hija o referendo) que se refiere a una columna o grupo de columnas en otra tabla (tabla maestra o referenciada). Las columnas en la tabla referendo deben ser la clave primaria u otra clave candidata en la tabla referenciada. Fuente: https://es.wikipedia.org/wiki/Clave_foránea

    Espero que mi respuesta te sea de ayuda.

    Saludos y buen código!
      Votos: 5 - Link respuesta
     
  • Fecha: 11-10-2016 02:00:51 Excelente explicación Fernando Mosquera!!!   Votos: 2 - Link respuesta
     
  • Fecha: 14-10-2016 08:29:47 PREGUNTA

    Walter, como haces para pegar una imagen aquí, ya que a veces ayuda a la hora de hacer una consulta o exponer algo

    Desde ya Gracias
      Votos: 1 - Link respuesta
     
  • Fecha: 14-10-2016 11:51:08 Antuan
    Si ayuda mucho las imágenes para hacerse entender de una manera mas rápida y concisa.
    Siempre que puedo lo demuestro con gráficas.

    para poner una imagen debes hostearla previamente en algún hosting de imagenes para que quede almacenada como por ejemplo:
    https://kn3.net/
    http://es.tinypic.com/
    http://s5.photobucket.com/

    Una vez subida la imagen, copias el link de la imagen que te proporcione dicho hosting por ejemplo
    https://k60.kn3.net/8DFA37688.png
    y luego lo pegas en el comentario, seleccionas todo el link de la imagen y hacer click en el boton img de la botonera de abajo.
    Enjoy it!

    Fernando muchas gracias por la respuesta, no te he respondido porque aun estoy digiriendo la información y leyendo mas información al respecto, estoy haciendo unas practicas con Workbench. En cuanto ya tenga una idea mas acabada respondere.

    Saludos
      Votos: 2 - Link respuesta
     
  • Fecha: 14-10-2016 12:48:54 Buenisimooooooooooo

    Gracias
      Votos: 1 - Link respuesta
     
  • Fecha: 16-10-2016 19:00:45 Hola
    He regresado.
    Fernando:
    Pido disculpa por la tardanza, he tenido poco tiempo y he estado viendo de varias fuentes temas relacionados sobre base de datos, tales como la normalización de bases de datos, las formas normales (NF) que proporcionan los criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías lógicas, etc.

    Volviendo al tema
    Actualmente estoy haciendo algunas prácticas básicas con Workbench. Aun me sigo mareando.
    He estado leyendo información complementaria sobre lo que me has comentado.
    Hay algunas cosas que no me han quedado aun tan claras.
    Para no hacer un embrollo con todos los puntos y conceptos iré por partes.
    Para iniciar este es el primer punto que creo que ya tengo claro, he realizado un gráfico (con dificultad) para ser más explícito en el tema y que a su vez espero que sirva como aporte didáctico a la comunidad.

    No sé si llamarlo esquema conceptual. En donde trato enfocar los siguientes puntos:

    1- (PK) Primary Key (clave primaria) - (FK) Foreign Key (clave foránea)
    2- Entidad Fuerte y Entidad Débil.
    3- Entidad relacional con cardinalidad de Uno a Muchos 1:N Se utiliza el icono 2 de la barra de herramientas de Workbench para establecer la relación entre entidades.


    4- ¿En este caso sería una relación de no identificación (Non Identifying Relationship) y NO una relación de identificación (Identifying Relationship)? Ya aquí me he extraviado un poco.

    Sobre los puntos expuesto que estaría bien y que estaría erróneo?

    Espero hacerme entender.

    Saludos
      Votos: 1 - Link respuesta
     
  • Fecha: 19-10-2016 19:06:39 Al anterior sumo otro gráfico, en este caso es con la cardinalidad 1 a 1
    Ejemplo: Un conductor puede no tener ningún vehículo y como máximo puede tener solamente un vehículo. Cardinalidad: 1: 1 (Uno a Uno)
    En este caso hay 2 diseños posibles.



    1- esta bien diseñado el garfico?
    2- Cual es le mejor diseño? Es el que menos NULL se produzcan?
    en ese caso a simple vista pareciera el mejor candidato el diseño 2 pero si ingreso 100 conductores se generarían mas NULL en el atributo (columna/campo) vehiculo_id, por lo tanto el mejor candidato seria el diseño 2 ya que se producirían menos NULL
    Creo que posiblemente este ejemplo no seria el mejor para representar la cardinalidad 1:1.
    Este ejemplo esta mas orientado a que depende al escenario que involucre en usar uno u el otro.

    Aprecio las respuesta que brinden a los casos expresados anteriores.

    Saludos
      Votos: 1 - Link respuesta
     
  • Fecha: 18-04-2017 14:51:54 Hola Walter, ante todo me disculpo por la demora, pero aquí mi respuesta.

    Veamos los puntos del comentario http://www.phpcentral.com/pregunta/734/der-con-mysql-workbench-cual-es-el-significado-de-los-iconos-de-relacion#resp_b7d0858d41a6c29b873e4aba411e6d04

    1- Está ok.

    2- Aquí tienes dos entidades fuertes, “autor” es claramente una entidad fuerte (eso está ok) pero “publicacion” no es entidad débil, sino fuerte, porque le incluiste una PK propia, y si te fijas en la teoría más arriba verás que "Una entidad débil es aquella que no puede existir sin participar en la relación, es decir aquella que no puede ser unívocamente identificada solamente por sus atributos". Cumples con la parte de “…no puede existir sin participar en la relación…” porque tiene una FK (Non Identifying Relationship) que genera una restricción (constraint) que no te permite insertar un registro en “publicacion” sin indicar esa FK, pero es solo por restricción (constraint) y no por concepto de entidad débil. Para que “publicacion” fuera una entidad débil debería tener una PK compuesta por un número/fecha/etc. (para el ejemplo voy a usar un número) y la PK de “autor”, donde “autor_id” en la tabla “publicacion” es el resultado de una relación de identidad (Identifying Relationship), entonces para tu ejemplo podrías tener los registros de la siguiente forma:
    nro(PK)		autor_id(PK)	fecha		titulo		texto
    1					1		2016-10-10	Java		xxxx
    2					1		2016-10-10	SQL		xxxx
    1					2		2016-10-10	PHP		xxxx
    2					2		2016-10-10	CSS		xxxx
    3					2		2016-10-10	HTML	xxxx
    3					1		2016-10-10	JQuery	xxxx
    


    Observa que para identificar la publicación con título “PHP” es necesario contar con el nro de la publicación que es 1 y el autor_id que es 2.

    En la práctica todo el mundo modela entidades fuertes y utiliza FK con la restricción (constraint), como lo hiciste en tu ejemplo… por eso se dice en la universidad que una cosa es la teoría formal de base de datos (la que te toman en el examen) y otra muy distinta es la práctica del mundo real (en la facultad no se habla de id’s, sino de columnas que hacen singular a un registro, por ejemplo un DNI, Fecha, etc… pero en la práctica no se usan esas columnas, sino id’s).

    3 y 4- Como te comento en el punto 2, la relación debería ser 1:n relación de identidad (Identifying Relationship), se utiliza el icono 4 de la barra de herramientas de Workbench.

    --------------

    Ahora veamos los puntos del siguiente comentario http://www.phpcentral.com/pregunta/734/der-con-mysql-workbench-cual-es-el-significado-de-los-iconos-de-relacion/#resp_9eac167ec1efbe078138397fabba902e

    1- Tiene el mismo problema de concepto con entidad débil, en tus gráficos todas las tablas son entidades fuertes. También el diseño 1 esta desnormalizado, porque estarías repitiendo el nombre del vehículo si todos (por ejemplo) usan bicicleta. El diseño 2 estaría ok a nivel normalización, pero recuerda que ambas son entidades fuertes (de hecho, a nivel concepto, si no hay un conductor no tiene por qué dejar de existir el vehículo, está ok que sean las dos entidades fuertes) y ojo con la relación, porque sería 1:n (imagina que todos los conductores tuvieran bicicleta, la bicicleta estaría relacionada con muchos conductores, o sea, 1 a muchos).

    2- El diseño 2 es el que esta ok, salvando la relación que es 1:n y que ambas son entidades fuertes.

    Walter, siempre es un placer, espero que mi respuesta sea esclarecedora y no te enrede más en conceptos, que en la práctica no son tan prácticos ;)

    Saludos y buen código!
      Votos: 1 - Link respuesta
     
Para participar activamente de la comunidad primero debes autenticarte, ingresa al sistema.Iniciar Sesión
 
frjcbbae garagebible.com