Progettazione di database Gestione della biblioteca personale Pasquale de Tullio 565721

Analisi dei requisiti Si vuole progettare un DB per la gestione della biblioteca personale. È emerso che: Il proprietario presta libri ai suoi amici quando presta un libro prende nota della data prevista di restituzione fa riferimento ai libri attraverso i titoli

Dominio applicativo Nel nostro caso il dominio applicativo è rappresentato da tutte le entità coinvolte nel sistema Biblioteca personale in particolare quelle relative alla gestione del prestito dei libri ai propri amici

Schema entità - relazioni Proprietari Amici 1 n 1 Prestiti n Libri n 1 n n

Progettazione concettuale Nel nostro caso sono state individuate le seguenti entità: Proprietari Amici Libri

Progettazione concettuale Proprietari Sono stati individuati i seguenti attributi: Id proprietario Nome proprietario

Progettazione concettuale Amici Sono stati individuati i seguenti attributi: Id amico Nome amico Soprannome amico Tel amico Indirizzo amico

Progettazione concettuale Libri Sono stati individuati i seguenti attributi: Id libro Titolo libro Autore libro Genere libro Data restituzione

Progettazione logica definizione delle relazioni Proprietari Amici 1 n Un amico può avere un solo proprietario Un proprietario può avere più amici

Progettazione logica definizione delle relazioni Amici Libri n n Più libri posso essere prestati ad un amico Più amici possono avere in prestito un libro

Progettazione logica definizione delle relazioni 1 Libri Amici 1 n N : N Prestiti

Progettazione logica definizione delle relazioni Dalla relazione N:N deriva l’entità PRESTITI con i seguenti attributi: Id prestito Campo link a tabella Amici: definisce a chi è stato prestato il libro Campo link a tabella Libri: definisce che libro è stato prestato Data del prestito

Progettazione logica definizione degli attributi Tabella Proprietari Nome campo Tipo campo dimensione vincoli note Id Proprietario Numerico Intero Lungo PK Nome Proprietario testo 50 unique

Progettazione logica definizione degli attributi Tabella Amici Nome campo Tipo campo dimensione vincoli note Id Amico Numerico Intero Lungo PK Nome Amico testo 50 Not null Soprannome Amico 25 Può anche non esserci Tel amico 15 Indirizzo amico Fk id Proprietario FK Link a tabella proprietari

Progettazione logica definizione degli attributi Tabella Libri Nome campo Tipo campo dimensione vincoli note Id Libro Numerico Intero Lungo PK Titolo libro testo 40 unique Autore libro Not null Genere libro Data restituzione data

Progettazione logica definizione degli attributi Tabella Prestiti Nome campo Tipo campo dimensione vincoli note Id prestito Numerico Intero Lungo PK Fk Amici FK Link a tabella amici Fk Libri Link a tabella libri Data prestito data Not null

Caso Ospedale

Caso Ospedale Chiavi: Tabella Ricoveri sono FK Pazienti : “Paziente” FK Reparti: “Reparto” Manca Id Ricovero Tabella Pazienti è PK: Cod Tabella Reparti è PK: Cod Tabella Medici è Pk: matr Fk: reparto

Caso Ospedale Vincoli di integrità referenziale e gli attributi sui quali si possono ammettere valori nulli: non ci possono essere medici con stessa Matricola (matr di Medici: Unique) un medico deve essre primario di un solo reparto (voce primario di Reparti deve essere not null e unique) in un reparto ci possono essere più medici, non tutti i medici possono essere primari (voce reparto di medici not unique e not null, ciò nel caso in cui nella tabella medici ci siano altri record) non ci possono essere pazienti con lo stesso codice (voce cod paziente unique) manca id ricovero in ricoveri non ci possono essere reparti con lo stesso nome (voce nome reparto deve essere unique) Data fine ricovero deve essere successiva data inizio ricovero Lo stesso paziente non può essere ricoverato nello stesso periodo in reparti diversi data inizio e data fine devono essere not null nome reparto deve essere not null