PROGETTAZIONE DI UN DATABASE

a cura di Santulli Domenica

Matricola 570121

ANALISI DEI REQUISITIProgettazione di una base di dati per la gestione dei prestiti di una biblioteca personale.

Il mio scopo è memorizzare i dati relativi a:• Libri• Amici• Autori• CaseEditrici

Il fine ultimo è ricavare le informazioni relative ai prestiti concessi da tale biblioteca personale.

Nello schema di base iniziale del mio database ho inserito anche le tabelle “Autori” e “CaseEditrici” al fine di evitare eventuali problemi di ridondanza ed incoerenza, legati ad alcuni attributi, in sede di inserimento dati.

SCHEMA ENTITÀ-RELAZIONI

Libri

AmiciAutori

Pubblicazioni

N

N

N

N

Prestiti

N

N

1

1

N

1

N

1

CaseEditrici

N

1

PROGETTAZIONE CONCETTUALE

La base di dati che ho progettato per la gestione della biblioteca personale prevede le seguenti entità, con i relativi attributi:

• Libri: NomeLibro, DataEdizione, FKCasaEditriceLibro

• Amici: Soprannome, Nome, Cognome, Telefono

• Autori: IDAutore, Nome, Cognome, DataNascita, LuogoNascita

• CaseEditrici: NomeEditore, Sitoweb, DataFondazione

PROGETTAZIONE LOGICADEFINIZIONE DELLE RELAZIONI

Fra l’entità Libri e l’entità Amici sussiste una relazione molti a molti (N : N): infatti, un libro può essere prestato a più amici (seppur in istanti temporali diversi e non coincidenti); ciascun amico, dal canto suo, può prendere a prestito più libri dalla biblioteca personale. Da tale relazione nasce la nuova entità:• Prestiti: IDPrestito, DataInizioPrestito, DataRestituzione, FKLibroPrestito, FKAmicoPrestito

Fra l’entità Libri e l’entità Autori sussiste una relazione molti a molti (N : N): infatti, un libro può essere scritto e pubblicato da più autori; ciascun autore può scrivere e pubblicare più libri. Da tale relazione nasce la nuova entità:• Pubblicazioni: IDPubblicazione, FKLibroPubblicazione, FKAutorePubblicazione

Fra l’entità CaseEditrici e l’entità Libri sussiste una relazione uno a molti (1 : N): infatti, una casa editrice può pubblicare più libri; ciascun libro può essere pubblicato da una sola casa editrice.

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteNomeLibro Testo 30 Primary Key

DataEdizione Data

FKCasaEditriceLibro

Testo 30 Foreign Key Link alla tabella CaseEditrici

Tabella LIBRI

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteSoprannome Testo 20 Primary Key

Nome Testo 20

Cognome Testo 20

Telefono Testo 15

Tabella AMICI

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteIDAutore Numerico Intero Lungo Primary Key Contatore

Nome Testo 20 Not Null

Cognome Testo 20 Not Null

DataNascita Data

LuogoNascita Testo 30

Tabella AUTORI

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteNomeEditore Testo 30 Primary Key

SitoWeb Testo 30

DataFondazione Data

Tabella CASEEDITRICI

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteIDPrestito Numerico Intero Lungo Primary Key Contatore

DataInizioPrestito Data Not Null

DataRestituzione Data Not Null

FKLibroPrestito Testo 30 Foreign Key Link alla tabella Libri

FKAmicoPrestito Testo 20 Foreign Key Link alla tabella Amici

Tabella PRESTITI

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteIDPubblicazione Numerico Intero Lungo Primary Key Contatore

FKLibroPubblicazione Testo 30 Foreign Key Link alla tabella Libri

FKAutorePubblicazione Numerico Intero Lungo Foreign Key Link alla tabella Autori

Tabella PUBBLICAZIONI

PUNTO 2Analisi della “Base di dati Ospedale”.

Di seguito individuerò:• Le chiavi della base di dati• I vincoli di integrità referenziale della base di dati• Attributi che possono ammettere valori nulli• Schema E-R• Progettazione logica

CHIAVI PRIMARIEINDIVIDUAZIONE DELLE PRIMARY KEY PER CIASCUNA TABELLA

Tabella PRIMARY KEY Tipo campo Dimensione NotePazienti Cod Testo 4

RicoveriPaziente Testo 4

Inizio Data

Medici Matr Numerico Intero lungo

Reparti Cod Testo 1

VINCOLI DI INTEGRITA’ REFERENZIALE

INDIVIDUAZIONE DEI VINCOLI DI INTEGRITA’ REFERENZIALE FRA LE DIVERSE TABELLE:

• vincolo fra l’attributo Paziente (della tabella “Ricoveri”) e l’attributo Cod (della tabella “Pazienti”);

• vincolo fra l’attributo Reparto (della tabella “Ricoveri”) e l’attributo Cod (della tabella “Reparti”);

• vincolo fra l’attributo Primario (della tabella “Reparti”) e l’attributo Matr della tabella “Medici”);

• vincolo fra l’attributo Reparto (della tabella “Medici”) e l’attributo Cod della tabella “Reparti”).

ATTRIBUTI CHE AMMETTONO VALORI NULLI

INDIVIDUAZIONE DEGLI ATTRIBUTI CHE POSSONO ASSUMERE VALORI NULLI:

• attributo Nome della tabella “Reparti”;

• attributi Nome e Cognome della tabella “Medici”;

• attributi Nome e Cognome della tabella “Pazienti”;

• attributo Fine della tabella “Ricoveri”.

SCHEMA ENTITÀ-RELAZIONI

Reparti

PazientiMedici

N

N

N

Ricoveri

1

N

1

N

1

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteCod Testo 1 Primary Key

Nome Testo 20

Primario Numerico Intero lungo Foreign Key Link alla tabella Medici

Tabella REPARTI

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteCod Testo 4 Primary Key

Cognome Testo 20

Nome Testo 20

Tabella PAZIENTI

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NotePaziente Testo 4 Primary Key-

Foreign KeyLink alla tabella Pazienti

Inizio Data Primary Key

Fine Data

Reparto Testo 1 Foreign Key Link alla tabella Reparti

Tabella RICOVERI (nasce dalla relazione N:N fra l’entità Reparti e l’entità Pazienti)

PROGETTAZIONE LOGICA

Nome campo Tipo campo Dimensione Vincoli NoteMatr Numerico Intero Lungo Primary Key

Nome Testo 20

Cognome Testo 20

Reparto Testo 1 Foreign Key Link alla tabella Reparti

Tabella MEDICI