Відео

Sí. Porque si alguna "binaria" entre ellas tuviera un 1 en alguna de las ramas, entonces se podría modelizar SIN la ternaria. No perderías información. La ternaria surge porque necesitas la concurrencia de las 3 a la vez en algún momento. Esa información la tendrás si pones una ternaria, o si pones una asociativa entre 2 de ellas, y luego haces una binaria desde esa asociativa con la tercera: en este último caso "parece" que no tengas ternaria, pero la tienes "escondida" en el rombo de la última interrelación (donde tienes los "tríos")

Consejo: supongo que ya lo estás haciendo, pero deberías mirarte los vídeos en los que se explica el "Paso del Modelo ER al Modelo Relacional". Ahí entenderás muchos de los problemas que pueden ocurrir si se diseña incorrectamente un modelo ER, lo que ocurre al pasarlo a TABLAS.

@@nettorius Todavía no he llegado. Comenzaré hoy. Te dejo por aquí la pregunta, entre el modelo ER y el relacional, ¿hay algún paso intermedio?. Por lo que tengo entendido son fases consecutivas. 1º Se recoge la información del mundo real. 2º se abstrae esa información construyendo el ER. 3º SE pasa ese diseño conceptual a un diseño lógico como es el relacional. ¿Correcto?.. Pero me entró la duda, si hay que hacer algo en medio entre el 2º y 3º. Muchas gracias por tu comprensión.

En las ternarias no acostumbro a poner las mínimas. Básicamente porque el punto de partida siempre es la pareja origen, y das por hecho de que esa pareja se está dando. Si llegas a la conclusión de que en una rama de la "ternaria" la mínima es 0, entonces si la máxima es N (o muchos) NO SERÍA Ternaria (porque en el MR tendrías una tabla con un NULL en un atributo que forma parte de la PK). Habría que hacer la asociativa en el origen. Eso lo expliqué en alguna de tus preguntas anteriores :-) La rama de Clientes: debes escoger una pareja (un suministrador y un producto que suministra) y preguntarte : ¿a cuántos clientes lo suministra? A muchos, ok. Pero ¿podría ser que ese producto que tiene ese suministrador no lo envíe a ningún cliente? SÍ. Por tanto, si lo pensamos MEJOR, no sería lo correcto modelizarlo como TERNARIA. Porque perderíamos información. Al ser las máximas de la ternaria N:M:P, la PK de la tabla que aparece serían las 3 del origen. Pero tendrías alguna combinación (ejemplo (sum_1, prod_3, NULL) ) y no se debe poner NULL en un atributo que forme parte de la PK. Y perderías la información de que el Suministrador 1 tiene el producto 3. Este ejemplo lo puse para ilustrar la discusión de las cardinalidades Máximas, y poderlas interpretar correctamente. Pero si vamos al detalle de la realidad quizá habría que matizar lo que te he comentado aquí. Entonces un criterio que nos puede ayudar para determinar si una interrelación es ternaria, es pensar que: -Si en una RAMA la cardinalidad máxima es MUCHOS, entonces la mínima DEBE SER 1. Si fuera 0, entonces NO es ternaria. -En las ramas donde la cardinalidad máxima es 1, entonces se permitiría tener una mínima de 0. Pero SÓLAMENTE PUEDE HABER UNA RAMA con esas características. Es decir, si tienes una candidata a ser ternaria (lo estás discutiendo), y es del tipo 1:1:N . Entonces no puedes tener a la vez en las dos ramas con el 1 la cardinalidad mínima 0, porque entonces (en el modelo Relacional) tendrías un NULL en un atributo que forma parte de la PK (porque recuerda que en ese caso, la PK está formada por una pareja: la del lado N (obligatorio) y una de las del lado 1) La verdad es que tus preguntas me acaban haciendo reflexionar sobre aspectos que complican el diseño, pero aparecen en la vida real, y deben tenerse en cuenta. Pero también es cierto que no he visto en ningún sitio a nadie que explique esto con ese nivel de detalle. Básicamente porque son conceptos que la gente está aprendiendo, no les puedes complicar tanto inicialmente. Cuando ya tienen una base y has hecho ejercicios, te empiezas a dar cuenta de los posibles fallos que implicarían un diseño con incorrecciones. Gracias.

