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

N1

N

Progettazione concettuale

Per l’entità Amici sono stati individuati i seguenti attributi:

Amici

•ID Amico•Nome Amico•Indirizzo Amico•Telefono Amico•E-mail Amico

Progettazione concettuale

Libri

Per l’entità Libri sono stati individuati i seguenti attributi:

•ID Libro•Titolo Libro•Autore Libro

Progettazione logicaDEFINIZIONE DELLE RELAZIONI

Amici LibriN : N

•Un libro può essere preso in prestito da più amici•Un amico può prendere in prestito più libri

Progettazione logicaDEFINIZIONE DELLE RELAZIONI

Amici Libri

Prestiti

N : N

1 : N

N : 1

Progettazione logicaDEFINIZIONE DELLE RELAZIONI

Dalla relazione N:N deriva una ulteriore entità (PRESTITI) i cui attributi saranno i seguenti:

ID prestito: codice univocoCampo link alla tabella Amici: definisce a chi è stato prestato il libroCampo link alla tabella Libri: definisce il libro che è stato preso in prestitoData concessione prestitoData prevista restituzione prestito

Progettazione logicaDEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI

Tabella Amici

Nome campo Tipo campo Dimensione Vincoli Note

IDAmico Numerico Intero Lungo Primary key Contatore

NomeAmico Testo 50 Unique

IndirizzoAmico

Testo 40

TelefonoAmico

Testo 15

EmailAmico Testo 50

N.B. L’Amico può avere più numeri di telefono, ma considerata l’analisi dei requisiti, non è necessario specificare questa relazione.

Progettazione logicaDEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI

Tabella Libri

Nome campo Tipo campo Dimensione Vincoli Note

IDLibro Numerico Intero Lungo Primary key Contatore

TitoloLibro Testo 150 Unique

AutoreLibro Testo 50

N.B. Un autore, può aver scritto n libri, ma considerata l’analisi dei requisiti, non è necessario specificare questa relazione.

Progettazione logicaDEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI

Tabella Prestiti

Nome campo Tipo campo Dimensione Vincoli Note

IDPrestito Numerico Intero Lungo Primary key Contatore

FKAmicoPrestito

Numerico Intero Lungo Foreign key Link alla tabella Amici

FKLibroPrestito Numerico Intero Lungo Foreign key Link alla tabella Libri

DataConcessionePrestito

Data

DataPrevistaRestituzionePrestito

Data

SCHEMA LOGICO

Considerazioni 1° puntoNon è 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 EmailAmico, perché l’amico potrebbe non avere una e-mail; 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 l’inserimento di valori nulli.

Considerazioni 2° puntoChiavi 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 l’attributo “Paziente” nella relazione Ricoveri e l’attributo “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 nulliE’ sensato ammettere valori nulli per gli attributi Cognome e Nome nella tabella Pazienti, per l’attributo Fine nella tabella Ricoveri, per gli attributi Nome e Cognome in Medici, per l’attributo Nome in Reparti.Ad ogni modo ritengo che, ai fini di una corretta gestione del sistema Ospedale, tutti i campi dovrebbero essere Not Null.