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