@@nettorius Perdona por no haberme dado cuenta que en el ejemplo de las entrevistas ya comentabas lo del O en las mínimas. Pero gracias a ello, ahora tengo una regla que me puede dar seguridad, se permite un 0 en min si es de un max 1. No puede haber más de un 0,1. Si hay 2 descartamos ternaria. Tambien descartamos ternaria si hay un 0,n. Sí tienes razón. Entiendo que los vídeos tendrían 2 fases. Una, dónde se aprende y otro posible vídeo donde surgen las complicaciones. Muchas gracias por tu buen hacer y paciencia.

No hay un orden. Lo pones tú en la rama adecuada interpretando correctamente las cardinalidades. Da igual poner N:M:1 o 1:N:M. Lo que importa es que en el diagrama los números o letras estén en la rama adecuada.

Hola. Sí , es lo mismo. La verdad es que yo nunca he usado el término "agregación", y siempre he usado las entidades "ASOCIATIVAS", es decir las que provienen de una interrelación (o sea "el rombo"). Con mi forma de pensar ("las bolitas que hay dentro") me resulta más fácil visualizarlo y hacerlo entender. He tenido que ver otras fuentes para ver qué entendían por "agregación", y efectivamente es lo que yo pongo como "asociativas". Pero en los ejemplos que he visto de agregación ponen un gran recuadro a toda la interrelación origen (entidades e interrelaciones (rombo)), y desde mi punto de vista eso despista bastante y no ayuda a concretar bien. Yo prefiero convertir el "rombo" en una Entidad, y a partir de ella hacer las otras interrelaciones.

Gracias a tí por "aguantar" 10 días viendo mis videos. Es una satisfacción ver que mi trabajo sirve para algo a alguien. Si a las personas que les gusta el contenido lo comparten y hacen difusión entre sus compañeros, seguro que acabaré teniendo más visitas. ;-)

@@nettorius Donde me lío más en las cardinalidades mín/max de una ternaria. Te pongo un ejemplo. Empleados llevan las cuentas de los clientes. Los empleados pueden ir cambiando. Pero no todos los empleados del banco llevan cuentas. Entiendo ternaria entre empleados, cuentas y empleados. 1 cliente con 1 cuenta puede ser llevada por N empleados. 1 Emp que tiene 1 cliente puede gestionar N cuentas. 1 Cuenta gestionada por 1 empleado puede pertenecer a N clientes. Hasta aquí bien Una ternaria N:M:P. Pero cuando pongo la cardinalidad minima. Como no todos los empleados pueden llevar cuentas, pero los clientes sí tienen que tener mínimo una cuenta, qué cardinalidad pongo en cuentas. Tengo 1,N desde clientes y 0,N desde empleados. ¿Cómo lo ves?

Vale, creo que ya tengo la respuesta. He visto en una de tus respuestas, que para saber si hay una ternaria o no, la cardinalidad mínima en las 3 deberá ser 1. Por lo tanto si tengo una de las binarias con cardinalidad mínima 0, como es el caso de empleados llevan cuentas, dónde NO todos los empleados llevan cuentas, este 0, me arruina la posibilidad de que sea una ternaria, ¿correcto?

Contestado en otra de tus preguntas. :-) La que dices: Las cardinalidades mínimas, ¿se preguntan igual? (en el video 11b)

Contestado en otra de tus preguntas. :-) La que dices: Las cardinalidades mínimas, ¿se preguntan igual? (en el video 11b). Allí te respondo con mucho detalle. Pero la conclusión técnica y cierta es: Entonces un criterio que nos puede ayudar para determinar si una interrelación es ternaria, es pensar que: -Si en una RAMA la cardinalidad máxima es MUCHOS, entonces la mínima DEBE SER 1. Si fuera 0, entonces NO es ternaria. -En las ramas donde la cardinalidad máxima es 1, entonces se permitiría tener una mínima de 0. Pero SÓLAMENTE PUEDE HABER UNA RAMA con esas características. Es decir, si tienes una candidata a ser ternaria (lo estás discutiendo), y es del tipo 1:1:N . Entonces no puedes tener a la vez en las dos ramas con el 1 la cardinalidad mínima 0, porque entonces (en el modelo Relacional) tendrías un NULL en un atributo que forma parte de la PK (porque recuerda que en ese caso, la PK está formada por una pareja: la del lado N (obligatorio) y una de las del lado 1)

