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
n
Prestiti
n
Libri
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
n
1
Libri
Amici
1
N
n
:
Prestiti
N
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
Id Proprietario
Numerico
Intero Lungo
PK
Nome
Proprietario
testo
50
unique
note
Progettazione logica
definizione degli attributi
Tabella Amici
Nome campo
Tipo campo
dimensione
vincoli
Id Amico
Numerico
Intero Lungo
PK
Nome Amico
testo
50
Not null
Soprannome
Amico
testo
25
Tel amico
testo
15
Not null
Indirizzo amico
testo
25
Not null
Fk id
Proprietario
Numerico
Intero Lungo
FK
note
Può anche
non esserci
Link a tabella
proprietari
Progettazione logica
definizione degli attributi
Tabella Libri
Nome campo
Tipo campo
dimensione
vincoli
Id Libro
Numerico
Intero Lungo
PK
Titolo libro
testo
40
unique
Autore libro
testo
40
Not null
Genere libro
testo
40
Not null
Data
restituzione
data
Not null
note
Progettazione logica
definizione degli attributi
Tabella Prestiti
Nome campo
Tipo campo
dimensione
vincoli
Id prestito
Numerico
Intero Lungo
PK
Fk Amici
Numerico
Intero Lungo
FK
Link a tabella
amici
Fk Libri
Numerico
Intero Lungo
FK
Link a tabella
libri
Data prestito
data
Not null
note
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