Acabo de terminar el anterior hace unos dias y la verdad que en todo youtube este es el mejor curso en español que hay, tanto para principiantes como para reforzar comocimientos, tu labor es impresindible, siga asi!
Tal cual, soy desarrollador Front-End y por cuestiones laborales tuve que volver a repasar el Back-End, este curso esta resumido en los 5 años de mi carrera...
saludos muchas gracias soy autodidacta trabajo cortando tela estampado en el dia, voy empezando mi empresa de software con firebase y react consegui algunos clientes las personas lo aprecian mas a uno por resolver sus problemas de automatizacion. Un sueño cumplido gracias a todas las personas como tu espero poder retribuirles, ahora voy en la etapa de escalar por que los clientes me van exigiendo cosas que se solucionan con sql estadisticas y php para manejar el backend minimizar costos por que los servidores dedicados son mas costosos todavia las versiones son muy basicas como para que justifiquen el cambio, aveces cosultas que se exeden en estos tiempos quieren hacer todo online ademas las campañas pagas que les suman muchas visitas
3:16:54 que buena que esté modelado de saint Seiya tomaste en cuenta la relación de una tabla así misma y la de que se pueden tener 2 o más FK de una misma tabla dependiendo de las reglas de negocio. Muy genial que cubras estás cosas más complejas de modelado.
3:11:35 Excelente aprendizaje de este quinto modelo, a pesar que el modelo entidad relación está más relacionado con las BDs relaciones te das la tarea de explicar cuando usar BDs no SQL, muy buena sección.
Finalmente termine este segundo curso de base de datos. Nunca habia tenido tanta informacion y conceptos unidos de este tema. Me gusto la metodologia y contenido del curso; es una exelente referencia para cualquier persona interezada en ello. Mil gracias y seguro que te vuelvo a invitar a varios tacos!!!!
Listo ya los 2 primeros cursos, vamos ahora por el de SQL. Infinitas gracias @jonmircha por aportar tu conocimiento y experiencia. Oro puro estos cursos.
*00:04:12** Corrección* ruclips.net/video/HXE169-n5pM/видео.html *00:17:05** Entidad de Datos Vs. Entidad de Catálogo* *00:21:14** Entidad Pivote* *00:57:03** Lógica de negocio* *01:02:25** Sistema de encuestas*
Mil gracias por el curso. El más completo y ameno de los que he seguido, genial para refrescar conceptos. Tengo una duda sobre el primer ejemplo: - La relación de las tablas cliente-pais debería ser 1-N, en caso contrario un pais solo se podría asignar a un cliente. - La relación ventas-productos es una relación N:N, lo que genera la tabla artículos_x_ventas... La relación de la tabla ventas con la tabla articulos_x_ventas y la tabla productos con la tabla articulos_x_ventas deberian ser 1:N. Así lo veo yo.
3:59 Justo iba a preguntar esto en el curso anterior, de porque era 1 a 1 las dos relaciones y no 1 a M según lo explicado en la sección de relaciones del curso anterior, que bueno aclararlo en este, excelente.
4:33:17 Me encantó este curso, creo que de los mejores del canal, ya que es muy difícil ver un curso tan práctico de modelado en RUclips o alguna plataforma que sea de calidad y muy bien explicado. Súper el modelado final que es de un proyecto real en el que has trabajado, muy buen ejemplo para terminar este curso. Muchas gracias, ahora a seguir con el de SQL.
Gracias por aportar tanto conocimiento de manera gratuita! Relacionado al curso (además de estar excelentemente hecho, como siempre) lo he podido entender muy bien. Todavía me cuesta un poco la especificidad de ciertas validaciones en las reglas de negocio y las entidades pivote. Pero no porque las hayas explicado mal. Todavía estoy terminando de comprenderlas.
Jon, buenas noches. Te agradezco el don que tienes para compartir magistralmente tus concocimientos por medio de tus publicaciones en este canal, en tus redes sociales y en tu sitio web. Felicitaciones. Quiero comentarte que en el modelo de Autenticaciones, creo que hay una relacion que se puede revisar y es que la entidad usuarios las relacionas con permisos c roles pero las claves con se corresponden !!!! Saludo cordial
Excelente curso y aprendo demasiado contigo. Con todo respeto estaria perfecto que te enfoques en el contenido del curso y no te desvies tanto del tema, ya que no todos conocemos de los caballeros del zodiaco, armaduras, etc. Es entendible que te apasione ello pero solo enfócate en el curso. Fuera de eso todo esta excelente. Muchas gracias por tus cursos!📚🇲🇽🙌🏼
Otro excelente curso, mil y mil gracias profesor por su tiempo y esfuerzo, me sirvió muchísimo, precisamente por estos días me dejaron una un ejercicio sobre hacer el modelo relacional de un proyecto y gracias a sus explicaciones se me hizo muy sencillo. Saludos y muchos éxitos.
Aún me acuerdo cuando aprendí lo básico hace unos 3 años con tu curso de javascript. Ahora Jon, tengo más de 1 año de experiencia y tengo perfil SSR (le metí muchísimas horas)
2:19:17 Ya en el cuarto modelado y la verdad que este es el mejor curso de modelamiento y diseño de base de datos, muy difícil encontrar un curso ya sea gratis o de paga de modelado con muchos ejemplos del mundo real, la mayoría de veces enseñan la teoría de las bases de datos relacionales, pero no te enseñan la diferencia de lógica de negocio y reglas de negocio, no te enseñan cuando usar SQL o noSQL. De verdad este hasta el momento está siendo de mis cursos favoritos por existir pocos cursos de este tema con ejemplos reales y además de ser un tema complejo que es el diseño de una BD.
Jon, realmente agradecido por todo tu conocimiento y compromiso con la educación. Desde que conocí tu canal no paro de aprender (y querer aprender más). Impresionante lo que me sirvió este curso para aprender a modelar (y para aprender de los caballeros del zodiaco 🤣). Realmente agradecido, iré comentando de a poco en todos los vídeos que he visto. Y a futuro me encantaría un curso de Vue si pudieras hacerlo.
29:20, hola profesor esta parte donde mencionas que la entidad cliente y pais tienen una relacion de 1A1 pero tambien podria ser de 1AM , es la parte que se me hace confuso, ya que al estar practicando tambien me surge esa duda ya que viendolo de muchas formas 2 entidades podrian tener relaciones de 1A1 y tambien de 1AM, que criterio debemos usar para elegir la cardinalidad correcta ?
Saludos profe. Tengo una duda, en el minuto 57 en las reglas de negocio de la DB, en la tabla de productos cosas como reducir la cantidad de un producto si este se usa en una venta, también puede ser una que pues aumente la cantidad de un producto si se agrega nueva cantidad al mismo? y otra que al llegar la cantidad a 0 el producto sea "bloqueado" y no pueda ser usado en ventas por el momento? No se si esto son reglas, si es algo que simplemente es obvio y no hace falta indicarlo o si es algo externo a la DB y son cosas que hace el desarrollador. Y lo otro es por que en articulos_x_ventas se da la regla de leer todos los artículos vendidos a un cliente, de que forma podríamos buscar eso en esa tabla si la que contiene la informacion del cliente es la tabla de venta y la de artículos solo tiene es produco_id y venta_id. Es decir, visualmente en la tabla artículos no se ve ninguna informacion del cliente, solo la tabla ventas es donde tenemos el id, por ahora me lo imagino como si en excel intentaramos usar un filtro en la tabla articulos para buscar todos los registros de un cliente pero no tenemos nada que nos indique que cliente es. Aun asi esto se podria con SQL? aun no he llegado alli Gracias por toda el aprendizaje que nos brindan Jon
Recuerda que es un ejemplo hipotético, toda mejora o implementación es viable, todo dependerá de las reglas de negocio y de las necesidades del proyecto 👋🏻😉
2:06:59 coloque "M-1" Muchos usuarios pueden estar asociados a un único país. Cada usuario está en un solo país, pero un país puede tener muchos usuarios. Estara bien Jon? ya que vi no tenia sentido colocarlo (1-M) o da igual el sentido?
Hola Jon, antes que nada agradecerte por tu dedicacion a la enseñanza y por la calidad y claridad con la cual lo hace. Te queria consultar por el Modelo relacional del ejercicio de Sistema de Autenticacion, no me quedo claro porque hay una relacion M-M entre "usuario_id" y "rol_id" entre las entidades "usuarios" y "permisos_x_roles".
Esa misma observación iba a realizar yo...Profe Mircha por qué se relacionan usuario_id con el rol_id?, pienso que debería ser todo horizontal en el diagrama...es decir; usuarios > roles_x_usuarios > roles > permisos_x_roles > permisos
@@rogerreyes4470 Muy buena observación, yo también pienso igual. Debería ser todo lineal (horizontal). Por eso creo que es mejor hacer estos diagramas con MySQL Workbench ya que al colocar las lineas de relación automaticamente crea las FK y en el caso de la relación muchos a muchos crea tambien la entidad pivote, esto es genial ya que disminuye el margen error al relacionar, pero en general es un gran curso del maestro @jonmircha.
Todas las relaciones serían 1:N, en lugar de N:N. Las relaciones N:N son entre usuario y roles | roles y permisos. Las relaciones de muchas a muchas (m:n) añaden complejidad y confusión al modelo y al proceso de desarrollo de aplicaciones. La clave para resolver relaciones m:n es separar las dos entidades y crear dos relaciones de una a muchas (1:n) entre las mismas con una tercera entidad de intersección. La entidad de intersección suele contener atributos procedentes de ambas entidades de conexión.
Saludos, seguimos aprendiendo con este fantástico curso. Puede ser que en el primer modelo-relacional esté mal la relación entre ventas-artículos? No debería ser al revés? En una venta muchos artículos? Tal como está en la imagen hay en un artículo muchas ventas.
Buen punto, yo tambien me fijé en eso y de hecho John lo habia dicho en el video anterior, tal vez se equivicó o fué una concha de mango para que aprendamos a fijarnos en los detalles jaja
Hasta el minuto 5:00 (no sé si más adelante lo cambiaste...) la dirección de uno a muchos en carreras con tipo de carreras, y carreras con países, me parece que está a la inversa. Colocas: 1:n carreras ->tipos_carreras 1:n carreras->paises Y debería ser: 1:n tipos_carrera->carreras 1:n paises->carreras En el análisis aprendí hacerlo así: Una carrera tiene un tipo de carrera (1:1) -> carrera - tipo_carrera (1:1) Un tipo de carrera está/tendrá varias carreras (1:n) -> tipo_carrera - carrera(1:n) Entonces quedándonos con el mayor: tipo_carrera - carrera(1:1) tipo_carrera - carrera(1:n) *tipo_carrera - carrera (1:n) (Sale del tipo de carrera hacía carrera)
Excelente curso maestro pero tengo una duda con respecto al ejercicio de autenticación. Hablando ya de un sistema creado con su interfaz definida. En que momento un usuario se le asignan los roles y/o los permisos?? porque en el modelo de la base de datos se plantean las relaciones pero no se aprecia en que punto el usuario llega a tener varios roles o al menos no lo noto.
Eso tendría que hacerse a la hora de crear el usuario, recuerda que la propuesta que hago en el curso, simplemente es un ejemplo básico, tendrías que analizar realmente lo que requiere tu sistema
@@jonmircha ya le capté la idea profe, no le había entendido bien. Eso sucede al crear el usuario. Una duda más profe en el modelado de la encuesta; entiendo que una misma encuesta puede tener muchos resultados, pero un encuestado según mi lógica solo puede tener un único resultado. Es decir que ese encuestado_id hará referencia al resultado que le pertenece a él.
Recien empiezo el segundo curso de gestores de bases de datos, gracias profe Jon por el conocimiento que compartes y enseñas, tengo una pequeña pregunta en el min 11:00 el atributo ciudad no podría ser una Entidad de Catálogo así como lo es país?, gracias, me encantan tus cursos, desde hace años los veo
@@jonmircha Hola profe Jon, teniendo en cuenta este curso de bases de datos quisiera saber si existe la posibilidad de que en un futuro no muy lejano nos puedas brindar un curso de Ruby on Rails, en mi empleo me tienen trabajando con esta tecnologia pero apenas la estoy aprendiendo y hay conceptos que aun no entiendo y los cursos que veo en RUclips son de hace 5 e incluso hasta 10 años, seria maravilloso que lo hicieras(si sabes Rails claro) siento que es un lenguaje muy bueno para interactuar con las bases de datos. Espero me leas, feliz dia :D
1:10:55 ## relaciones hola profesor aqui mi solucion al reto, la cardinalidad es algo confusa y he visto que algunos tienen respuestas distintas, pero por lo que voy entendiendo la cardinalidad que pueda tener un sistema va depender de la logica de negocio de que tendra la aplicacion y dependiendo de a que entidad le demos mas relevancia, la cardinalidad cambiara? una **encuesta** _tiene_ preguntas (_1 a M_)('en caso que la encuesta tenga una sola pregunta podria cambiar') una **pregunta** _tiene_ una respuesta (_1 a 1_)('si consideramos solo la que es correcta') un **resultado** _pertenece_ a una sola encuesta (_1 a 1_) un **resultado** _pertenece_ a un solo encuestado (_1 a 1_) un **encuestado** _realiza_ varias encuestas (_1 a M_)('si tenemos un sistema que haga encuestas de manera periodica' )
Cuando ví estos conceptos en la universidad, se nos enseñaba que la entidad con la cardinalidad más fuerte es la que guardaba como llave foránea la llave primaria de la entidad más débil. Esa son una de las cosas que se pueden ver (visualmente) más claro en el diagrama entidad relación a diferencia del modelo relacional. En lo personal también considero que debería existir una forma más sencilla de hacer esto porque ciertamente se vuelve muy extenso al hacerlo todo en un diagrama ER (aunque sea necesario)... es como comentas nada está escrito en piedra.
Tengo otra consulta, del ejercicio de "MirChaGraM", en las reglas de negocio enla seccion #user se podria poner como regla -habilitar un user y tamb -Inhabilitar un user? y la otra duda es si "contar el numero de comments de un post es igual a decir "incrementar en uno cada que un post tenga un comments"?
- Una **Encuesta** puede ser *realizada* por varios **encuestados** (1 a M) - Una **Encuesta** puede *tener* muchas **preguntas** (1 a M) - Una **Pregunta** *tiene* una **respuesta** (1 a 1) - Un **resultado** *pertenece* a una **encuesta** (1 a 1) - Un **resultado** *pertenece* a un **encuestado** (1 a 1) Así fue como yo lo hice XD
Jon, en la entidad usuarios y la entidad permisos_x_roles, colocas una flecha de relacion que me parece no corresponde a la definicion. yo creo que la correcta es de la entidad roles a la entidad permisos_x_roles.
John una pregunta, en el caso del alias de Mirchagram que tenías como PK antes de modificarlo; si el usuario quisiera cambiarse el alias y con esto se hiciera un UPDATE ON CASCADE...¿no cambiaría en el resto de tablas hijas y por tanto seguiría manteniendo las relaciones? Igualmente, al ser una PK no me gusta la idea tampoco de que se pueda modificar porque puede dar lugar a fallos imagino pero me vino a la cabeza el CASCADE y me preguntaba esto que te comento
Tengo una pregunta, en el caso de las entidades Catalogo, por ejemplo, la entidad pais que tiene ya muchos paises precargados, a la hora de crear la tabla en sql, agrego todos los paises asi?
Primero q nada felicitarte por tu contenido, tengo una duda, en el ejercicio de autenticación de usuarios hay una entidad pivote que se llama permiso por roles, no debiera estar unida a las entidades permiso y roles respectivamente? o en todo caso llamarse permisos_x_usuario?
Hola Jon. En el primer ejemplo (ventas) dices que la relación entre la entidad "artículos_x_venta" y la entidad "producto" es 1 a 1 , ¿por qué? No lo acabo de ver. ¿No sería 1 a N? Según cómo lo veo: 1 "articulos_x_venta" tienen 1 "producto" pero 1 "producto" pertenece a N "artículos_x_venta". Tú compras 5 televisiones ( artículo_id = 1 + producto_id=T ) y yo compro 1 televisión y 1 plancha (artículo_id = 2 + producto_id = T, artículo_id = 3 + producto_id = P)...tenemos que tanto artículo_id =1, como artículo_id = 2, como articulo_id=3 tan solo tienen 1 producto (T , T, P, respectivamente), o sea 1 a 1; sin embargo producto_id = T lo encontramos tanto en articulo_id = 1 como en artículo_id = 2, o sea 1 a N. La cardinalidad me genera bastante confusión, tan solo quiero saber si hay un error o yo estoy ya echando humo por la cabeza jajaja. Muchas gracias por tus videos!
Profe una duda, en el modelo relacional entre peliculas - paises y paises - series, a como esta planteado no va la FK en la entidad paises? pienso que la relación esta invertida.
critica constructiva? puedo? la corrida de datos termina de decantar todo lastima que no todos los ejercicios la tienen, sobre todo en el de las encuestas cuesta mucho agarrarle la logica, no x la base de datos de datos en si sino por la logica de negocio, el resto es una maravilla y gratis, mil gracias john
No lo entiendo bien, por ejemplo el registro de Caballero tiene (a lo largo de la serie puede cambiar) varias armaduras. Por otro lado una armadura puede haber sido tenida por muchos caballeros. Yo veo una relación de M a M. Es decir el registro llamemosle 25 de la tabla caballeros se puede relacionar con 4 registros de armaduras, a su vez un registro de la tabla Armaduras, llamemosle 02 y es la armadura de Capricornio se puede relacionar con varios registros de la tablla Caballeros, pues una armadura ha podido ser tenida por varios caballeros. Vamos, M : M.
vale estoy intentando hacer un modelado de una base de un posible proyecto personal me puedes ayudar porfa , estoy enredado segun yo tengo 3 tablas cliente (cada uno de los cliente) - uid_client (PK) -...demas atributos Compras (las compras que el cliente hizo conmigo y portanto genera una deuda ) - uid_compras (PK) - uid_client (FK) - ... demas atributos Pagos (pagos del cliente para disminuir la deuda) - uid_pagos(PK) -uid_client(FK) -..demas atributos segun entiendo necesito una entidad pivote para relacionar los pagos con las compras y llegar a un total de la deuda , pero no estoy consiguiendo pensar en como provablemente es mas facil de lo que parece pero esas cardinalidades me confunde en la definicion AYUDAAAA!!! porfa :3
El ultimo modelado me quedo de esta manera ## Listado de entidades ### Actividades - id **(PK)** - nombre ### Horario - id **(PK)** - id_actividad **(FK)** - lugar - hora - cupos ### Registro - id **(PK)** - id_horario **(FK)** - nombre - apellido - email **(UQ)** - fecha_nacimiento Como lo ven?
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
Acabo de terminar el anterior hace unos dias y la verdad que en todo youtube este es el mejor curso en español que hay, tanto para principiantes como para reforzar comocimientos, tu labor es impresindible, siga asi!
👋🏻😉
Tal cual, soy desarrollador Front-End y por cuestiones laborales tuve que volver a repasar el Back-End, este curso esta resumido en los 5 años de mi carrera...
el mejor contenido en RUclips, gracias JONMIRCHA.
👋🏻😉
este canal vale mil 😊 vamooos aprendiendo
Mil gracias!!
👋🏻😉
saludos muchas gracias soy autodidacta trabajo cortando tela estampado en el dia, voy empezando mi empresa de software con firebase y react consegui algunos clientes las personas lo aprecian mas a uno por resolver sus problemas de automatizacion. Un sueño cumplido gracias a todas las personas como tu espero poder retribuirles, ahora voy en la etapa de escalar por que los clientes me van exigiendo cosas que se solucionan con sql estadisticas y php para manejar el backend minimizar costos por que los servidores dedicados son mas costosos todavia las versiones son muy basicas como para que justifiquen el cambio, aveces cosultas que se exeden en estos tiempos quieren hacer todo online ademas las campañas pagas que les suman muchas visitas
😉👋🏻
Magnífico curso, igual que el anterior, y seguro que igual que el siguiente! Enhorabuena, maestro! :)
👋🏻😉
Muchas gracias por su apoyo y dedicación con estos cursos y poner su conocimiento al alcance de todos 🙌🏻🤝🏼
👋🏻😉
Vamos por el siguiente curso💪
👋🏻😉
Listo con los 2 primeros cursos, ahora me voy al de SQL. Un agrado aprender con Jon. Muchas gracias por tanto!
👋🏻😉
3:16:54 que buena que esté modelado de saint Seiya tomaste en cuenta la relación de una tabla así misma y la de que se pueden tener 2 o más FK de una misma tabla dependiendo de las reglas de negocio. Muy genial que cubras estás cosas más complejas de modelado.
👋🏻😉
Estoy verdaderamente agradecido por impartir sus conocimientos a todos nosotros , muchas gracias maestro!!
👋🏻😉
3:11:35 Excelente aprendizaje de este quinto modelo, a pesar que el modelo entidad relación está más relacionado con las BDs relaciones te das la tarea de explicar cuando usar BDs no SQL, muy buena sección.
👋🏻😉
QUÉ GRAN CURSO ... estoy al 100 ...Gracias totales profe.
👋🏻😉
Profe Jon muchas gracias por compartir sus conocimiento ya llevo 2/3
👋🏻😉
Finalmente termine este segundo curso de base de datos. Nunca habia tenido tanta informacion y conceptos unidos de este tema. Me gusto la metodologia y contenido del curso; es una exelente referencia para cualquier persona interezada en ello. Mil gracias y seguro que te vuelvo a invitar a varios tacos!!!!
👋🏻😉
Profe jhon comencé recién en sus cursos y son una completa joyita, va a estar buenazo el curso de modelado de datos
👋🏻😉
Buen video, cada vez mas estoy aprendiendo sobre base de datos y su normalizacion.
Excelente!👋🏻😉
Listo ya los 2 primeros cursos, vamos ahora por el de SQL. Infinitas gracias @jonmircha por aportar tu conocimiento y experiencia. Oro puro estos cursos.
👋🏻😉
*00:04:12** Corrección* ruclips.net/video/HXE169-n5pM/видео.html
*00:17:05** Entidad de Datos Vs. Entidad de Catálogo*
*00:21:14** Entidad Pivote*
*00:57:03** Lógica de negocio*
*01:02:25** Sistema de encuestas*
👋🏻😉
El mejor curso de base de datos!!!!!!
👋🏻😉
Mil gracias por el curso. El más completo y ameno de los que he seguido, genial para refrescar conceptos. Tengo una duda sobre el primer ejemplo:
- La relación de las tablas cliente-pais debería ser 1-N, en caso contrario un pais solo se podría asignar a un cliente.
- La relación ventas-productos es una relación N:N, lo que genera la tabla artículos_x_ventas... La relación de la tabla ventas con la tabla articulos_x_ventas y la tabla productos con la tabla articulos_x_ventas deberian ser 1:N. Así lo veo yo.
👋🏻😉
3:59 Justo iba a preguntar esto en el curso anterior, de porque era 1 a 1 las dos relaciones y no 1 a M según lo explicado en la sección de relaciones del curso anterior, que bueno aclararlo en este, excelente.
👋🏻😉
¡Buenísimo el curso! ¡Muchas gracias!
Con mucho gusto👋🏻😉
4:33:17 Me encantó este curso, creo que de los mejores del canal, ya que es muy difícil ver un curso tan práctico de modelado en RUclips o alguna plataforma que sea de calidad y muy bien explicado.
Súper el modelado final que es de un proyecto real en el que has trabajado, muy buen ejemplo para terminar este curso.
Muchas gracias, ahora a seguir con el de SQL.
👋🏻😉
MUchas gracias profe.. Señores sigan a este profesor .. este es un excelente curso de Bases de Datos.. Saludos desde Venezuela (21/03/2023)
👋🏻😉
Curso terminado, espero con ansias el curso de SQL. Muchas gracias por compartir tu conocimiento Maestro
😉👋🏻
Gracias por aportar tanto conocimiento de manera gratuita! Relacionado al curso (además de estar excelentemente hecho, como siempre) lo he podido entender muy bien. Todavía me cuesta un poco la especificidad de ciertas validaciones en las reglas de negocio y las entidades pivote. Pero no porque las hayas explicado mal. Todavía estoy terminando de comprenderlas.
👋🏻😉
ni media naranja ni cuentos , somo polos o puestos jajajaja en las relaciones . Gracias por esos videos me están ayudando bastantes
😅👋🏻
Jon, buenas noches. Te agradezco el don que tienes para compartir magistralmente tus concocimientos por medio de tus publicaciones en este canal, en tus redes sociales y en tu sitio web. Felicitaciones. Quiero comentarte que en el modelo de Autenticaciones, creo que hay una relacion que se puede revisar y es que la entidad usuarios las relacionas con permisos c roles pero las claves con se corresponden !!!! Saludo cordial
👋🏻😉
Excelente curso y aprendo demasiado contigo. Con todo respeto estaria perfecto que te enfoques en el contenido del curso y no te desvies tanto del tema, ya que no todos conocemos de los caballeros del zodiaco, armaduras, etc. Es entendible que te apasione ello pero solo enfócate en el curso. Fuera de eso todo esta excelente. Muchas gracias por tus cursos!📚🇲🇽🙌🏼
👋🏻😉
Una taza de café para este buen hombre por favor.
☕️👋🏻😉
Excelente #curso de #modelado de #basededatos
Gracias por tu aporte y contenido!
Con mucho gusto👋🏻😉
Qué bien me viene este tutorial para repasar conceptos! Gracias por tanto
Con mucho gusto👋🏻😉
Otro excelente curso, mil y mil gracias profesor por su tiempo y esfuerzo, me sirvió muchísimo, precisamente por estos días me dejaron una un ejercicio sobre hacer el modelo relacional de un proyecto y gracias a sus explicaciones se me hizo muy sencillo. Saludos y muchos éxitos.
😉👋🏻
Me gusto mucho este curso, lo acabo de terminar y me encanto el modelado de Saint Seiya ya que soy fan desde chico de este anime
👋🏻😉
Aún me acuerdo cuando aprendí lo básico hace unos 3 años con tu curso de javascript. Ahora Jon, tengo más de 1 año de experiencia y tengo perfil SSR (le metí muchísimas horas)
👋🏻😉👏🏻👏🏻👏🏻
server side rendering?
@@gbarajas2971 Semi senior
2:19:17 Ya en el cuarto modelado y la verdad que este es el mejor curso de modelamiento y diseño de base de datos, muy difícil encontrar un curso ya sea gratis o de paga de modelado con muchos ejemplos del mundo real, la mayoría de veces enseñan la teoría de las bases de datos relacionales, pero no te enseñan la diferencia de lógica de negocio y reglas de negocio, no te enseñan cuando usar SQL o noSQL. De verdad este hasta el momento está siendo de mis cursos favoritos por existir pocos cursos de este tema con ejemplos reales y además de ser un tema complejo que es el diseño de una BD.
👋🏻😉
En verdad agradezco su apoyo y se ve que todo lo haces por que te gusta enseñar, sigue asi buen heroe de ingenieria en sistemas :3
👋🏻😉
ahora si se viene lo chidoooo!!!
👋🏻😉
Hola profe q ha pasado con el curso de sql q iba a estar el 11 d abril estoy ansiosa por verlo gracias por sus videos
Jon, realmente agradecido por todo tu conocimiento y compromiso con la educación. Desde que conocí tu canal no paro de aprender (y querer aprender más).
Impresionante lo que me sirvió este curso para aprender a modelar (y para aprender de los caballeros del zodiaco 🤣). Realmente agradecido, iré comentando de a poco en todos los vídeos que he visto. Y a futuro me encantaría un curso de Vue si pudieras hacerlo.
👋🏻😉
Eres un crack Jhon
Muchas gracias x compartir conocimiento de esta forma tan clara y practica
😁😁
👋🏻😉
Simplemente MUCHAS GRACIAS Jon estoy aprendiendo todo gracias a ti.
Con mucho gusto😉👋🏻
29:20, hola profesor esta parte donde mencionas que la entidad cliente y pais tienen una relacion de 1A1 pero tambien podria ser de 1AM , es la parte que se me hace confuso, ya que al estar practicando tambien me surge esa duda ya que viendolo de muchas formas 2 entidades podrian tener relaciones de 1A1 y tambien de 1AM, que criterio debemos usar para elegir la cardinalidad correcta ?
Es un pequeño error qu tuve y que corrijo en el siguiente curso la relación es 1 a M👋🏻😉
Saludos profe. Tengo una duda, en el minuto 57 en las reglas de negocio de la DB, en la tabla de productos cosas como reducir la cantidad de un producto si este se usa en una venta, también puede ser una que pues aumente la cantidad de un producto si se agrega nueva cantidad al mismo? y otra que al llegar la cantidad a 0 el producto sea "bloqueado" y no pueda ser usado en ventas por el momento? No se si esto son reglas, si es algo que simplemente es obvio y no hace falta indicarlo o si es algo externo a la DB y son cosas que hace el desarrollador.
Y lo otro es por que en articulos_x_ventas se da la regla de leer todos los artículos vendidos a un cliente, de que forma podríamos buscar eso en esa tabla si la que contiene la informacion del cliente es la tabla de venta y la de artículos solo tiene es produco_id y venta_id. Es decir, visualmente en la tabla artículos no se ve ninguna informacion del cliente, solo la tabla ventas es donde tenemos el id, por ahora me lo imagino como si en excel intentaramos usar un filtro en la tabla articulos para buscar todos los registros de un cliente pero no tenemos nada que nos indique que cliente es. Aun asi esto se podria con SQL? aun no he llegado alli
Gracias por toda el aprendizaje que nos brindan Jon
Recuerda que es un ejemplo hipotético, toda mejora o implementación es viable, todo dependerá de las reglas de negocio y de las necesidades del proyecto 👋🏻😉
Muy buen Curso de Base de Datos.
Hola, muchas gracias
👋🏻😉
Esté fin no se viene Netflix se viene Jhon mircha gracias sensei
👋🏻😉
2:06:59 coloque "M-1" Muchos usuarios pueden estar asociados a un único país. Cada usuario está en un solo país, pero un país puede tener muchos usuarios. Estara bien Jon? ya que vi no tenia sentido colocarlo (1-M) o da igual el sentido?
👋🏻😉 de las dos formas esta bien
Notificación activada gracias 🙋🏽♂️🙇🏽♂️
Excelente
Genial este curso, por favor, seri genial si el curso de codigo SQL lo hicieras con Postgres, sigo super atento !!!
👋🏻😉
Hola Jon, antes que nada agradecerte por tu dedicacion a la enseñanza y por la calidad y claridad con la cual lo hace. Te queria consultar por el Modelo relacional del ejercicio de Sistema de Autenticacion, no me quedo claro porque hay una relacion M-M entre "usuario_id" y "rol_id" entre las entidades "usuarios" y "permisos_x_roles".
Esa misma observación iba a realizar yo...Profe Mircha por qué se relacionan usuario_id con el rol_id?, pienso que debería ser todo horizontal en el diagrama...es decir;
usuarios > roles_x_usuarios > roles > permisos_x_roles > permisos
@@rogerreyes4470 Muy buena observación, yo también pienso igual. Debería ser todo lineal (horizontal). Por eso creo que es mejor hacer estos diagramas con MySQL Workbench ya que al colocar las lineas de relación automaticamente crea las FK y en el caso de la relación muchos a muchos crea tambien la entidad pivote, esto es genial ya que disminuye el margen error al relacionar, pero en general es un gran curso del maestro @jonmircha.
Todas las relaciones serían 1:N, en lugar de N:N. Las relaciones N:N son entre usuario y roles | roles y permisos.
Las relaciones de muchas a muchas (m:n) añaden complejidad y confusión al modelo y al proceso de desarrollo de aplicaciones. La clave para resolver relaciones m:n es separar las dos entidades y crear dos relaciones de una a muchas (1:n) entre las mismas con una tercera entidad de intersección. La entidad de intersección suele contener atributos procedentes de ambas entidades de conexión.
Saludos, seguimos aprendiendo con este fantástico curso. Puede ser que en el primer modelo-relacional esté mal la relación entre ventas-artículos? No debería ser al revés? En una venta muchos artículos? Tal como está en la imagen hay en un artículo muchas ventas.
Buen punto, yo tambien me fijé en eso y de hecho John lo habia dicho en el video anterior, tal vez se equivicó o fué una concha de mango para que aprendamos a fijarnos en los detalles jaja
Gracias Amigo ♥
👋🏻😉
Justo lo necesitaba 😊 Excelente curso!!!
Gracias!👋🏻😉
profe como estas consulta. en una arquitectura muty tenans es aconsejable organizarlas con con schema separados? o tablas compartidas?
uy se tendría que analizar cada caso de forma específica, pero siempre vete por la opción más optima
@@jonmircha gracias profe 👍
Hasta el minuto 5:00 (no sé si más adelante lo cambiaste...) la dirección de uno a muchos en carreras con tipo de carreras, y carreras con países, me parece que está a la inversa.
Colocas:
1:n carreras ->tipos_carreras
1:n carreras->paises
Y debería ser:
1:n tipos_carrera->carreras
1:n paises->carreras
En el análisis aprendí hacerlo así:
Una carrera tiene un tipo de carrera (1:1) -> carrera - tipo_carrera (1:1)
Un tipo de carrera está/tendrá varias carreras (1:n) -> tipo_carrera - carrera(1:n)
Entonces quedándonos con el mayor:
tipo_carrera - carrera(1:1)
tipo_carrera - carrera(1:n)
*tipo_carrera - carrera (1:n) (Sale del tipo de carrera hacía carrera)
Excelente curso maestro pero tengo una duda con respecto al ejercicio de autenticación. Hablando ya de un sistema creado con su interfaz definida. En que momento un usuario se le asignan los roles y/o los permisos?? porque en el modelo de la base de datos se plantean las relaciones pero no se aprecia en que punto el usuario llega a tener varios roles o al menos no lo noto.
Eso tendría que hacerse a la hora de crear el usuario, recuerda que la propuesta que hago en el curso, simplemente es un ejemplo básico, tendrías que analizar realmente lo que requiere tu sistema
@@jonmircha ya le capté la idea profe, no le había entendido bien. Eso sucede al crear el usuario.
Una duda más profe en el modelado de la encuesta; entiendo que una misma encuesta puede tener muchos resultados, pero un encuestado según mi lógica solo puede tener un único resultado. Es decir que ese encuestado_id hará referencia al resultado que le pertenece a él.
Hola Jon Excelente clase como siempres, tambien nos gustaria una actualizacion del curso de Wordpress que tienes, Saludos
👋🏻😉
Recien empiezo el segundo curso de gestores de bases de datos, gracias profe Jon por el conocimiento que compartes y enseñas, tengo una pequeña pregunta en el min 11:00 el atributo ciudad no podría ser una Entidad de Catálogo así como lo es país?, gracias, me encantan tus cursos, desde hace años los veo
Sí
@@jonmircha Hola profe Jon, teniendo en cuenta este curso de bases de datos quisiera saber si existe la posibilidad de que en un futuro no muy lejano nos puedas brindar un curso de Ruby on Rails, en mi empleo me tienen trabajando con esta tecnologia pero apenas la estoy aprendiendo y hay conceptos que aun no entiendo y los cursos que veo en RUclips son de hace 5 e incluso hasta 10 años, seria maravilloso que lo hicieras(si sabes Rails claro) siento que es un lenguaje muy bueno para interactuar con las bases de datos. Espero me leas, feliz dia :D
gracias!
👋🏻😉
Justo a tiempo 🎉
👋🏻😉
Vales oro bro
👋🏻😉
1:10:55 ## relaciones
hola profesor aqui mi solucion al reto, la cardinalidad es algo confusa y he visto que algunos tienen respuestas distintas, pero por lo que voy entendiendo
la cardinalidad que pueda tener un sistema va depender de la logica de negocio de que tendra la aplicacion y dependiendo de a que entidad le demos mas relevancia, la cardinalidad cambiara?
una **encuesta** _tiene_ preguntas (_1 a M_)('en caso que la encuesta tenga una sola pregunta podria cambiar')
una **pregunta** _tiene_ una respuesta (_1 a 1_)('si consideramos solo la que es correcta')
un **resultado** _pertenece_ a una sola encuesta (_1 a 1_)
un **resultado** _pertenece_ a un solo encuestado (_1 a 1_)
un **encuestado** _realiza_ varias encuestas (_1 a M_)('si tenemos un sistema que haga encuestas de manera periodica' )
👋🏻😉
Muchas gracias Jon!!!!
👋🏻😉
Muchas gracias por compartir su conocmiento con nosotros profesor :'D
👋🏻😉
Cuando es necesario el uso de tablas recursivas o que tan aconsejable es crear este tipo de tablas me podrían ayudar con esa consulta por favor
Cuando ví estos conceptos en la universidad, se nos enseñaba que la entidad con la cardinalidad más fuerte es la que guardaba como llave foránea la llave primaria de la entidad más débil. Esa son una de las cosas que se pueden ver (visualmente) más claro en el diagrama entidad relación a diferencia del modelo relacional.
En lo personal también considero que debería existir una forma más sencilla de hacer esto porque ciertamente se vuelve muy extenso al hacerlo todo en un diagrama ER (aunque sea necesario)... es como comentas nada está escrito en piedra.
🤓👍🏻
Esto va a estar bueno 👌
👋🏻😉
Tengo otra consulta, del ejercicio de "MirChaGraM", en las reglas de negocio enla seccion #user se podria poner como regla -habilitar un user y tamb -Inhabilitar un user? y la otra duda es si "contar el numero de comments de un post es igual a decir "incrementar en uno cada que un post tenga un comments"?
Sí y sí
@@jonmircha Muchisimas gracias Jon!
- Una **Encuesta** puede ser *realizada* por varios **encuestados** (1 a M)
- Una **Encuesta** puede *tener* muchas **preguntas** (1 a M)
- Una **Pregunta** *tiene* una **respuesta** (1 a 1)
- Un **resultado** *pertenece* a una **encuesta** (1 a 1)
- Un **resultado** *pertenece* a un **encuestado** (1 a 1)
Así fue como yo lo hice XD
👋🏻😉
Hola Jon, excelente curso, el de bases de datos SQL se vendrá en los proximos días? Saludos y gracias por todo!
Muy pronto
Jon, en la entidad usuarios y la entidad permisos_x_roles, colocas una flecha de relacion que me parece no corresponde a la definicion. yo creo que la correcta es de la entidad roles a la entidad permisos_x_roles.
John una pregunta, en el caso del alias de Mirchagram que tenías como PK antes de modificarlo; si el usuario quisiera cambiarse el alias y con esto se hiciera un UPDATE ON CASCADE...¿no cambiaría en el resto de tablas hijas y por tanto seguiría manteniendo las relaciones? Igualmente, al ser una PK no me gusta la idea tampoco de que se pueda modificar porque puede dar lugar a fallos imagino pero me vino a la cabeza el CASCADE y me preguntaba esto que te comento
Sí, jejeje te me estas adelantando pero sí , eso lo veremos en el curso de SQL
@@jonmircha aaah perdón 🙏🏻. Nota mental: tener más paciencia. Gracias!
Tengo una pregunta, en el caso de las entidades Catalogo, por ejemplo, la entidad pais que tiene ya muchos paises precargados, a la hora de crear la tabla en sql, agrego todos los paises asi?
si
Primero q nada felicitarte por tu contenido, tengo una duda, en el ejercicio de autenticación de usuarios hay una entidad pivote que se llama permiso por roles, no debiera estar unida a las entidades permiso y roles respectivamente? o en todo caso llamarse permisos_x_usuario?
Hola brou, yo igual he visto eso y pienso que en esa parte hubo error al unir las flechitas.
Hola Jon.
En el primer ejemplo (ventas) dices que la relación entre la entidad "artículos_x_venta" y la entidad "producto" es 1 a 1 , ¿por qué? No lo acabo de ver. ¿No sería 1 a N? Según cómo lo veo: 1 "articulos_x_venta" tienen 1 "producto" pero 1 "producto" pertenece a N "artículos_x_venta". Tú compras 5 televisiones ( artículo_id = 1 + producto_id=T ) y yo compro 1 televisión y 1 plancha (artículo_id = 2 + producto_id = T, artículo_id = 3 + producto_id = P)...tenemos que tanto artículo_id =1, como artículo_id = 2, como articulo_id=3 tan solo tienen 1 producto (T , T, P, respectivamente), o sea 1 a 1; sin embargo producto_id = T lo encontramos tanto en articulo_id = 1 como en artículo_id = 2, o sea 1 a N.
La cardinalidad me genera bastante confusión, tan solo quiero saber si hay un error o yo estoy ya echando humo por la cabeza jajaja.
Muchas gracias por tus videos!
Muchas gracias profe por su trabajo :)
👋🏻😉
Excelente video
Gracias!
¿Qué diferencia hay entre markdown y rmarkdown?
Muy buenos los cursos, muchas gracias?
4:06:00 explicación de microservicios
👋🏻😉
John va todo bien??
Saludos maestro, estuve mirando el Git Hub del curso, y aun no esta disponible el repositorio de Modelado De Datos.
Si esta, es el mismo repo para los 4 cursos de BDs
Profe una duda, en el modelo relacional entre peliculas - paises y paises - series, a como esta planteado no va la FK en la entidad paises? pienso que la relación esta invertida.
Tengo el mismo pensar..
👏🏼👏🏼👏🏼
👋🏻😉
3:55:36 profe en la relacion de personaje-pais, no deberia ser de 1 a 1? ya que el caballero nace en un solo pais.
5 PALABRAS: CRACK
👋🏻😉
letss goooooo!!!
👋🏻😉
jonmircha puedes hacer un tutorial de python con base de datos por favor
😉👋🏻
A la par de tu carrera en informática estas haciendo una maestría en Caballeros del Zodiaco o ya es doctorado? :)
Soy el Patriarca del Santuario 😎
Let's gooooo
👋🏻😉
Profe pregunta, cómo puedo dejar ser el estudiante eterno? Por cierto buenos cursos y este viene joyita 🎉
POnte a practicar y a hacer proyectos, no hay otra forma que poniendo en práctica lo que aprendes
critica constructiva? puedo? la corrida de datos termina de decantar todo lastima que no todos los ejercicios la tienen, sobre todo en el de las encuestas cuesta mucho agarrarle la logica, no x la base de datos de datos en si sino por la logica de negocio, el resto es una maravilla y gratis, mil gracias john
No lo entiendo bien, por ejemplo el registro de Caballero tiene (a lo largo de la serie puede cambiar) varias armaduras. Por otro lado una armadura puede haber sido tenida por muchos caballeros. Yo veo una relación de M a M. Es decir el registro llamemosle 25 de la tabla caballeros se puede relacionar con 4 registros de armaduras, a su vez un registro de la tabla Armaduras, llamemosle 02 y es la armadura de Capricornio se puede relacionar con varios registros de la tablla Caballeros, pues una armadura ha podido ser tenida por varios caballeros. Vamos, M : M.
CRACK :) cuando gane en dólares te gastare el taco lo prometo, muchas gracias😄
👋🏻😉
Hacemos normalización para corregir algunos errores para que no se generen anomalías
Porque el atributo país fk va en cliente y porque mejor no va cliente fk en país
👋😉
😉 👋🏻
gemelas!!!
vale estoy intentando hacer un modelado de una base de un posible proyecto personal me puedes ayudar porfa , estoy enredado
segun yo tengo 3 tablas
cliente (cada uno de los cliente)
- uid_client (PK)
-...demas atributos
Compras (las compras que el cliente hizo conmigo y portanto genera una deuda )
- uid_compras (PK)
- uid_client (FK)
- ... demas atributos
Pagos (pagos del cliente para disminuir la deuda)
- uid_pagos(PK)
-uid_client(FK)
-..demas atributos
segun entiendo necesito una entidad pivote para relacionar los pagos con las compras y llegar a un total de la deuda , pero no estoy consiguiendo pensar en como
provablemente es mas facil de lo que parece pero esas cardinalidades me confunde en la definicion
AYUDAAAA!!! porfa :3
¿Pero qué carajos vendí? jajajaja saludos Jon
😅
El ultimo modelado me quedo de esta manera
## Listado de entidades
### Actividades
- id **(PK)**
- nombre
### Horario
- id **(PK)**
- id_actividad **(FK)**
- lugar
- hora
- cupos
### Registro
- id **(PK)**
- id_horario **(FK)**
- nombre
- apellido
- email **(UQ)**
- fecha_nacimiento
Como lo ven?
👋🏻😉