Compito di Laura Lorusso (565547) Abilità informatiche avanzate CdLM in Marketing
Analisi dei requisiti Si vuole automatizzare la gestione dei prestiti di una biblioteca personale. A tale scopo bisognerà memorizzare i dati relativi alle entità Amici e Libri. Il fine ultimo è ricavare informazioni relative ai Prestiti effettuati. Occorre considerare che il proprietario: indica i suoi amici semplicemente attraverso il nome o il soprannome (per evitare omonimie); fa riferimento ai libri attraverso i titoli e non possiede libri con lo stesso titolo; quando presta un libro prende nota della data prevista di restituzione.
Dominio applicativo E rappresentato da tutte le entità coinvolte nel sistema Biblioteca Personale relative alla gestione dei prestiti: Amici, Libri e Prestiti.
Schema entità-relazioni Amici Prestiti Libri 1 N N N 1 N
Progettazione concettuale Per lentità Amici sono stati individuati i seguenti attributi: Amici ID Amico Nome Amico Indirizzo Amico Telefono Amico Amico
Progettazione concettuale Libri Per lentità Libri sono stati individuati i seguenti attributi: ID Libro Titolo Libro Autore Libro
Progettazione logica DEFINIZIONE DELLE RELAZIONI Amici Libri N : N Un libro può essere preso in prestito da più amici Un amico può prendere in prestito più libri
Progettazione logica DEFINIZIONE DELLE RELAZIONI Amici Libri Prestiti N : N 1 : N N : 1
Progettazione logica DEFINIZIONE DELLE RELAZIONI Dalla relazione N:N deriva una ulteriore entità (PRESTITI) i cui attributi saranno i seguenti: ID prestito: codice univoco Campo link alla tabella Amici: definisce a chi è stato prestato il libro Campo link alla tabella Libri: definisce il libro che è stato preso in prestito Data concessione prestito Data prevista restituzione prestito
Progettazione logica DEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI Tabella Amici Nome campoTipo campoDimensioneVincoliNote IDAmicoNumericoIntero LungoPrimary keyContatore NomeAmicoTesto50Unique IndirizzoAmicoTesto40 TelefonoAmicoTesto15 AmicoTesto50 N.B. LAmico può avere più numeri di telefono, ma considerata lanalisi dei requisiti, non è necessario specificare questa relazione.
Progettazione logica DEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI Tabella Libri Nome campoTipo campoDimensioneVincoliNote IDLibroNumericoIntero LungoPrimary keyContatore TitoloLibroTesto150Unique AutoreLibroTesto50 N.B. Un autore, può aver scritto n libri, ma considerata lanalisi dei requisiti, non è necessario specificare questa relazione.
Progettazione logica DEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI Tabella Prestiti Nome campoTipo campoDimensioneVincoliNote IDPrestitoNumericoIntero LungoPrimary keyContatore FKAmicoPrestitoNumericoIntero LungoForeign keyLink alla tabella Amici FKLibroPrestitoNumericoIntero LungoForeign keyLink alla tabella Libri DataConcessione Prestito Data DataPrevistaRestit uzionePrestito Data
SCHEMA LOGICO
Considerazioni 1° punto Non è possibile ammettere valori nulli per i campi chiave il cui scopo è quello di identificare i record e realizzare riferimenti da altre relazioni. Ai fini di una adeguata gestione dei prestiti devono essere not null i campi NomeAmico e TitoloLibro; è sensato ammettere valori nulli per i campi DataConcessionePrestito e DataPrevistaRestituzionePrestito. Ritengo opportuno non inserire tale vincolo per il campo Amico, perché lamico potrebbe non avere una ; trattandosi poi di una biblioteca personale non è necessario imporre il vincolo not null per i campi IndirizzoAmico e TelefonoAmico, che potrebbero essere sconosciuti al proprietario dei libri. Infine, per quanto riguarda il campo AutoreLibro, trattandosi di un attributo di scarsa importanza è bene ammettere linserimento di valori nulli.
Considerazioni 2° punto Chiavi primarie Cod per la relazione Pazienti Paziente e Inizio per la relazione Ricoveri (a mio avviso è preferibile inserire una chiave IDRicoveri di tipo contatore) Matr per la relazione Medici Cod per la relazione Reparti Vincoli di integrità referenziale Tra lattributo Paziente nella relazione Ricoveri e lattributo Cod nella relazione Pazienti Tra Reparto in Ricoveri e Cod in Reparti Tra Primario in Reparti e Matr in Medici Tra Reparto in Medici e Cod in Reparti Valori nulli E sensato ammettere valori nulli per gli attributi Cognome e Nome nella tabella Pazienti, per lattributo Fine nella tabella Ricoveri, per gli attributi Nome e Cognome in Medici, per lattributo Nome in Reparti. Ad ogni modo ritengo che, ai fini di una corretta gestione del sistema Ospedale, tutti i campi dovrebbero essere Not Null.