COMPITO SECONDO Corso: Abilità Informatiche Avanzate Prof. Agostino Marengo Anno accademico 2010/2011 Studente: Antonio D’Aniello Matricola: 569637
1) PROGETTAZIONE DI UN DATA BASE: gestione dei prestiti di una biblioteca personale
Gestione prestiti di una biblioteca personale Entità LIBRI (Non possiedo stessi libri – per cui assumo chiave primaria il titolo del libro) AMICI (Individuo univocamente ogni amico con un soprannome.) La relazione tra le due è di n:n Ad ogni amico posso prestare uno o più libri; Ogni libro posso prestarlo ad uno o più amici. PRESTITI si rende necessaria per "scomporre" la relazione.
Gestione prestiti di una biblioteca personale Schema Entità-Relazioni LIBRI 1 : N PRESTITI N : 1 AMICI N : N
Gestione prestiti di una biblioteca personale Tabella LIBRI Nome campo Tipo campo Dimensione Vincoli Note Titolo Testo 50 Primary Key Casa editrice Anno edizione Numerico 4 Prestato 2 Not null Restituito
Gestione prestiti di una biblioteca personale Tabella AMICI Nome campo Tipo campo Dimensione Vincoli Note Soprannome Testo 50 Primary Key Telefono Numerico Intero lungo Not null Domicilio Alfa numerico Indirizzo mail Alfanumerico
Gestione prestiti di una biblioteca personale Tabella PRESTITI Nome campo Tipo campo Dimensione Vincoli Note Titolo Testo 50 Foreign Key Link alla tabella libri Soprannome Link alla tabella amici Data prestito Data Not null Data restituzione Check if >(Data prestito)
Gestione prestiti di una biblioteca personale es. PRESTITI Titolo Soprannome Data prestito Data restituzione La solitudine dei numeri primi Giusè 10/10/2010 03/03/2011 Rossovermiglio Peppino 05/01/2011 I giorni dell’amore e della guerra Pino 27/11/2010 01/02/2011 L’estate del cane nero Michele 02/01/2011 25/01/2011
Gestione prestiti di una biblioteca personale es. LIBRI Titolo Editore Anno edizione Prestato Restituito La solitudine dei numeri primi Mondadori 2008 Si Rossovermiglio Feltrinelli 2009 No I giorni dell’amore e della guerra Garzanti libri L’estate del cane nero Marsilio
Gestione prestiti di una biblioteca personale es. AMICI Soprannome Telefono Domicilio Indirizzo mail Giusè 3476985555 Via strada chiusa, 5 giuseppe978@libero.it Peppino 080556699 Via strada storta, 6 Pino 534654654 Piazza Capri,10 Michele 456465465 Viale dei Lilium,8 michele1234@tiscali.it
Gestione prestiti di una biblioteca personale Conclusini Non sono accettabili valori nulli per le Chiavi primarie (Titolo, Soprannome) perchè ho necessità di identificare quale libro ho prestato e a quale dei miei amici, sono gli elementi fondamentali del prestito. In alcune tabelle come ad esempio quella LIBRI ho impostato come NOT NULL gli attributi "prestato" e "restituito" in modo da ottimizzare l'utilità del database costringendo l'utente ad indicare se il libro è o no nella propria disponibilità. Nella tabella AMICI il soprannome individua univocamente l'amico e mi evita la costruzione di una superchiave: nell'esempio ho inserito tre persone, tutte con il nome Giuesppe, ma la prima conosciuta come Giusè, l'altra come Peppino, l‘altra come Pino. Nella tabella PRESTITI "impongo" all'utente di indicare la data in cui è avvenuto il prestito, al contrario dell'attributo "Data restituzione"; nel caso in cui però si voglia riempire anche quest'ultimo campo, c'è il vincolo logico da rispettare che la data di restituzione sia posteriore alla data del prestito.
2) " Base dati Ospedale" Chiavi Tra le tabelle PAZIENTI e REPARTI esiste una relazione n:n :un paziente può essere ricoverato in più reparti e un reparto può ospitare più pazienti. La si scompone in RICOVERI. Le chiavi primarie sono “Cod” per PAZIENTI, "Cod" per REPARTI – entrambe chiavi esterne nella tabella RICOVERI - e "Matr" per MEDICI; chiave esterna in REPARTI(Primario). Nella tabella RICOVERI non è possibile individuare una chiave – dobbiamo costruirci una superchiave: RICOVERI(Paziente,Inizio,Reparto)
"Base dati Ospedale" Attributi nulli e vincoli referenziali Gli attributi che possiamo ammettere nulli sono tutti quelli che non siano chiavi primarie (VINCOLO REFERENZIALE) – se ad esempio non disponessimo del cognome di un paziente, comunque sarebbe sufficiente PAZIENTI(COD) per identificarlo unificamente. Per cui attributi nulli REPARTI (Nome) PAZIENTI (Cognome,Nome)MEDICI (Nome,Cognome)
"Base dati Ospedale" Attributi nulli e vincoli referenziali Nonostante PAZIENTI e MEDICI abbiano una chiave primaria ciascuno, per rispettare i vincoli di integrità referenziale non possiamo considerare nulli i campi REPARTI(Primario) e MEDICI(Reparto), altrimenti perderemmo i riferimenti alle tabelle esterne. Per i RICOVERI la questione si rende più delicata perchè dobbiamo costruirci una superchiave. Poniamo composta da RICOVERI(Paziente,Inizio,Reparto) allora la voce ammissibile nulla è "FINE".