Sí , es correcto.... más o menos. Se tiene que matizar. Lo intento explicar aquí, pero quizá haría falta un video para entenderlo mejor. Si realmente tenemos una "ternaria", le habríamos podido bajar el grado mediante asociativas, para tener sólo interrelaciones de grado 2 (o binarias). Pero al revés no es cierto: si partimos de una binaria, y luego vemos que podemos hacer otra interrelación desde el "rombo" (sería una posible candidata a ser ternaria), hemos de decidir si podría ser ternaria realmente o no. ¿Y qué criterio seguimos? Pues yo miro si la "nueva interrelación binaria" (desde la "asociativa") tiene cardinalidad mínima 1 (es decir, siempre se va a interrelacionar con alguna instancia del rombo). Pero si va a tener cardinalidad mínima 0 (cero) y máxima N, entonces NO la pondría como ternaria (SÓLO sería posible ternaria si LA CARDINALIDAD MÁXIMA FUERA 1), . Básicamente porque cuando la pasemos a Tablas (Modelo Relacional) necesitaremos que la nueva PK forme parte de la PK compuesta de la supuesta "ternaria", y como algunas "parejas" del rombo no se van a relacionar con ninguna del otro lado, tendría un valor NULL en un atributo que formaría parte de la Clave, lo cual no es posible. El ejemplo de la ETT ERA un buen intento para entenderlo. Pero en este caso resulta que sí sería POSIBLE modelizarlo como ternaria (aunque no lo aconsejo, porque al ser "CONTRATO" una entidad propia, prefiero vincularla a la "ENTREVISTA" y hacer una binaria entre ellas. ¿Por qué es posible modelizarlo como Ternaria? Explico: Empresas "hacen entrevistas" a Personas: Una empresa puede entrevistar a N personas. Una persona puede ser entrevistada por M empresas. Esa binaria es N:M Ahora intentamos la "ternaria": miramos la interrelacion entre el "rombo" anterior (la asociativa "ENTREVISTA") y el CONTRATO: una entrevista puede dar (0,1) contratos, es decir, ninguno (la mínima) o 1 contrato la máxima. En sentido inverso de la binaria: Un contrato está vinculado a 1 entrevista (pareja persona-empresa). TOTAL: si la miramos como "Ternaria" sería N:M:1 (Persona:Empresa:Contrato) Eso quiere decir que cuando lo pasemos a tablas, la PK de la Ternaria sería sólo (id_persona, id_empresa), porque NO hace falta que id_contrato forme parte de la PK. Y entonces las "entrevistas" que NO dieron resultado pueden tener perfectamente un NULL en ese valor, porque NO forma parte de la PK. Creo que debería hacer un video explicando estos casos ... Si tengo tiempo algún día lo haré. Saludos

@@nettorius Buenas. Si trabajo como Ternaria la ETT, y analizo las cardinalides máximas, 1E que entrevista a 1P puede hacerle 1C. 1C hecho por una E sería a 1P. 1P que consigue un C sólo puede ser por 1C. O sea 1:1:1. Si lo hago como has comentado por parejas Emp-per, contrato-empresa, persona-contrato.

¡ Genial! La verdad es que no conocía ese ejemplo, pero ilustra perfectamente lo que te he comentado en otra respuesta sobre las ternarias. En este caso tenemos claramente una candidata a ternaria del tipo 1:1:1. Ahora vemos que de las 3 ramas posibles, sólo en una de ellas puede tenerla mínima 0 (en las otras observa que la mínima es 1, porque en la pareja implicas el "contrato", y el contrato por fuerza debe estar asociado a 1 persona, y hecho por 1 empresa). Entonces, cuadra con lo que te dije para ser ternaria: en las ramas donde la máxima es 1, sólo puede haber una rama con la mínima 0. Y como este es el caso, se podría hacer la ternaria, porque en la tabla que aparece con la ternaria, la clave primaria estaría formada por (empresa_id, persona_id). El contrato_id podría valer NULL (no forma parte de la PK) para aquellas "entrevistas" que no dieron contrato. Ahora todo cuadra.

@@nettorius Muchas gracias por tu empeño en que confirme mis conclusiones y avance en mi conocimiento.

Lo explico en el video: se puede hacer un asociativa de CUALQUIER interrelacion ("rombo"), sea binaria o ternaria, o de cualquier grado. PERO la intención cuando pones la ASOCIATIVA es para poder hacer una NUEVA INTERRELACIÓN que parte de ella hacia otras Entidades. Es decir, si no vas a hacer una nueva interrelación que parte del rombo, NO ES NECESARIO recuadrarla, porque no vas a necesitar la asociativa. Por eso en un diagrama ER sólo aparecen entidades asociativas en casos contados.

Buena pregunta. A veces las dos opciones son correctas. Depende de las preferencias personales, y tener en cuenta las repercusiones de ambas opciones al pasar al Modelo Relacional (tengo videos que lo explican). La simplicidad del modelo te puede ayudar. La subordinacion de entidades también. Las ternarias, si aparecen, son todavía fáciles de entender. Yo las pondría. Porque rebajar las interrelaciones a grado 2 (o binarias) suele hacer que aparezcan más tablas. Pero las interrelaciones de grado 4 o superior son más difíciles de entender (y justificar), y por eso se usan las asociativas (lo que tú llamas agregación).

Gracias a ti por comentar. Me alegra de que te haya servido para aprender.

Gracias a ti por comentar. Me alegra de que te haya servido para aprender.

Gracias a ti por comentar.

Gracias a ti por comentar. Me alegra de que te haya servido para aprender.

Gracias a ti por comentar. Me alegra de que te haya servido para aprender.

Gracias por la aclaración . He aprendido una nueva palabra en inglés. ;-)

