[bofhers] Re: [bofhers] Re: [bofhers] Problemilla con diseño de BD SQL Server 2008 (para el cole)
- From: Autoestopista El <autoestopistael@xxxxxxxxx>
- To: bofhers@xxxxxxxxxxxxx
- Date: Thu, 14 Mar 2013 19:21:54 +0100
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
Other related posts:
