Totalmente. Importante recordar que cada diseñador de base de datos debe tomar en cuenta los requerimientos y tomar decisiones sobre cómo diseña su base de datos, incluyendo las relaciones. Para este ejemplo, decidí que a cada libro de esa base de datos solo se le guardará una editorial. Hay que recordar que en diseño de bases de datos no existe una solución única, porque varias diferentes podrían funcionar bien.
muy buen video y la verdad me gusto demasiado la manera en la que explico, pero me surgió una duda, en la relacion de libros a prestamos por ser de n:n (muchos a muchos) por concepto no se debería de crear una nueva tabla entre ellas ?
5:26 Entiendo la relación "uno a uno" entre la placa y el vehiculo, dos tablas separadas. Y también entiendo que "la placa" podría ser "una columna más" dentro de la tabla "vehiculos". ¿Cómo sé cuál opción escoger?
Si colocas el campo placa como informacion adicional, ya no sera llave primaria, la llave primaria será un valor autoincrementable o algun otro valor que se pueda tomar en relacion a ese vehiculo, por eso lo más recomendable es tomar la placa como llave primaria.
Muy bueno, pero cambiaria un par de cosas en las relaciones, por ejemplo un Autor si puede tener varios libros, pero también hay libros que tienen más de un autor. en cuanto a editoriales y libros lo mismo, en la vida real muchas editoriales pueden tener el mismo titulo de libro, pero claro el isbn es único
muy buena explicación! lo único que me da vueltas, es que, aparte de que lo pida el problema no veo la necesidad de hacer una tabla de géneros, en vez de ser un atributo del libro. No veo cual es la razón de hacer una tabla con un PK y un solo atributo. Y ya como buena práctica para programar posteriormente, nunca colocaría como PK una información publica como el rut o patente, ya que sería fácilmente hackeable... pero eso es harina de otro costal
Buen video, buena explicación, no me queda claro el concepto de cardinalidad ¿son la cantidad de filas pero tambien las relaciones entre tablas? gracias
Hola, gracias por la pregunta. La cardinalidad de una relación es el número de filas relacionadas de cada una de las tablas en la relación. Por ejemplo, si tenemos una relación con cardinalidad 1 a N, significa que una fila de la tabla A, se relaciona con muchas filas de la tabla B. Si la relación es con cardinalidad N a M, significa que muchas filas de la tabla A se relacionan con muchas filas de la tabla B.
Para que exista una relacion Muchos a Muchos , no debe haber un intermediario? En libros y Prestamos , Bueno al menos asi es en Acces , aqui no aplica?
Hola y gracias por la pregunta. Dependiendo de la herramienta DBMS que uses, vas a tener que crear necesariamente la tabla intermedia entre las dos que se están relacionando. Esta tabla intermedia jala las llaves primarias de las tablas que se están relacionando e incluso se puede agregar un atributo adicional si es de interés.
CREATE TABLE AUTORES ( AU_ID INT PRIMARY KEY IDENTITY, AU_NOMBRE NVARCHAR(50) NOT NULL, AU_APELLIDO_PATERNO NVARCHAR(50) NOT NULL, AU_APELLIDO_MATERNO NVARCHAR(50) NOT NULL, AU_PAIS NVARCHAR(45) NOT NULL ); CREATE TABLE USUARIOS ( US_DNI INT PRIMARY KEY IDENTITY, US_NOMBRE NVARCHAR(50) NOT NULL, US_APELLIDO_PATERNO NVARCHAR(50) NOT NULL, US_APELLIDO_MATERNO NVARCHAR(50) NOT NULL, US_DIRECCION NVARCHAR(200) NOT NULL, US_TELEFONO INT NOT NULL, US_CORREO NVARCHAR(100) NOT NULL ); CREATE TABLE EDITORIALES ( ED_ID INT PRIMARY KEY IDENTITY, ED_NOMBRE NVARCHAR(45) NOT NULL, ED_DIRECCION NVARCHAR(200) NOT NULL ); CREATE TABLE GENEROS ( GE_ID INT PRIMARY KEY IDENTITY, GE_NOMBRE NVARCHAR(50) NOT NULL ); CREATE TABLE LIBROS ( LI_ISBN INT PRIMARY KEY IDENTITY, LI_TITULO NVARCHAR(50) NOT NULL, LI_PUBLICACION DATE NOT NULL, LI_AU_ID INT NOT NULL, LI_GE_ID INT NOT NULL, LI_ED_ID INT NOT NULL, CONSTRAINT FK_LI_AU_ID FOREIGN KEY (LI_AU_ID) REFERENCES AUTORES (AU_ID), CONSTRAINT FK_LI_GE_ID FOREIGN KEY (LI_GE_ID) REFERENCES GENEROS (GE_ID), CONSTRAINT FK_LI_ED_ID FOREIGN KEY (LI_ED_ID) REFERENCES EDITORIALES (ED_ID) ); CREATE TABLE PRESTAMO ( PR_ID INT PRIMARY KEY IDENTITY, PR_FECHA_INICIO DATE NOT NULL, PR_FECHA_DEVOLUCION DATE NOT NULL, PR_ESTADO NVARCHAR(30) NOT NULL, PR_US_DNI INT NOT NULL, PR_LI_ISBN INT NOT NULL, CONSTRAINT FK_PR_US_DNI FOREIGN KEY (PR_US_DNI) REFERENCES USUARIOS (US_DNI), CONSTRAINT FK_PR_LI_ISBN FOREIGN KEY (PR_LI_ISBN) REFERENCES LIBROS (LI_ISBN) );
Tengo una duda ,siempre veo esto y no comprendo ,si tenemos a autores y usuarios ,entonces no sería mejor crear una tabla del tipo solo usuarios y dentro de este tenga a autores ,con atributos del tipo autor y otro usuario admin por ejemplo , entonces solo necesitaría una sola tabla y no 2 ,porque sí no como aplicaría la autenticación?.esta duda es principalmente porque ,siempre veo que trabajan con una tabla usuario y ahí le agregan diferentes tipos ,ya sea autor ,cliente ,vendedor ,administrador , esto me vuela la cabeza por Dios ,porque sí no ,como podría aplicar la seguridad? O esto tambien es posible en tablas separadas?
En este caso no, porque la tabla autores lo está utilizando como una entidad de catálogos para que cada libro esté relacionado con el autor y si vemos el problema a resolver dice un sistema de biblioteca, ahí nos preguntamos quienes utilizarían el sistema, en este caso un encargado de turno el cual prestara los libros. Espero poder aclarado algo a tu duda.
Hola!!, Me gustó tu diseño de base de datos, y a partir de él, estaré creando el proyecto y dándole vida acá: ruclips.net/p/PLsHSo40lsM9F6Aso3tpfI6JZW7ypBtzG2 👍
No entiendo por qué al final dices que un libro no puede tener 0 préstamos. Si es un libro nuevo, perfectamente puede tener 0 préstamos, o no? - o un libro que a nadie le interesó?
Muchas gracias por tu video, explicas muy bien
Muchas gracias por sus conocimientos y el favor que nos hace al compartirlos de forma tan simple para nosotros. Muy amable.
Muy buena explicación. Gracias por compartir.
Excelente explicación, muy clara. Muchas gracias
me sirvió para una prueba técnica que me pidieron realizar, muchas gracias
Excelente explicación, me sirvió mucho para un trabajo
muchas gracias por esos conocimientos
Gran video. Excelentemente explicado todo 👌
Excelente, me encantó este video, muy fácil de comprender. Muy agradecido por su contenido.
Aprendí más en este video que en una tutoría de tres horas de la Uned.
Excelente explicación 👍👍👍👍
Excelente, aquí una nueva suscritora, saludos desde Perú
Muy buena explicación!
muyyyyyyyyy buena explicacion.
Ohhhh que video tan bueno, excelente material y muy buena explicación. Muchas gracias
muy buena explicación
Excelente video , disculpe una consulta , cuando existe una relación de muchos a muchos , ¿no tendria existiria una tabla intermedia ?
Muchas gracias por el video exelente.
Esto es realmente hermoso !!!!!!
Muchas gracias maestro !
Excelente, gracias aqui un nuevo suscriptor!!!
Muchas gracias y bienvenido al canal.
Gracias buen hombre
gracias capo
Buen video, muy bien explicado.
muchas gracias
Buen video, gracias
Gran video🙌🏼
Excelente explicación
un libro como por ejemplo DOn quijote de la mancha podria tener varias editoriales
Totalmente. Importante recordar que cada diseñador de base de datos debe tomar en cuenta los requerimientos y tomar decisiones sobre cómo diseña su base de datos, incluyendo las relaciones. Para este ejemplo, decidí que a cada libro de esa base de datos solo se le guardará una editorial. Hay que recordar que en diseño de bases de datos no existe una solución única, porque varias diferentes podrían funcionar bien.
Muy buena clase!!!!
muy buen video
muy buen video y la verdad me gusto demasiado la manera en la que explico, pero me surgió una duda, en la relacion de libros a prestamos por ser de n:n (muchos a muchos) por concepto no se debería de crear una nueva tabla entre ellas ?
Excelente video
Solo porque usas Ubuntu me suscribo y le doy like
Muchas gracias, disculpa como agregas un apartado para los tipos de datos?
5:26 Entiendo la relación "uno a uno" entre la placa y el vehiculo, dos tablas separadas. Y también entiendo que "la placa" podría ser "una columna más" dentro de la tabla "vehiculos". ¿Cómo sé cuál opción escoger?
Si colocas el campo placa como informacion adicional, ya no sera llave primaria, la llave primaria será un valor autoincrementable o algun otro valor que se pueda tomar en relacion a ese vehiculo, por eso lo más recomendable es tomar la placa como llave primaria.
Muy bueno, pero cambiaria un par de cosas en las relaciones, por ejemplo un Autor si puede tener varios libros, pero también hay libros que tienen más de un autor. en cuanto a editoriales y libros lo mismo, en la vida real muchas editoriales pueden tener el mismo titulo de libro, pero claro el isbn es único
muy buena explicación! lo único que me da vueltas, es que, aparte de que lo pida el problema no veo la necesidad de hacer una tabla de géneros, en vez de ser un atributo del libro. No veo cual es la razón de hacer una tabla con un PK y un solo atributo. Y ya como buena práctica para programar posteriormente, nunca colocaría como PK una información publica como el rut o patente, ya que sería fácilmente hackeable... pero eso es harina de otro costal
Yo lo haría si quiero evitar la contaminación de las categorías... digo yo...
Buen video, buena explicación, no me queda claro el concepto de cardinalidad ¿son la cantidad de filas pero tambien las relaciones entre tablas? gracias
Hola, gracias por la pregunta. La cardinalidad de una relación es el número de filas relacionadas de cada una de las tablas en la relación. Por ejemplo, si tenemos una relación con cardinalidad 1 a N, significa que una fila de la tabla A, se relaciona con muchas filas de la tabla B. Si la relación es con cardinalidad N a M, significa que muchas filas de la tabla A se relacionan con muchas filas de la tabla B.
@@mascienciaytecnologia ¡gracias!
es como si hablara con mi amigo de costa rica , de donde sos? muy bien explicado el video, gracias
Hola, justamente somos de Costa Rica.
Para que exista una relacion Muchos a Muchos , no debe haber un intermediario? En libros y Prestamos , Bueno al menos asi es en Acces , aqui no aplica?
Hola y gracias por la pregunta. Dependiendo de la herramienta DBMS que uses, vas a tener que crear necesariamente la tabla intermedia entre las dos que se están relacionando. Esta tabla intermedia jala las llaves primarias de las tablas que se están relacionando e incluso se puede agregar un atributo adicional si es de interés.
Como decir que eres tico sin decirlo: Pura Vida! :D buen video!
CREATE TABLE AUTORES (
AU_ID INT PRIMARY KEY IDENTITY,
AU_NOMBRE NVARCHAR(50) NOT NULL,
AU_APELLIDO_PATERNO NVARCHAR(50) NOT NULL,
AU_APELLIDO_MATERNO NVARCHAR(50) NOT NULL,
AU_PAIS NVARCHAR(45) NOT NULL
);
CREATE TABLE USUARIOS (
US_DNI INT PRIMARY KEY IDENTITY,
US_NOMBRE NVARCHAR(50) NOT NULL,
US_APELLIDO_PATERNO NVARCHAR(50) NOT NULL,
US_APELLIDO_MATERNO NVARCHAR(50) NOT NULL,
US_DIRECCION NVARCHAR(200) NOT NULL,
US_TELEFONO INT NOT NULL,
US_CORREO NVARCHAR(100) NOT NULL
);
CREATE TABLE EDITORIALES (
ED_ID INT PRIMARY KEY IDENTITY,
ED_NOMBRE NVARCHAR(45) NOT NULL,
ED_DIRECCION NVARCHAR(200) NOT NULL
);
CREATE TABLE GENEROS (
GE_ID INT PRIMARY KEY IDENTITY,
GE_NOMBRE NVARCHAR(50) NOT NULL
);
CREATE TABLE LIBROS (
LI_ISBN INT PRIMARY KEY IDENTITY,
LI_TITULO NVARCHAR(50) NOT NULL,
LI_PUBLICACION DATE NOT NULL,
LI_AU_ID INT NOT NULL,
LI_GE_ID INT NOT NULL,
LI_ED_ID INT NOT NULL,
CONSTRAINT FK_LI_AU_ID FOREIGN KEY (LI_AU_ID) REFERENCES AUTORES (AU_ID),
CONSTRAINT FK_LI_GE_ID FOREIGN KEY (LI_GE_ID) REFERENCES GENEROS (GE_ID),
CONSTRAINT FK_LI_ED_ID FOREIGN KEY (LI_ED_ID) REFERENCES EDITORIALES (ED_ID)
);
CREATE TABLE PRESTAMO (
PR_ID INT PRIMARY KEY IDENTITY,
PR_FECHA_INICIO DATE NOT NULL,
PR_FECHA_DEVOLUCION DATE NOT NULL,
PR_ESTADO NVARCHAR(30) NOT NULL,
PR_US_DNI INT NOT NULL,
PR_LI_ISBN INT NOT NULL,
CONSTRAINT FK_PR_US_DNI FOREIGN KEY (PR_US_DNI) REFERENCES USUARIOS (US_DNI),
CONSTRAINT FK_PR_LI_ISBN FOREIGN KEY (PR_LI_ISBN) REFERENCES LIBROS (LI_ISBN)
);
Tengo una duda ,siempre veo esto y no comprendo ,si tenemos a autores y usuarios ,entonces no sería mejor crear una tabla del tipo solo usuarios y dentro de este tenga a autores ,con atributos del tipo autor y otro usuario admin por ejemplo , entonces solo necesitaría una sola tabla y no 2 ,porque sí no como aplicaría la autenticación?.esta duda es principalmente porque ,siempre veo que trabajan con una tabla usuario y ahí le agregan diferentes tipos ,ya sea autor ,cliente ,vendedor ,administrador , esto me vuela la cabeza por Dios ,porque sí no ,como podría aplicar la seguridad? O esto tambien es posible en tablas separadas?
En este caso no, porque la tabla autores lo está utilizando como una entidad de catálogos para que cada libro esté relacionado con el autor y si vemos el problema a resolver dice un sistema de biblioteca, ahí nos preguntamos quienes utilizarían el sistema, en este caso un encargado de turno el cual prestara los libros.
Espero poder aclarado algo a tu duda.
Vale pero, este es el esquema relacional, el entidad relación es el de rectangulos y rombos, si mis profesores no me han explicado mal
Así es que dice el vídeo
eso dice en el título del video
Hola!!, Me gustó tu diseño de base de datos, y a partir de él, estaré creando el proyecto y dándole vida acá: ruclips.net/p/PLsHSo40lsM9F6Aso3tpfI6JZW7ypBtzG2 👍
No entiendo por qué al final dices que un libro no puede tener 0 préstamos. Si es un libro nuevo, perfectamente puede tener 0 préstamos, o no? - o un libro que a nadie le interesó?