Gracias a ti por comentar. Me alegra de que te haya servido para aprender.

Gracias a ti por comentar. Me alegro de que te hayan servido para aprender.

Gracias a ti por comentar. Aunque no todos los profesores que estan en youtube son iguales. Y muchos de los profesores que estan en youtube también lo son de colegios e institutos (como es mi caso). Pero es cierto que profesores los hay de todos los tipos. Hay algunos muy buenos por el mundo, y otros que sería mejor que se dedicasen a otra cosa. En fin.

Hola Jessica. Me alegro de que te gusten mis videos. Por falta de tiempo no tengo un canal aparte con más materiales. Me lo estoy planteando pero de momento tengo que posponerlo. También me planteaba poner un enlace de PayPal (donacion voluntaria), porque hacer videos supone un gran esfuerzo, pero la "monetización" por anuncios es ridícula, y más en un canal de contenido cultural tan específico donde los suscriptores son pocos. En fin, de momento la satisfacción que me dáis cuando ponéis un bonito comentario ya es suficiente. Gracias.

Profesor muchas gracias por responder. Podria considerar subir una clase a la plataforma de UDEMY, ahi puede desarrollar cursos como este mas detallados en los cuales uno puede comprar. Ojala lo considere ya que profesores como usted ya practicamente no se ven. Muchas gracias.

Hola. Tienes razón en tus apreciaciones. El ejemplo lo pongo para ilustrar el concepto. Es una primera aproximación. Pero cuando la realidad hace que algo sea más complejo, entonces debe cambiarse el modelo para poder adaptarse. Es lo que comentas de añadir la fecha para poder permitir que exista en el tiempo. Trato ejemplos así en algún video. Por ejemplo: las PERSONAS visitan CIUDADES es claramente N:M. En la interrelacion tenemos instancias del tipo (p2,c5) , queriendo decir que la persona 2 ha visitado la ciudad 5. Pero si queremos modelizar CUANDO la ha visitado, y queremos permitir que una persona vuelva a la misma ciudad en diferentes fechas, esa pareja se debe repetir en el tiempo, y entonces hacemos una "ternaria" con FECHA para poderla incluir en la clave primaria.

Tú lo que buscas es como se representa gráficamente una jerarquía EXCLUSIVA. Se representa con un "arco" entre las interrelaciones disjuntas. En el futuro debería hacer un video explicandolo. Mientras tanto tienes un ejemplo gráfico en esta página: www.danielbenvenuto.com/EDUCACION/EBD-I/Unidad_II/Unidad_II.htm

@@nettorius ya veo, creo que lo que busco es efectivamente que sea exclusiva y parcial. No conocía el termino de exclusividad en el E/R, si conocía total,parcial,solapada y disjunta. Es exactamente lo que buscaba, ni chatGPT me pudo decir esto luego dirán que la IA quitará trabajos...desde luego que a profesionales no. Mil gracias, si hubiera algún vídeo genial que tus tutoriales son los más esclarecedores. Un saludo!

@@Juicio87 pero disjunto y exclusivo no son lo mismo?

