Hola!!, Me gustó tu diseño de base de datos, y a partir de él, estaré creando el proyecto y dándole vida acá: ru-vid.com/group/PLsHSo40lsM9F6Aso3tpfI6JZW7ypBtzG2 👍
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.
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) );
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
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.
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 ?
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ó?
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 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
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.
