WOW tres días tratando de trazar esto y hoy aprendí Bastatante Me encantó esto.. De ahora en Adelante Usaré Lucidchart para todos estos temas... estoy muy Agradecido.
Mi "profesor" explicó este tema de E-R y no le entendi absolutamente nada pero tras mirar estos videos entendí todo. Muchas gracias por el tiempo y aporte.
La tabla pedido no cumple la tercera forma normal, debido que hay campos no claves que dependen de otro no clave, por ejemplo Nombre_cliente que depende del cliente_ID
Hola, me gustaría saber en que momentos se debe utilizar llaves compuestas y en que momentos realizar indices. si puedes hacer un vídeo, seria muy bueno para aclarar la inquietud
Yo recomendaría evitar utilizar claves primarias compuestas, en bases de datos grandes son un dolor de cabeza. Si esa tabla que tu mencionaste de Envíos no va a alterar ni la tabla productos ni la tabla pedidos, es decir solamente serán consultas lo que en buenas practicas se debe utilizar son los indices. Los indices ademas de eficientar las consultas a otras tablas también pueden ser compuestos y como una mejor solución para mi seria tener un numero de envió único, es decir un idEnvio y al mismo tiempo un índice compuesto donde consultemos el idPedido y el idProducto incluso podemos incluir el idCliente, de hecho asi es como lo manejan las paqueterias combinan el idProducto con tu idCliente pero no es el mismo que el idEnvio ya que eso crearia mucha confusion y genera lentitud en consultas.En conclusion cada tabla de tener su PK unica, en caso de relacionarse en un solo campo utilizar FK, cuando hay mas de una relación y esa relación no solo es consulta es decir no sera alterado utilizar índices y mejor aun indices únicos.
no se puede hacer tutoriales sobre uso de postgreSQL? seria buenisimo aprender las sentencias SELECT WHERE JOIN y asi mas detallado como lo hacen con la Entidad - Relacion
El modelo parece tener una restricción muy fuerte a saber: un pedido solo puede tener asociado uno y solo un producto. A no ser que esta sea una regla de negocio aplicable a un dominio específico, lo normal es que entre pedido y producto exista un relacionamiento muchos a muchos (un pedido puede tener cero, uno, o muchos productos y un producto puede ser parte de cero, uno o muchos pedidos). En este caso será necesario incluir en el modelo una "Tabla de unión" o "Tabla puente" como dice el instructor. Esta tabla sería algo como "Item_Pedido" y tendría un relacionamiento con la entidad Pedido y otro relacionamiento con la entidad Producto y tendría atributos tales como Cantidad_Pedida, Precio_Unitario, Porcentaje_Descuento, etc. Esta tabla tendría todos los productos incluidos en un pedido. Producto_Id y Numero_Pedido serían llaves foráneas en esta tabla. Igualmente, en esta tabla se podría tener una llave primaria compuesta estableciendose la restricción de que un producto solo puede aparecer una y solo una vez en un pedido. De no ser así, sería necesario definir una llave subrogada (identificador único de una tabla que no se deriva de los datos propios del dominio de la aplicación - P.Ej.: una secuencia autogenerada).
el entidad relacion es para una buena practica de crear bd, y tenerla bien estructurada. el modelo relacional es muy parecido, de hecho unas vez que ya la tenes clara en el entidad relacion, directamente haces el modelo relacional!
demasiado bueno el video, el nivel de detalle y de simplicidad en las explicaciones es perfecto, mcuhas gracias
Sus videos me salvaron mucho! deberían de retomar este proyecto :)
WOW tres días tratando de trazar esto y hoy aprendí Bastatante Me encantó esto.. De ahora en Adelante Usaré Lucidchart para todos estos temas... estoy muy Agradecido.
Mi "profesor" explicó este tema de E-R y no le entendi absolutamente nada pero tras mirar estos videos entendí todo. Muchas gracias por el tiempo y aporte.
es una verdadera lastima que una gran y sencilla explicación que parece hacha con palos y bolitas no subieran más contenido de esta calidad :(
como asi? explica?
Que le pareció bueno el vídeo
Explicas muy bien el diagrama de clases, ojalá continuarán esta serie con los demás diagramas de UML
muy buen video estoy estudiando Base de datos en SQL.... Gracias por el aporte !!!
genio!!, mejor explicado, imposible....nueva suscriptora..
Gracias por todo Lucid Software Español🙏🏻🙏🏻🙏🏻
Lo que expones es muy claro mil gracias!!!
Muchas gracias, excelente explicación, tal vez deberían impartir mas clases la dinámica es genial.
Maravillosa explicación, muchas gracias.
Gracias estaba buscando alguna herramienta para diseñar los ER. Lucichard es excelente y gartuito
Excelente explicación. Muy buena edición del video. Muy pedagógico.
Excelent información. Muy clara y util. Gracias!
Muy buenos videos y muy bien explicados. Muchas gracias!!
Muchas gracias por el contenido, quedo clarísimo
Pd: Me gustaría ver mas Ejemplos de como armar Diagramas de entidad relaciona mas complejos
me ayudo mucho llevo clases en línea y muy bien explicado me salvaste en mi ultimo proyectoooo
Me gusto mucho este video me ayudo mucho con mi materia de base de datos.
buena serie de tutoriales de diseño de diagramas entidad relacion. buenas explicaciones , buenas animaciones buen script
Están TAN bien hecho estos videos que parecen un curso pago.
Me encantó excelente explicación el video, seguiré la cuenta a la espera de nuevas publicaciones.
todo muy claro me encanto el tutorial gracias
GENIO, mas claro imposible !
¡Gracias por la información!
Me enganche con estos tutoriales, así da gusto estar suscrito a LucidCharts
Excelente. Muy claro, ojala sigan haciendo más videos.
!!Fantástico!! muy bien explicado, gracias
que calidad de contenido muchas gracias
estos videos son los mejores
Excelente video 👍 me quedo claro los conceptos.
Muchas gracias amigo Paco!!
Gracias me quedo muy claro la cardinalidad
gracias esta execelentemente explicado.
Tienen vídeos muy buenos espero sigan así.
¡Muchas gracias Orianna!
muchas gracias... se me hacia bastante dificil entenderlo!!!
Que calidad de información gracias.
este video me explico este tema mejor q 3 semestres de bases de datos en la universidad
Después de tus explicaciones probaré el Lucidchat para mis ejercicios
Excelente tutorial, te felicito.
"Empecemos donde nos quedamos del diagrama simple del tutorial anterior del año pasado"
¡Excelente video! Súper bien explicado. Me gustaría saber si pueden hablar sobre normalización.
Excelente hermano. Muy buen video.
Excelente explicacion muchas gracias
Buen video, seria interesante seguir con mas ejercicios. !!!!
buen trabajo bro, feicitaciones!
Gracias por su generosa explicacion
Excelente explicación
super buenos videos son muy explicativos
Estoy deseando que sea diciembre de 2019 para la parte 3
:v
Yo tambien estoy esperando una tercera parte. Algunos otros conceptos de diseño avanzado.
jajajajajaja que observador.
ya estamos mas cerca..que emocion!!!
han pasado 84 años
Compro lucichart si hacen un curso completo y avanzado, no importa que sea de paga.
Gracias esta muy bien explicado se espera el proximo
Muy didáctico. Felicitaciones
Muchas gracias!!!!
me salvaron de reprobar jsjsjs gracias
No comprendí biel "Tablas puentes". SON MUY BUENAS LAS EXLICACIONES - Gracias.
La tabla pedido no cumple la tercera forma normal, debido que hay campos no claves que dependen de otro no clave, por ejemplo Nombre_cliente que depende del cliente_ID
Gracias Paquito!! me salvaste el final de software aplicado a recursos humanos!!
Excelente tutorial hermano!!!
muy bueno!!!
¿Tendrán un curso mas completo en udemy o algo así? Si no es así, sería genial que subieran una a udemy, porque tu explicación es sorprendente.
Hola, me gustaría saber en que momentos se debe utilizar llaves compuestas y en que momentos realizar indices. si puedes hacer un vídeo, seria muy bueno para aclarar la inquietud
que tal, en el diagrama ER se ponen metodos o solo hasta el diagrama de clases?
gracias los amo
Buen video!
¡Muchas gracias Aristo!
Excelente video!!
Se te ve demacrau jajajaja Gracias por los tutoriales!
Yo recomendaría evitar utilizar claves primarias compuestas, en bases de datos grandes son un dolor de cabeza. Si esa tabla que tu mencionaste de Envíos no va a alterar ni la tabla productos ni la tabla pedidos, es decir solamente serán consultas lo que en buenas practicas se debe utilizar son los indices. Los indices ademas de eficientar las consultas a otras tablas también pueden ser compuestos y como una mejor solución para mi seria tener un numero de envió único, es decir un idEnvio y al mismo tiempo un índice compuesto donde consultemos el idPedido y el idProducto incluso podemos incluir el idCliente, de hecho asi es como lo manejan las paqueterias combinan el idProducto con tu idCliente pero no es el mismo que el idEnvio ya que eso crearia mucha confusion y genera lentitud en consultas.En conclusion cada tabla de tener su PK unica, en caso de relacionarse en un solo campo utilizar FK, cuando hay mas de una relación y esa relación no solo es consulta es decir no sera alterado utilizar índices y mejor aun indices únicos.
no se puede hacer tutoriales sobre uso de postgreSQL? seria buenisimo aprender las sentencias SELECT WHERE JOIN y asi mas detallado como lo hacen con la Entidad - Relacion
Muy bueno , gracias
Muy bueno el video
me gustaron los 2 videos , pero quisiera saber como se codifica esa reacion, gracias
Consulta con este programa al exportarlo para el DBMS se podria sincronizar a mi pagina web??
Hola Paco! una preguntilla y con qué tipo de dato declararía a la fecha_envio podría ser varchar(15)
Depende el sistema que uses, por lo general lo mejor es usar DATE o DATETIME, no varchar.
Varchar no se usa para fechas...
El modelo parece tener una restricción muy fuerte a saber: un pedido solo puede tener asociado uno y solo un producto. A no ser que esta sea una regla de negocio aplicable a un dominio específico, lo normal es que entre pedido y producto exista un relacionamiento muchos a muchos (un pedido puede tener cero, uno, o muchos productos y un producto puede ser parte de cero, uno o muchos pedidos). En este caso será necesario incluir en el modelo una "Tabla de unión" o "Tabla puente" como dice el instructor. Esta tabla sería algo como "Item_Pedido" y tendría un relacionamiento con la entidad Pedido y otro relacionamiento con la entidad Producto y tendría atributos tales como Cantidad_Pedida, Precio_Unitario, Porcentaje_Descuento, etc. Esta tabla tendría todos los productos incluidos en un pedido. Producto_Id y Numero_Pedido serían llaves foráneas en esta tabla. Igualmente, en esta tabla se podría tener una llave primaria compuesta estableciendose la restricción de que un producto solo puede aparecer una y solo una vez en un pedido. De no ser así, sería necesario definir una llave subrogada (identificador único de una tabla que no se deriva de los datos propios del dominio de la aplicación - P.Ej.: una secuencia autogenerada).
Lucid chart sirve para crear diagramas para base de datos no relacionales??? si es así puede poner un ejemplo? gracias un saludo
Mas tutoriales de base de datos por fabor. O tambien deberias hacer un curso en udemy de paga.
Excelentes animaciones en la explicación,
Buenas tardes, el modelo ER se hace antes o después de normalizar?
Cuando exporto el diagrama, en el script no veo que se cree las FK. Hay algo mas que se debe hacer? Gracias.
gracias por la información , tendrás algo de información para montar nomencladores
Hola, no me quedo muy en claro por que 9:23 un pedido podría ser 2 envíos diferentes
Si el pedido es de varios artículos, pueden ser enviados en diferentes envíos, por lo que puede no ser un registro único.
Un pedido de un cliente puede estar compuesto de varios productos como lo reflejas y almacenas en la base de datos.
gracias a ti entendi porque no puedo cambiar mi nombre de twitter 😭
Hola hay forma de convertir el diagrama a clases para usarlo con code first con algun ORM tipo TypeORM ?
Mejor explicado que el profesor de la universidad , Hahhaha
Exelente!!!
hola excelente información, me puedes decir que opción de pagina web puedo realizar para mi emprendiendo saludos gracias
Pueden hacer un vídeo con ejemplo de un colegio el modelo de relación
Me gustaría ver lo de Estereotipos, Boundary, Control, Entity
genial!
Pero en la tabla pedido como se hace para agregar mas de un producto???? :/
Como obtengo esos graficos????
2020 casi 2021 y estoy esperando la tercera parte como todos los demás
gracias¡¡¡¡¡¡ :D
muy buen video, solo una cosa este video es de ENTIDAD-RELACION, mi pregunta o mi duda es en qué cambia con RELACIÓNAL?
el entidad relacion es para una buena practica de crear bd, y tenerla bien estructurada. el modelo relacional es muy parecido, de hecho unas vez que ya la tenes clara en el entidad relacion, directamente haces el modelo relacional!
Me gustaría saber cómo normalizar esas tablas, gracias.
Ese seria un tema para otra serie de videos
Donde le doy para que mi mapa se guarde en mi computadora
Tabla puente= tabla de una relación?
Hola!, Tutoriales de laravel y de app inventor 2, por favor. Gracias!