Compito 2 Progettazione DataBase Nicola Stornelli Statistica per le decisioni finanz. ed attuar. 570260.

Presentazione sul tema: "Compito 2 Progettazione DataBase Nicola Stornelli Statistica per le decisioni finanz. ed attuar. 570260."— Transcript della presentazione:

1 Compito 2 Progettazione DataBase Nicola Stornelli Statistica per le decisioni finanz. ed attuar. 570260

2 Esercizio 1 Database biblioteca Si vuole automatizzare la gestione dei prestiti di una biblioteca. A tale scopo bisognerà memorizzare i dati relativi ad i seguenti campi: LIBRI AMICI PRESTITI È ovvio che ciascun campo, chiamato entità presenterà delle caratteristiche (attributi).

3 Progettazione concettuale Nel nostro caso abbiamo considerato tre diverse entità: libri, amici e prestiti. Specifichiamo adesso i relativi attributi: ogni attributo è individuato da un nome, dal tipo e dalla dimensione. Linsieme degli attributi relativi ad unentità sarà chiamato dominio. Amici Per lentità amici sono stati individuati i seguenti attributi:

4 Idamico: codice univoco dellamico nomeamico: nome dellamico cognomeamico: cognome dellamico Libri Per lentità libri sono stati individuati i seguenti attributi: Idlibro: codice univoco del libro titololibro: titolo del libro

5 Prestiti Per lentità prestiti sono stati individuati i seguenti attributi: Idprestito: codice univoco del prestito datainizioprestito: data di inizio del prestito del libro dataconsegna: data di consegna del libro prestato Fkamicoprestito: amico che ha preso il libro in prestito Fklibroprestito: libro prestato

6 Schema entità-relazioni Amici Libri Prestiti 1 : NN : 1 NN

7 Definizione delle caratteristiche degli attributi Tabella amici NOME CAMPOTIPO CAMPODIMENSIONEVINCOLINOTE IdamicoNumericoIntero lungoPrimary key nomeamicoTesto20Not null cognomeamicoTesto30Not null

8 Tabella libri NOME CAMPO TIPO CAMPODIMENSIONEVINCOLINOTE IdlibroNumericoIntero lungoPrimary key titololibroTesto40Not null Unique

9 Tabella prestiti NOME CAMPO TIPO CAMPODIMENSIONEVINCOLINOTE IdprestitoNumericoIntero lungoPrimary key datainiziopres tito DataNot null dataconsegna prestito Data>=datainiziopr estito Fkamicoprestit o NumericoIntero lungoForeign keyLink alla tabella amici Fklibroprestito NumericoIntero lungoForeign keyLink alla tabella libri

10 Esercizio 2

11 Ogni tabella che compone il precedente riquadro sarà caratterizzata dalle seguenti chiavi: Per la tabella Pazienti la primary key sarà lattributo Cod, che identifica univocamente un singolo paziente. Nella tabella Reparti, lattributo Cod (primary key) identifica univocamente un singolo reparto. Nella stessa tabella lattributo Primario sarà una foreign key collegata con la tabella Medici.

12 Nella tabella Ricoveri vi sono due foreign keys: la prima è Paziente che collega la tabella Pazienti, la seconda è Reparto che collega rispettivamente la tabella Reparti. Tabella Pazienti Tutti gli attributi comprendono il vincolo Not null in quanto identificano il paziente Tabella Ricoveri Gli attributi Paziente, Inizio e Reparto saranno caratterizzati dal vincolo Not null

13 Poiché la data di inizio ricovero non può essere successiva a quella di fine ricovero, porremo il seguente vincolo: Inizio <= Fine. Lattributo Fine non può avere il vincolo Not null, in quanto al momento di inizio del ricovero, la data della dimissione del paziente è ancora ignota. Tabella Reparti Tutti gli attributi devono essere Not null per identificare in maniera univoca ogni reparto.

14 Tabella Medici Tutti gli attributi devono contenere il vincolo Not null.

15 Schema logico Pazienti Ricoveri RepartiMedici 1 N NNNN 1 N 1

16 Relazioni Pazienti-Reparti (N:N) Un singolo paziente può essere ricoverato in diversi reparti, e allo stesso tempo in un reparto possono essere ricoverati più pazienti Pazienti-Ricoveri (1:N) Reparti-Ricoveri (1:N) Reparti-Medici (1:1) In quanto in tale database fittizio vi è unidentità tra primari e medici, quindi un medico è presente in un solo reparto.