Vale si, da un fallo porque he llamado a un elemento de una tabla antes de definirla. Cosas que pasas :D El 14 de marzo de 2013 19:21, Autoestopista El <autoestopistael@xxxxxxxxx>escribió: > La fecha de devolucion solamente la manejo en caso de prestamos al > exterior, para los prestamos de sala se asume que es la misma fecha en que > se presta. Así que opto por manejar los prestamos exteriores y sus fechas > de devolucion aparte, en la tabla prestamo_externo. Que a lo mejor no es la > mejor opción, pero bueno, a mi se me ha ocurrido así :) > > El 14 de marzo de 2013 08:07, TarodBOFH <bofh@xxxxxxxxxxxxx> escribió: > >> Para la integridad referencial tienes que tener en cuenta que entidades >> tienen sentido unas sin otras y cuales no. >> >> Por ejemplo, un cliente puede no tener una dirección (si tienes tablas >> clientes y otra direcciones), por lo que en ese caso ON_DELETE (en >> dirección) --> SET NULL a cliente; mientras que una dirección sin cliente >> no tiene sentido (ON_DELETE_CASCADE --> cliente) >> >> Otro ejemplo es permitir el borrado: No deberías borrar datos de clientes >> que tengan compras. Aunque si la bbdd está bien hecha, INVOICES siempre >> será una copia con todos los datos de los clientes y precios, y tendrás >> columnas de referencia para agilizar las búsquedas (ojo, si tu caso es para >> un ejercicio, esto que se *debe* hacer en la vida real no estaría >> normalizado para el ejercicio!) >> >> ¿Es eso a lo que te refieres? >> >> En tu caso: >> - Prestamo (te falta fecha de devolución? ) -> no podrías borrar un socio >> que aún tiene préstamos sin devolver (o incluso borrar un socio con >> préstamos antigios, ya que num_socio en prestamo es not null) >> - Al borrar un libro --> en cascada cascada de fondo (si borras el >> libro, desaparece de fondo), etc. >> >> >> 2013/3/14 Autoestopista El <autoestopistael@xxxxxxxxx> >> >>> Bueeeno, pues como comenté esta mañana ahí lo lanzo. >>> >>> Arresulta que tengo el siguiente diseño de una BD. Tiene los detalles >>> justos requeridos según un enunciado (DiagramaER_corregido.vsd) del cual he >>> sacado, normalizando y desnormalizando, el siguiente juego de tablas >>> (Tablas_corregido.vsd). Hay otros posibles, pero este es el mío. >>> >>> El caso es que he creado la BD según las especificaciones que me piden >>> con este script (biblioteca.sql) y generado las tablas y sus relacions >>> (foreign keys) con este otro (tablas.sql). Si, señores, me lo piden así de >>> separadito. Como véis he definido un par de constraints para las foreign >>> keys y un UNIQUE para que me cuadrara una clave candidata. Todos los campos >>> a NOT NULL de momento. >>> >>> Así que ahora me piden un tercer script que haga dos cosas: >>> >>> - Aplicar restricciones de integridad referencial. >>> - Establecer que atributos admiten o no valores NULL. >>> >>> El caso es que no tengo muy claro en que me tengo que fijar para >>> determinar el tema de la integridad referencial. Es decir, ¿que tengo que >>> tener en cuenta a la hora de aplicar una restricción? Supongo que no es >>> tan difícil pero al final me ha vencido el tiempo y el pánico, y las BBDD >>> no son precisamente mi fuerte. >>> >>> Y ya podéis lartearme tranquilamente, que yo agacho la cabeza a la >>> espera de vuestro aleccionamiento. >>> -- >>> Lista de Correo #BOFHers - //www.freelists.org/list/bofhers >>> Síguenos también el Twitter, en el hastag #BOFHers (y derivados) >>> ¡También tenemos un servidor IRC! irc.escomposlinux.org:6667 canal >>> #BOFHers >>> >> >> > > > -- > Lista de Correo #BOFHers - //www.freelists.org/list/bofhers > Síguenos también el Twitter, en el hastag #BOFHers (y derivados) > ¡También tenemos un servidor IRC! irc.escomposlinux.org:6667 canal > #BOFHers > -- Lista de Correo #BOFHers - //www.freelists.org/list/bofhers Síguenos también el Twitter, en el hastag #BOFHers (y derivados) ¡También tenemos un servidor IRC! irc.escomposlinux.org:6667 canal #BOFHers