Mapping Database Atsilo Componenti : Antonio Cesarano Luca Di Costanzo Luigi Lomasto

Mapping del database Memorizzare i dati persistenti è uno dei problemi principali nello sviluppo di un software. Purtroppo i linguaggi di programmazione Object Oriented non forniscono un modo per salvare i dati, per questo motivo abbiamo deciso di utilizzare un Database Relazionale. Il modello relazionale si basa sul concetto di tabella. Ogni tabella è divisa in record composti da campi.

Trade off (Relazionale vs Ad Oggetti) Il database relazionale permette di memorizzare i dati in tabelle seguendo un linguaggio standard per le operazioni (SQL) PRO: Le query che andremo ad effettuare saranno più semplici da scrivere e comprendere. Le performance sono maggiori rispetto al modello ad oggetti. CONTRO: Bisogna effettuare un’operazione di mapping non sempre semplice.

Trade off (Relazionale vs Ad Oggetti) Il database ad oggetti aggiunge al modello del database relazionale nuove funzionalità per supportare l’utilizzo degli oggetti. PRO : Non bisogna effettuare un’operazione di mapping Viene utilizzato per database di grandi dimensioni e più complessi CONTRO : Query più difficili da scrivere e da comprendere Performance peggiori.

Dati persistenti Durante la fase di Analisi dei Requisiti è stato prodotto in output il documento relativo al Dizionario dei Dati contenente le specifiche sui dati presenti nel nostro sistema. Da questo abbiamo selezionato gli oggetti persistenti che dovranno essere salvati nel nostro database.

Euristiche Utilizzate Per individuare le classi, gli attributi e le relazioni abbiamo utilizzato l’euristica di Abbott. Esempio: “La maestra inserisce nel registro di classe le attività svolte dai bambini” Utilizzando l’euristica di Abbott individuiamo gli oggetti attraverso i nomi comuni (“ Maestra,Bambino,Registro,Attività ”) e le relazioni che intercorrono fra loro individuando i verbi ( “inserire”, “svolgere”)

Mapping Database Una volta individuata la classe e gli attributi da inserire nel database procediamo con il mapping. Il tipo di dato selezionato per la “descrizione” può coincidere a diversi tipi di dato presenti nel database (Es. text-char etc.) Fattura +id:INT +descrizione:String +personaleAsilo:String id:INTdescrizione:Varchar(100)personaleAsilo:Varchar(50) Fattura

Mapping Database Tabella FATTURA ID rappresenta la chiave primaria della nostra tabella in quanto attributo unico di ogni record. Il PersonaleAsilo è chiave referenziale della tabella Personale Asilo ed indica il codice fiscale dell’impiegato che ha emesso la fattura descrizionepersonale_asilo “Pagamento n°....” CSRNTC95L12C129M “Pagamento n°....” id Foreign key Primary key “Pagamento n°....” RFTCTC94L12C139K SDRTBC65F17S432R

Linee Guida Utilizzate Al fine di ottenere un modello di database “standard” abbiamo scelto di seguire le seguenti linee guida per evitare determinati problemi. Nomi delle tabelle in maiuscolo singolare. Nomi dei campi minuscolo singolare. Underscore al posto degli spazi. Caratteri speciali non permessi.

Risoluzione delle Molteplicità Le relazioni tra due o più entità danno vita a diversi tipi di associazione: One to One : Sono mappate inserendo la chiave esterna in una delle due tabelle. One to Many : Sono mappate inserendo la chiave esterna nella tabella con la cardinalità “*”. Many to Many : Sono mappate creando una tabella di smistamento che contiene le chiavi delle due tabelle.

Associazione One to One Domanda IscrizioneBambino 11 nomecodice_fisc. Bambino AldoRF124FGGC3D PaoloDS874QCRG8R Domanda Iscrizione id 56 datacodfisc alice 79john RF12… DS87…

Associazione One to Many ClasseBambino *1 nomecodice_fisc. Bambino AldoRF124FGGC3D PaoloDS874QCRG8R classe id 56 codfisc 79 RF12… DS87…

Associazione Many to Many id Retta 23 name... novice 24expert id_rettaid_extra Possiede Extra id 56 descr.... Supp… 79Supp… ExtraRetta **

Risoluzione delle Molteplicità E’ possibile risolvere l’associazione “one to one” o “one to many” con una tabella di smistamento come con l’associazione “many to many”. Trade Off Migliore manutenibilità. Performance peggiori.

Risoluzione Ereditarietà L’ereditarietà non è supportata dai database relazionali, per questo dobbiamo trovare un modo per eliminarla. Nel nostro caso avevamo la tabella “Utente” che era padre di “PersonaleAsilo”, “Genitore”, “Psico pedagogo” ed “Educatore Didattico”. Attraverso il mapping orizzontale abbiamo eliminato la tabella “Utente” inserendo gli attributi comuni nelle tabelle figlie e duplicando le relazioni della tabella padre.

Risoluzione Ereditarietà Utente Nome Cognome Codice Fiscale Genitore Tipo Account Educatore Didattico Titolo Studi Genitore nomecodfiscTitolo studi... PaoloGF4F3…Diploma Superiore nomecodfiscTipo Account... MarcoGF4F3…Iscritto Educatore Didattico