Mapping Database Atsilo Mapping Database Atsilo Componenti : Antonio Cesarano Luca Di Costanzo Luigi Lomasto
Mapping Database AtsiloMapping Database Atsilo
Componenti :Antonio Cesarano
Luca Di Costanzo
Luigi Lomasto
Mapping del databaseMapping 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 Trade off (Relazionale vs Ad Oggetti)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 Trade off (Relazionale vs Ad Oggetti)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 mappingViene utilizzato per database di grandi dimensioni e
più complessi
CONTRO :Query più difficili da scrivere e da comprenderePerformance peggiori.
Dati persistentiDati 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 UtilizzateEuristiche 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 DatabaseMapping 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:INT descrizione:Varchar(100) personaleAsilo:Varchar(50)
Fattura
Mapping DatabaseMapping 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
descrizione personale_asilo
“Pagamento n°....” CSRNTC95L12C129M
“Pagamento n°....”
id
1
2
3
Foreign keyPrimary key
“Pagamento n°....”
RFTCTC94L12C139K
SDRTBC65F17S432R
Linee Guida UtilizzateLinee 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à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 OneAssociazione One to One
Domanda IscrizioneBambino 11
nome codice_fisc.
Bambino
Aldo RF124FGGC3D
Paolo DS874QCRG8R
Domanda Iscrizione
id
56
data codfisc
alice
79 john
RF12…
DS87…
Associazione One to ManyAssociazione One to Many
ClasseBambino *1
nome codice_fisc.
Bambino
Aldo RF124FGGC3D
Paolo DS874QCRG8R
classe
id
56
codfisc
79
RF12…
DS87…
Associazione Many to Associazione Many to ManyMany
id
Retta
23
name ...
novice
24 expertid_retta id_extra
Possiede
23 56
23 79
Extra
id
56
descr. ...
Supp…
79 Supp…
ExtraRetta **
Risoluzione delle Molteplicità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à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àRisoluzione Ereditarietà
Utente
NomeCognome
Codice Fiscale
Genitore
Tipo Account
Educatore Didattico
Titolo Studi
Genitore
nome codfisc Titolo studi ...
Paolo GF4F3… Diploma Superiore
nome codfisc Tipo Account ...
Marco GF4F3… Iscritto
Educatore Didattico