Esercizio 1 Progettazione Database Biblioteca Personale Compito 2

Esercizio 1 Progettazione Database Biblioteca Personale Compito 2 Pedone Antonio Matricola: 566396

Analisi • Si vuole automatizzare la gestione dei prestiti di una biblioteca personale • Si gestiranno dati relativi a: – Libri presenti nella biblioteca – Soggetti che prendono libri in prestito – Prestiti di ciascun libro

Schema Concettuale • Entità previste nel Database: – Libri: comprende l’insieme dei libri disponibili – Amici: nominativo del soggetto che prende un libro in prestito – Prestiti: dati riguardanti i prestiti in corso o effettuati in passato

Progettazione Concettuale • Entità Libri • Attributi previsti: – Id. Libro: Codice univoco di un singolo libro – Titolo. Libro: Titolo di un libro

Progettazione Concettuale • Entità Amici • Attributi previsti: – Id. Amico: Codice univoco di un singolo amico – Nome. Amico: Nominativo del soggetto che prende un libro in prestito

Progettazione Concettuale • Entità Prestiti • Attributi previsti: – Id. Prestito: Codice univoco per ogni prestito – Fk. Libro. Prestito: Libro oggetto del prestito – Fk. Amico. Prestito: Soggetto che ha preso il libro in prestito – Inizio. Prestito: Data nella quale è partito il prestito – Consegna. Presunta. Prestito: Data nella quale si presume che il libro venga restituito – Consegna. Prestito: Data nella quale avviene la restituzione del libro

Progettazione Logica • Definizione delle relazioni: Libri – Amici Un soggetto può prendere in prestito più libri e lo stesso libro può essere preso in prestito da più soggetti Relazione N : N

Progettazione Logica Libri - Prestiti Ogni prestito riguarda un singolo libro, mentre lo stesso libro può essere oggetto di più prestiti Relazione 1 : N

Progettazione Logica Amici – Prestiti Un singolo prestito riguarda un solo soggetto, mentre un soggetto può effettuare più prestiti Relazione 1 : N

Progettazione Logica Schema Relazioni N Libri N Amici 1 1 N Prestiti N

Progettazione Logica Tabella Libri – Caratteristiche degli attributi Nome Tipo Id. Libro Nome. Libro Contatore Testo Dimensione Vincoli 60 Primary key Not Null Unique

Progettazione Logica Tabella Amici – Caratteristiche degli attributi Nome Tipo Id. Amico Contatore Nome. Amico Testo Dimensione Vincoli 30 Primary key Not Null Unique

Progettazione Logica Tabella Prestiti – Caratteristiche degli attributi Nome Tipo • Id. Prestito • Fk. Libro. Prestito Contatore Numerico Intero lungo • Fk. Amico. Prestito Numerico Intero lungo • Inizio. Prestito Data • Consegna Data Presunta. Prestito • Consegna. Prestito Data Dim. Vincoli Primary key Foreing key link Tabella Libro Foreing key link Tabella Amico Not Null >= Inizio. Prestito

Osservazioni sui vincoli • Quasi tutti gli attributi delle tabelle presentano il vincolo Not Null, in quanto necessari per identificare il libro o il soggetto del prestito. • Solo nella Tabella Prestiti l’attributo Consegna. Prestito non prevede il vincolo Not Null in quanto non è possibile conoscere ex-ante quando il libro verrà restituito, comunque va inserita una data di consegna presunta obbligatoria. • Sia la data di Consegna. Presunta. Prestito che la data di Consegna. Prestito devono essere successive alla data di Inizio. Prestito.

Schema Logico

Esercizio 2

Chiavi • Le Chiavi necessarie in questa progettazione di Database sono: • Tabella Pazienti: attributo Cod, identifica univocamente un singolo paziente (Primary key) • Tabella Reparti: attributo Cod, identifica univocamente un singolo reparto (Primary key) attributo Primario (Foreing key link con tabella medici) • Tabella Medici: attributo Matr, identifica univocamente un singolo medico (Primary key) • Tabella Ricoveri: attributo Paziente (Foreing key link con tabella Pazienti) attributo Reparto (Foreing key link con tabella Reparti) Per identificare una singola ennupla dobbiamo utilizzare una superchiave formata da due attributi: Paziente – Inizio, lo stesso paziente non può essere ricoverato più di una volta nello stesso giorno

Vincoli • Tabella Pazienti Tutti gli attributi devono contenere il vincolo Not Null in quanto necessari per identificare univocamente il paziente. • Tabella Ricoveri Vincolo Not Null per gli attributi: Paziente, Inizio, Reparto. Vincolo fra attributi: Inizio <= Fine, la data di inizio ricovero non può essere successiva a quella di fine ricovero. L’attributo Fine non deve prevedere il vincolo Not Null in quanto impossibile conoscere al momento del ricovero la data di fine ricovero.

Vincoli • Tabella Reparti Tutti gli attributi devono contenere il vincolo Not Null in quanto necessari per identificare univocamente il Reparto. • Tabella Medici Tutti gli attributi devono contenere il vincolo Not Null in quanto necessari per identificare univocamente il Medico.

Progettazione Logica Schema Relazioni Pazienti N N 1 Reparti 1 N N Ricoveri 1 N Medici

Definizione delle relazioni • Pazienti – Reparti Relazione N : N Un singolo paziente può essere ricoverato in diversi reparti, in un reparto possono essere ricoverati più pazienti. Ci serve la tabella Ricoveri: • Pazienti – Ricoveri • Reparti – Ricoveri Relazione 1 : N • Reparti - Medici Relazione 1 : N In un reparto possono lavorare più medici, mentre ogni medico è assegnato ad un singolo reparto (nel quale può essere primario).