Muchas gracias por sus conocimientos y el favor que nos hace al compartirlos de forma tan simple para nosotros. Muy amable.

me sirvió para una prueba técnica que me pidieron realizar, muchas gracias

Excelente, me encantó este video, muy fácil de comprender. Muy agradecido por su contenido.

Ohhhh que video tan bueno, excelente material y muy buena explicación. Muchas gracias

Muy buena explicación. Gracias por compartir.

Gran video. Excelentemente explicado todo 👌

Excelente, aquí una nueva suscritora, saludos desde Perú

Esto es realmente hermoso !!!!!! Muchas gracias maestro !

Muchas gracias por el video exelente.

Buen video, muy bien explicado.

muy buena explicación

Buen video, gracias

Excelente, gracias aqui un nuevo suscriptor!!!

muyyyyyyyyy buena explicacion.

Excelente explicación

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

muchas gracias

Muy buena explicación!

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 ?

Muy buena clase!!!!

un libro como por ejemplo DOn quijote de la mancha podria tener varias editoriales

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?

Excelente video

Muchas gracias, disculpa como agregas un apartado para los tipos de datos?

es como si hablara con mi amigo de costa rica , de donde sos? muy bien explicado el video, gracias

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

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?

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?

Como decir que eres tico sin decirlo: Pura Vida! :D buen video!

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

Hola!!, Me gustó tu diseño de base de datos, y a partir de él, estaré creando el proyecto y dándole vida acá: kzfaq.info/sun/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ó?