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.
Fattura
+id:INT
+descrizione:String
+personaleAsilo:String
Fattura
id:INT
descrizione:Varchar(100) personaleAsilo:Varchar(50)
Il tipo di dato selezionato per la “descrizione” può coincidere
a diversi tipi di dato presenti nel database (Es. text-char etc.)
Mapping Database
Tabella FATTURA
id
descrizione
personale_asilo
1
“Pagamento n°....”
CSRNTC95L12C129M
2
“Pagamento n°....”
RFTCTC94L12C139K
3
“Pagamento n°....”
SDRTBC65F17S432R
Primary key
Foreign key
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
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
Bambino
1
Bambino
nome codice_fisc.
1 Domanda Iscrizione
Domanda Iscrizione
id
data
codfisc
Aldo
RF124FGGC3D
56
alice
RF12…
Paolo
DS874QCRG8R
79
john
DS87…
Associazione One to Many
Bambino
1
* Classe
Bambino
nome codice_fisc.
classe
id codfisc
Aldo
RF124FGGC3D
56
RF12…
Paolo
DS874QCRG8R
79
DS87…
Associazione Many to Many
Retta
*
* Extra
Retta
id
name
23
novice
24
expert
Extra
...
id
Possiede
id_retta
id_extra
23
56
23
79
descr.
56
Supp…
79
Supp…
...
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
Educatore
Didattico
Genitore
Tipo Account
Titolo Studi
Educatore Didattico
nome
codfisc
Tipo Account
Marco
GF4F3…
Iscritto
Genitore
...
nome
codfisc
Titolo studi
Paolo
GF4F3…
Diploma Superiore
...