Database: Personal Library 2°Compito Abilità Informatiche Av. Docente: Prof. A.Marengo Studente: Leonardo Ciriello Matr Università Degli Studi Di Bari L.M. in Marketing A.A. 2010/11
Schema Entita’-Relazioni Libri Datarestituzione Amici N N 1 : N N : 1
Progettazione Concettuale ENTITA’ Sono state individuate le seguenti entità: Libri Libri Amici Amici Data Restituzione Data Restituzione ENTITA’ LIBRI Per l’entità LIBRI sono stati individuati i seguenti attributi: Id_libro (primary key) Id_libro (primary key) Titolo_libro Titolo_libro ENTITA’ AMICI Per l’entità AMICI sono stati individuati i seguenti attributi: Id_Amico (primary key) Id_Amico (primary key) Nome_Amico Nome_Amico Soprannome_Amico Soprannome_Amico
Progettazione Logica Relazioni LibriAmici NN: Un libro può essere prestato a più amici Un libro può essere prestato a più amici Un amico può prendere in prestito più libri Un amico può prendere in prestito più libri
Progettazione Logica LibriAmici N1: N:1 Datarestituzione N : N
Progettazione Logica Dalla relazione N:N risulta opportuno per normalizzare, indicare una terza entità “Data Restituzione” i cui attributi sono i seguenti: Id_Data (Cod. univoco) Id_Data (Cod. univoco) Fk_tab_libri (Indica il libro prestato) Fk_tab_libri (Indica il libro prestato) Fk_tab_amici (Indica a chi è stato prestato) Fk_tab_amici (Indica a chi è stato prestato) Data_Restituzione Data_Restituzione
Progettazione Logica TABELLA LIBRI NomeCampoTipoCampoDimensioneVincoliNote Id_libron° intero lungo Pk Titolo_librotesto50unique
Progettazione Logica TABELLA AMICI NomeCampoTipoCampoDimensioneVincoliNote Id_amicon° intero lungo Pk Nome_amicotesto20 not null Soprannome_amicotesto10
Progettazione Logica TABELLA DATA RESTITUZIONE NomeCampoTipoCampoDimensioneVincoliNote Id_data_rest.n° intero lungo Pk Fk_libron° Fk link a tab libri Fk_amicon° intero lungo Fk link a tab amici Data restituzione data not null
In questo database, le Primary Key sono le seguenti: In questo database, le Primary Key sono le seguenti: Tab. Pazienti: “COD”; Tab. Pazienti: “COD”; Tab. Reparti: “COD”; Tab. Reparti: “COD”; Tab. Ricoveri: “PAZIENTE” e “INIZIO”; Tab. Ricoveri: “PAZIENTE” e “INIZIO”; Tab. Medici: “MATR” Tab. Medici: “MATR” La scelta fatta su RICOVERI implica che un paziente può essere ricoverato solo una volta nello stesso giorno. Nel caso in cui ciò non avvenga la relazione non è corretta. La scelta fatta su RICOVERI implica che un paziente può essere ricoverato solo una volta nello stesso giorno. Nel caso in cui ciò non avvenga la relazione non è corretta. Database: Ospedale
VINCOLI D’INTEGRITA’: VINCOLI D’INTEGRITA’: tra “Paziente” in RICOVERI e “Cod” in PAZIENTI; tra “Paziente” in RICOVERI e “Cod” in PAZIENTI; tra “Reparto” in RICOVERI e “Cod” in REPARTI; tra “Reparto” in RICOVERI e “Cod” in REPARTI; tra “Primario” in REPARTI e “Matr.” in MEDICI; tra “Primario” in REPARTI e “Matr.” in MEDICI; tra “Reparto” in MEDICI e “Cod” in REPARTI. tra “Reparto” in MEDICI e “Cod” in REPARTI. VALORI NULLI: “Cognome” e “Nome” in PAZIENTI; “Cognome” e “Nome” in PAZIENTI; “Fine” in RICOVERI; “Fine” in RICOVERI; “Cognome” e “Nome” in MEDICI; “Cognome” e “Nome” in MEDICI; “Nome” in REPARTI “Nome” in REPARTI N.B.: Questi attributi non sono chiavi e non hanno nessun vincolo d’integrità referenziale