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
1
N
N
Prestiti
N
1
Libri
N
Progettazione concettuale
Amici
Per l’entità Amici sono stati individuati i seguenti
attributi:
•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 logica
DEFINIZIONE DELLE RELAZIONI
Amici
N
:
N
•Un libro può essere preso in prestito da più amici
•Un amico può prendere in prestito più libri
Libri
Progettazione logica
DEFINIZIONE DELLE RELAZIONI
1
:
N
Libri
Amici
N
:
1
N : N
Prestiti
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 campo
Tipo campo
Dimensione
Vincoli
Note
Contatore
IDAmico
Numerico
Intero Lungo
Primary key
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 logica
DEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI
Tabella Libri
Nome campo
Tipo campo
Dimensione
Vincoli
Note
Contatore
IDLibro
Numerico
Intero Lungo
Primary key
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 logica
DEFINIZIONE 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
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 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° 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 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 nulli
E’ 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.