@@liamgg1217 sí sí, yo lo estudie como disjunto y solapado así que evidentemente disjunto es lo mismo que exclusivo me equivoqué. Eso hace que mi duda siga vigente (o tengo que releer bien el documento que pasó nettorius). El tema es que en el caso que digo un empleado puede ser alumno y profesor pero no en la misma edición y aunque suene evidente aún no sé como se representa eso en el modelo E/R. Es decir, es solapado pero con matices porque no puede ocurrir al mismo tiempo en la misma edición (si es total o parcial no importa tanto). Creo que al ser una condición debo reflejarlo cuando creo la base de datos, quizás en el modelo E/R bastaría con una anotación aunque si es así ya pierde algo de gracia. A no ser que como dice nettorius deba representarlo como exclusivo, pero tenía entendido que de esta manera o es alumno o es profesor pero es que mientras es profesor puede ser alumno de otra edición xD

@elianasanchez6607 hace 3 minutos Con respecto a lo que estais planteando, voy a dar una idea, estoy empezando y no se si será correcto, pero yo creo que una cosa es la jerarquia de empleados, y otra diferente el tema de las interrelaciones imparte-recibe, en la que yo meteria una exclusion que se representa con una linea discontinua entre las dos relaciones.Esto se refiere a restricciones de relaciones que pueden ser de exclusividad, exclusion, inclusividad e inclusion por si lo quereis buscar

En las entidades débiles, si piensas en la entidad te haces un lío, porque ves "debilidades" por todas partes. Pero tienes que pensar en términos de "instancias", es decir concreciones de la entidad. Decimos que una "entidad es débil si depende existencialmente de otra". Sólo puede depender de 1 (nunca de muchos, porque entonces no puede ser débil). En tu caso la relacion entre PARTIDOS y JUGADORES es N:M (1 partido es jugado por muchos jugadores, y 1 jugador puede jugar muchos partidos). Pero cuidado: no todas las relaciones 1:N son débiles. Una entidad es débil respecto de otra (que es fuerte), si al coger una instancia de la entidad débil, esta DEPENDE existencialmente de 1 instancia (concreta) de la fuerte. Y además NO puedes relacionarla con otra diferente. Vamos, que no podrías cambiarla por otra. Ejemplo 1: Equipo tiene Jugadores: cogemos 1 jugador concreto. Este juega en 1 equipo. Ok. Pero ¿podríamos cambiarle de equipo si ficha por otro? Sí. Con lo cual no dependía existencialmente de ese equipo en particular. Le puedes asociar cualquier otro equipo. Es decir, la información del jugador tiene sentido por sí misma, no depende del equipo, y no se ve mermada si desaparece la informacion de un equipo. Ejemplo 2: Las PERSONAS tienen PASAPORTES (es 1:N porque una persona podría tener varios pasaportes (si tiene varias nacionalidades), pero 1 pasaporte pertenece a 1 persona CONCRETA (sí o sí), y nunca podremos asociar ese pasaporte concreto a OTRA persona diferente. No podemos escoger el 1 con el que está relacionado. En este caso esta interrelación es claramente DÉBIL. Estoy pensando en hacer un video que explique mejor el concepto de DEBIL y cómo reconocerlas fácilmente.

Gracias a ti por comentar. Me alegra de que te haya servido para aprender.

Es cierto. Pero eso sólo ocurre para un empleado (el jefe supremo). Y siempre se puede considerar que dicho jefe es subordinado de sí mismo. La cardinalidad es algo genérico, que miras para todos los empleados. Si en esa interrelación pones 0..1 (0 como mínima) , se está dando la sensación de que dado un empleado "cualquiera", puede no tener un jefe. Y yo no quería que se pensase eso. Pero si quieres considerar la realidad que planteas, es correcto lo que dices.

Gracias a ti por comentar. Me alegra de que te haya servido para aprender.

Si mi entidad fuera TEMPORADA, le pondría como clave primaria id_temporada, y otros atributos las fecha_inicio y fecha_fin. Al discutir las cardinalidades de la ternaria, quedaría también N:M:1: 1) un ciclista en una temporada sólo puede estar en 1 equipo 2) un ciclista en un equipo puede estar en N temporadas 3) un equipo en una temporada tiene a M ciclistas. En este caso la ternaria tendría los atributos (id_ciclista, id_temporada, id_equipo, salario,...), y la PK estaría formada por (id_ciclista, id_temporada). Y la tabla TEMPORADA NO la quitaríamos, para poder ver la fecha de inicio y fecha de fin de cada temporada.