Reverse Engineering
di una base dati
Contenuti



Introduzione e scenario di riferimento
La progettazione delle basi dati
Dallo schema logico allo schema
concettuale











Assegnare nomi significativi agli oggetti
Normalizzare e rimuovere i dati “tecnici”
Determinare le chiavi e le associazioni
Definire le gerarchie di
specializzazione/generalizzazione
Integrare le entità
Documentare il modello concettuale
Mapping schema concettuale / schema
logico-fisico
Approccio “misto” alle attività di R.E.
Produzione di uno schema di sintesi
Dall’E/R al modello delle classi
Glossario
©
Reverse Engineering di una base dati
Pag. 2
Introduzione

Il Reverse Engineering è un insieme di tecniche e di strumenti
che consentono di :

analizzare il software esistente
 derivarne in automatico la documentazione
 modificarne l'impostazione
 rigenerare il codice (Forward Engineering)

In particolare, a riguardo della componente dati di un sistema, è
possibile, tramite il reverse engineering, derivare le strutture
concettuali dei dati a partire da DDL o copy di tracciati record di
archivi esistenti

Ciò consente di fornire una rappresentazione concettuale delle
informazioni del sistema esistente, che può essere utilizzata
come base di partenza per la ri-progettazione (re-engineering)
©
Reverse Engineering di una base dati
Pag. 3
Scenario

Questa presentazione riporta un esempio di come si procede
per un reverse engineering della componente dati di
un’applicazione

Esiste una base dati relazionale (es: DB2 o Oracle) non
documentata e si vuole ottenere come risultato uno schema
concettuale dei dati e tutta la documentazione necessaria per:

capire il significato delle informazioni
 poter effettuare agevolmente la manutenzione della base dati
 evidenziare eventuali criticità rilevate sul modello
 individuare interventi di miglioramento, analizzando l’impatto su
quanto già realizzato.

Le attività da eseguire sono le seguenti:



analisi del DDL
derivazione dal DDL dello schema logico finale
produzione dello schema concettuale (per il significato dei diversi tipi di
schema vedere più avanti)
©
Reverse Engineering di una base dati
Pag. 4
Scenario …



Alcune attività possono essere effettuate in modo meccanico con il
supporto di un tool adeguato: è possibile ad esempio derivare in modo
automatico dal DDL uno schema logico-fisico dei dati
Ottenuto lo schema logico (un diagramma delle tabelle e dei loro
legami), si tratta di astrarre da questo uno schema concettuale dei dati,
indipendente dal DBMS e dall’ambiente tecnologico utilizzati.
E qui iniziano le vere difficoltà, l’attività può essere assai critica, in
quanto richiede una profonda conoscenza del significato e del dominio
dei dati e un’analisi attenta a risolvere problemi di omonimia e
sinonimia a tutti i livelli (entità, attributi, relationship)
Per condurre tale attività sarà probabilmente necessario:

coinvolgere le persone che hanno partecipato alla progettazione della base
dati attuale o altre persone esperte del dominio applicativo
 analizzare il codice applicativo al fine di ricavare altre informazioni non
dichiarate esplicitamente nella base dati, quali valori dei domini, regole di
integrità dei dati, ecc…
©
Reverse Engineering di una base dati
Pag. 5
La progettazione delle basi dati

La progettazione delle basi dati si articola nelle
seguenti fasi operative:




progettazione concettuale
progettazione logica
progettazione fisica
Ogni fase produce un risultato finale che viene detto
schema, così come evidenziato nella seguente
tabella:
Fase
Risultato
progettazione concettuale
schema concettuale
progettazione logica
schema logico
progettazione fisica
schema fisico
©
Reverse Engineering di una base dati
Pag. 6
La progettazione concettuale

La progettazione concettuale ha l’obiettivo di
tradurre i requisiti espressi dal cliente in una
descrizione formale delle informazioni necessarie al
sistema

Tale descrizione è detta schema concettuale, in
quanto:


è indipendente dalle caratteristiche di ogni specifico DBMS
la sua strutturazione dipende esclusivamente dai legami di
significato che esistono tra le varie informazioni in esso
contenute, non da criteri di efficienza
©
Reverse Engineering di una base dati
Pag. 7
La progettazione logica

La progettazione logica ha l’obiettivo di trasformare lo
schema concettuale in uno schema logico (iniziale)
conforme alle strutture proprie del DBMS scelto per la
realizzazione (es: schema logico gerarchico,
relazionale, ecc…)

La trasformazione in un modello logico relazionale si
basa sulle seguenti regole:

ogni entità viene trasformata in una tabella
 ogni attributo diventa una colonna
 per ogni relationship uno-a-molti, la chiave primaria dell’entità con il
verso a uno viene riportata come chiave esterna in quella con il verso
a molti
 per ogni relationship molti-a-molti viene creata una tabella
associativa, che ha come chiave primaria la concatenazione delle
chiavi primarie delle entità coinvolte nell’associazione
©
Reverse Engineering di una base dati
Pag. 8
La progettazione logica …

Normalmente, non è sufficiente effettuare una semplice
traduzione. Lo schema logico deve essere ottimizzato,
per consentire prestazioni adeguate ai sistemi che
operano sui dati

A tale scopo possono essere introdotte nello schema
modifiche quali: scomposizioni, denormalizzazioni,
ecc…

La trasformazione dà luogo alle strutture dati definitive
(es: tabelle, file, …) dello schema logico finale
©
Reverse Engineering di una base dati
Pag. 9
La progettazione delle basi dati
– differenze metodologiche

In alcune metodologie la progettazione fisica non è distinta da
quella logica, quindi le fasi si riducono a due:

progettazione concettuale
 progettazione logico-fisica.

Anche la terminologia può cambiare: si parla di modello logico in
luogo di modello concettuale e di modello fisico per quello logicofisico (ad es. è questo l’approccio di alcuni tool di modellazione
dati, quali Erwin, che distinguono tra un logical model e un
physical model)

E’ invece comune a tutte le metodologie la netta distinzione tra la
fase di modellazione (o progettazione) concettuale e le restanti
fasi
©
Reverse Engineering di una base dati
Pag. 10
La progettazione logico-fisica

La progettazione fisica ha l’obiettivo di completare lo
schema logico con i parametri fisici di memorizzazione
e di ricerca dei dati (indici, tablespace, …) tenendo
conto delle caratteristiche del DBMS e dell’ambiente
hardware e software in cui la base dati sarà realizzata.

Il risultato finale di questa fase è lo schema fisico
©
Reverse Engineering di una base dati
Pag. 11
Dallo schema logico-fisico allo
schema concettuale

Astrarre un modello concettuale da un modello logico
significa effettuare una serie di attività:








assegnare nomi significativi agli oggetti
normalizzare lo schema e rimuovere i dati “tecnici”
determinare le chiavi candidate (chiavi primarie e chiavi alternative)
determinare le associazioni (relationship) tra le entità
definire eventuali gerarchie di specializzazione / generalizzazione
integrare e “aggiustare” le entità
documentare tutti gli elementi del modello concettuale ottenuto
(entità, attributi, ecc…)
Normalmente queste attività non sono svolte in
maniera rigidamente sequenziale: si procede in modo
iterativo (per “aggiustamenti” successivi)
©
Reverse Engineering di una base dati
Pag. 12
Assegnare nomi significativi
agli oggetti del modello conc.

Spesso la denominazione degli oggetti della base dati
segue standard di nomenclatura aziendali, definiti allo
scopo di facilitarne l’implementazione e la gestione
negli specifici DBMS (es. una tabella è denominata
TACN0521, …)

Quando si effettua il R.E. è necessario assegnare alle
entità, agli attributi e alle relationship individuati un
nome significativo, che agevoli la comprensione delle
informazioni contenute nel modello concettuale (es:
l’entità derivata dalla tabella TACN0521, con chiave
primaria cod_fornitore è denominata FORNITORE)
©
Reverse Engineering di una base dati
Pag. 13
Normalizzare e rimuovere i dati
“tecnici”

L’attività comporta la rimozione delle
ridondanze e, più in generale, di tutte le
modifiche introdotte nel modello logico per
ottimizzare le prestazioni del sistema e
soddisfare i vincoli imposti dall’ambiente di
implementazione

Le modifiche più frequenti apportate al modello
logico possono essere:
 denormalizzazioni
 scomposizioni
 introduzione
di dati di natura “tecnica”
©
Reverse Engineering di una base dati
Pag. 14
Denormalizzazioni

Con la tecnica di denormalizzazione si procede in
maniera inversa rispetto alla normalizzazione

La normalizzazione dello schema concettuale ha lo
scopo di ridurre la ridondanza dei dati e prevenire le
anomalie che questa comporta per le operazioni di
aggiornamento

La denormalizzazione consiste nell’introdurre alcune
ridondanze nello schema logico con l’obiettivo di
ridurre il numero delle operazioni di I/O richieste per
reperire i dati necessari
©
Reverse Engineering di una base dati
Pag. 15
Denormalizzazioni – attributi
ridondanti
L’attributo rag_soc_forn nella tabella Ordine è da eliminare dallo
schema concettuale, in quanto ridondante
©
Reverse Engineering di una base dati
Pag. 16
Denormalizzazioni – indicatori
Gli indicatori servono a segnalare un preciso evento o una condizione
eliminando la necessità di eseguirne una verifica, accedendo ai dati di
un’altra tabella
Grazie all’indicatore ind_presenza_richieste non è necessario
accedere alla tabella Richieste_Servizi per verificare se esistono o
meno richieste a fronte di un determinato servizio. L’indicatore può
essere utile in ottica di ottimizzazione degli accessi, ma è ridondante e
quindi da eliminare dallo schema concettuale
©
Reverse Engineering di una base dati
Pag. 17
Denormalizzazioni – attributi
derivati
Gli attributi derivati sono attributi il cui valore è ricavato dal valore di
altri attributi, ad esempio applicando algoritmi di calcolo


L’attributo num_tot_dipendenti riporta il numero totale dei dipendenti di un
reparto evitando la necessità di effettuare gli accessi atti a recuperare i valori
“elementari” (in questo caso una lettura dell’intera tabella Dipendenti)
Attenzione: secondo un’opinione diffusa, gli attributi derivati non dovrebbero
essere presenti nel modello concettuale, in quanto ne comprometterebbero
l’essenzialità. Nel caso siano particolarmente rilevanti per il business,
possono essere inseriti, ma è importante esplicitarne le regole di derivazione
©
Reverse Engineering di una base dati
Pag. 18
Denormalizzazioni – vettori
Questa tecnica è utilizzata quando si è in presenza di dati ripetitivi (es:
dati mensili, …), con un numero di occorrenze predefinito, che sono
spesso acceduti insieme dalle applicazioni
Normalizzando la struttura si ottiene l’entità:
©
Reverse Engineering di una base dati
Pag. 19
Denormalizzazioni – entità di
decodifica
La normalizzazione della struttura produce lo schema che
segue, in cui compaiono le due entità di decodifica:
Tipo_Fornitura e Tipo_Contratto
©
Reverse Engineering di una base dati
Pag. 20
Scomposizioni

Con la tecnica di scomposizione si separa il
contenuto di un’entità in due o più tabelle

L’obiettivo è quello di ottimizzare le prestazioni,
riducendo le dimensioni delle tabelle ottenute quando il
numero delle righe e/o la dimensione della riga siano
molto elevati

Spesso si effettua tale partizionamento quando
l’utilizzo dei dati non è omogeneo, ad esempio quando
alcuni dati sono acceduti meno frequentemente di altri
©
Reverse Engineering di una base dati
Pag. 21
Scomposizione verticale
In questo tipo di scomposizione la struttura dati originaria è suddivisa in
modo da separare alcune colonne in una tabella e altre in un’altra
tabella. Le due tabelle hanno la stessa chiave primaria.
Operando in modo inverso alla scomposizione,
le due tabelle saranno ricomposte nel modello
concettuale in un’unica entità:
©
Reverse Engineering di una base dati
Pag. 22
Scomposizione orizzontale
La scomposizione orizzontale opera a livello di riga; in base a
determinate condizioni alcune righe andranno a finire in una tabella,
altre righe in un’altra tabella.
In questo caso le righe dell’entità Ordine
sono separate in due tabelle diverse in
base al loro stato: da un lato gli ordini da
evadere, dall’altro gli ordini evasi. Nel
modello concettuale le due strutture
andranno integrate in un’unica entità:
©
Reverse Engineering di una base dati
Pag. 23
Introduzione di dati di natura
“tecnica”


Spesso nel modello logico sono introdotti dati di natura “tecnica”,
che non sono rilevanti per il modello concettuale, ad esempio
attributi per gestire informazioni di audit, quali:

cod_ user_ultima_modifica,

timestamp_ultima_modifica, ecc…
In alcuni casi sono introdotte tabelle di appoggio per memorizzare
il risultato di qualche processo elaborativo in modo temporaneo
(ad es. il contenuto può essere cancellato a fine giornata). Se tali
tabelle non contengono informazioni proprie, ma dati ricavati da
altre entità del modello, non andranno rappresentate come entità
nel modello concettuale.
©
Reverse Engineering di una base dati
Pag. 24
Determinare le chiavi
candidate

Può accadere che le chiavi primarie non siano state
definite per tutte le tabelle

Occorre esaminare gli attributi (e i sottostanti domini)
per stabilire quali di essi possono essere utilizzati come
chiavi primarie o chiavi alternative

La presenza di indici univoci indica la presenza di chiavi
candidate
©
Reverse Engineering di una base dati
Pag. 25
Determinare le associazioni




L’attività considera l’esistenza di legami tra le entità,
ancorché non implementati nel DBMS
Si esaminano gli attributi (e i sottostanti domini) per
stabilire quali di essi sono utilizzati per riferimenti ad
altre tabelle. Tali attributi sono foreign key potenziali
Si introducono quindi nel modello le nuove relationship,
avendo cura di non introdurre relationship transitive
(ridondanti)
L’attività potrebbe richiedere un’analisi del codice
applicativo che implementa i controlli di integrità
referenziale
©
Reverse Engineering di una base dati
Pag. 26
Integrare e “aggiustare” le
entità

Non è raro che nello schema risultato di un primo R.E.
siano presenti più entità identiche o simili. Le ragioni
possono essere diverse: una tabella è la replica totale o
parziale di un’altra, le tabelle sono state introdotte da
gruppi di lavoro diverso per puro errore, le tabelle
provengono da due schemi non ancora integrati, ecc…

Occorre determinare se le entità simili possono essere
combinate in un’unica entità
©
Reverse Engineering di una base dati
Pag. 27
Integrare e “aggiustare” le
entità …

Sono sintomi di possibile identità:





il nome delle entità è simile o uguale
il nome degli attributi che formano la chiave primaria delle due entità è
uguale
i domini degli attributi che formano la chiave primaria delle due entità
sono uguali
la chiave primaria di un’entità è chiave alternativa nell’altra entità
La verifica di identità va condotta analizzando:



il significato delle entità in esame
i domini delle loro chiavi primarie
modalità e tempi di inserimento e cancellazione
©
Reverse Engineering di una base dati
Pag. 28
Integrare e “aggiustare” le
entità …

Se si verifica un’effettiva coincidenza, le due entità
possono essere unificate. La nuova entità risultante
riceverà:





il nome nella dizione più in generale
una chiave primaria (derivata eventualmente dalla scelta tra le chiavi
alternative)
tutti gli attributi delle entità originarie, denominati secondo la dizione più
generale
tutte le relationship in cui erano coinvolte le entità originarie,
denominate secondo la dizione più generale
L’unificazione di due entità può provocare anomalie:


necessità di normalizzare l’entità risultante
possibilità di introdurre relationship transitive (ridondanti), che
andranno eliminate dallo schema concettuale
©
Reverse Engineering di una base dati
Pag. 29
Integrare e “aggiustare” le
entità …
Esempio 1
Integrando insieme le due entità, Customer e
Clienti, l’entità risultante, Clienti, deve essere
ulteriormente normalizzata
Dopo l’integrazione e la normalizzazione, nello schema
concettuale otteniamo:
©
Reverse Engineering di una base dati
Pag. 30
Integrare e “aggiustare” le
entità …
Esempio 2
Supponiamo di dover integrare i due schemi:
Nello schema integrato compare una relationship transitiva (ridondante
perché dato un dipendente è possibile conoscere la società a cui
appartiene per il tramite del reparto di cui fa parte). La relationship andrà
eliminata dallo schema finale.
©
Reverse Engineering di una base dati
Pag. 31
Definire le gerarchie di
specializzazione

Si esaminano le entità con attributi simili per stabilire se conviene
definire un’entità più generale (supertipo), in cui raccogliere gli
attributi comuni alle entità (sottotipo) e creare una gerarchia IS_A
(detta anche gerarchia di generalizzazione / specializzazione) tra le
entità

La nuova entità risultante riceverà:




una chiave primaria (derivata eventualmente dalla scelta tra le chiavi
alternative)
tutti gli attributi comuni alle entità sottotipo, denominati secondo la
dizione più generale
tutte le relationship comuni in cui erano coinvolte le entità sottotipo,
denominate secondo la dizione più generale
Ovviamente dalle entità sottotipo saranno rimossi attributi e
relationship comuni
©
Reverse Engineering di una base dati
Pag. 32
Definire le gerarchie di
specializzazione …
Si deve verificare se un’entità può considerarsi sottotipo
oppure supertipo di un’altra entità già presente nel modello
ed evidenziare la gerarchia IS_A:
©
Reverse Engineering di una base dati
Pag. 33
Definire le gerarchie di
specializzazione …
Si deve verificare se un’entità non sia da
partizionare: la presenza di un attributo
“definitore” (es.: tipo_cliente, tipo_contratto, …)
e/o una serie di attributi inapplicabili a seconda
della tipologia, può indicare l’esistenza di una
gerarchia IS_A
In questo esempio, gli
attributi nome_cliente,
cognome_cliente,
cod_sesso, non sono
applicabili per le persone
giuridiche: è opportuno
evidenziare la
specializzazione
(gerarchia IS_A):
©
Reverse Engineering di una base dati
Pag. 34
Definire le gerarchie di
specializzazione …
Possono esistere due o più entità che sono “simili” in termini di
attributi e significato. Le entità potrebbero costituire sottotipi di un
supertipo non ancora definito
E’ possibile evidenziare la
seguente gerarchia IS_A:
©
Reverse Engineering di una base dati
Pag. 35
Mapping tra gli schemi
concettuale e logico-fisico


Una volta ottenuto lo schema concettuale dei dati è importante
documentare il mapping (la corrispondenza) tra gli oggetti dello
schema concettuale e quelli presenti nello schema logico-fisico.
In altre parole è necessario documentare:



a fronte di ogni tabella, l’entità da cui è derivata
a fronte di ogni colonna, l’attributo o la relationship (nel caso di chiave
esterna) che l’ha originata
Nel caso in cui lo schema logico-fisico è il risultato di
denormalizzazioni o scomposizioni, si potranno verificare situazioni
in cui:



una tabella corrisponde a più entità (denormalizzazione)
più tabelle corrispondono ad un’unica entità (scomposizione)
una colonna non fa riferimento a nessun attributo specifico dello
schema concettuale, perché si tratta di una dato derivato (es:
imp_totale_ordine) o un dato di natura “tecnica” (es:
timestamp_ultimo_inserimento)
©
Reverse Engineering di una base dati
Pag. 36
Mapping tra gli schemi
concettuale e logico-fisico …

Occorre documentare e mantenere aggiornato il mapping (la
tracciabilità) tra le strutture concettuali e le corrispondenti strutture
logiche, allo scopo di facilitare le attività di manutenzione

Grazie al mapping è possibile:
 conoscere su quali oggetti fisici intervenire a fronte di una
modifica allo schema concettuale (ad es. la modifica di un’entità
su quali tabelle ha impatto?)
 effettuare un’impact analysis, valutando costi, tempi e difficoltà
dell’intervento di modifica
©
Reverse Engineering di una base dati
Pag. 37
Mapping tra gli schemi
concettuale e logico-fisico …

E’ importante, inoltre, documentare ogni modifica evidenziata a
livello dello schema logico-fisico rispetto allo schema concettuale,
fornendo, dove possibile, un’opportuna motivazione della scelta (ad
es. il motivo per cui un’entità è stata scomposta in due tabelle, o il
perché di un attributo ridondante, ecc…)

Conoscere le motivazioni delle scelte effettuate, ci permette di
intervenire in modo adeguato e rivedere tali scelte nel caso in cui
cambino le premesse (vincoli dell’ambiente di implementazione,
modalità di accesso alle informazioni, …)
©
Reverse Engineering di una base dati
Pag. 38
Approccio “misto” alle attività
di R.E.

L’approccio fin qui seguito è tipicamente bottom-up. A partire dagli elementi
fisici (tabelle definite nel DDL) si ricava una rappresentazione ad un più alto
livello di astrazione (lo schema concettuale dei dati), in parte attraverso
attività meccaniche, effettuabili con il supporto di un tool, e in parte
applicando meccanismi di astrazione e la normalizzazione

E’ possibile comunque adottare un approccio misto: partire con un
approccio top-down, producendo dapprima una bozza del modello
concettuale, applicando i meccanismi di astrazione classici dell’analisi dati.
Ovviamente è possibile procedere in questo modo se è disponibile una
conoscenza del dominio del problema (conoscenza diretta o acquisibile
attraverso interviste agli esperti del problema, l’analisi della
documentazione esistente, …)

Il modello prodotto dovrà essere confrontato ed opportunamente rivisto alla
luce dei risultati del R.E. condotto in modo canonico (bottom-up)
©
Reverse Engineering di una base dati
Pag. 39
Approccio “misto” alle attività
di R.E.

I vantaggi di un approccio “misto” possono essere così
riassunti:

è possibile acquisire fin da subito una conoscenza ad alto livello
delle informazioni e delimitare in modo opportuno il contesto
dell’analisi

è possibile suddividere il dominio del problema, identificando
sotto-insiemi logici in cui ripartire l’applicazione (se non è già
presente una ripartizione di questo tipo) ed assegnare ad ogni
sotto-insieme le entità e le corrispondenti tabelle

è possibile individuare più facilmente criticità, evidenziando gli
scostamenti tra quanto fisicamente realizzato e quanto
modellato inizialmente
©
Reverse Engineering di una base dati
Pag. 40
Produzione di uno schema
concettuale di sintesi

Nel caso in cui l’obiettivo sia un re-engineering dell’applicazione e il
Reverse Engineering sia condotto più allo scopo di comprendere le
informazioni principali del sistema che di documentare in modo
dettagliato l’esistente, ci si può fermare ad individuare gli oggetti di
business e le loro proprietà principali (soprattutto nel caso in cui il
sistema attuale dovrà essere ampiamente modificato)

In quest’ottica, se le entità desunte dalla basi dati, sono molto
numerose, può essere conveniente produrre uno schema
concettuale di sintesi, più facilmente consultabile rispetto ad uno
schema concettuale analitico
©
Reverse Engineering di una base dati
Pag. 41
Produzione di uno schema
concettuale di sintesi …

Lo schema concettuale di sintesi ha caratteristiche profondamente
diverse rispetto ad un normale (analitico) schema concettuale:




le entità vengono aggregate in macroentità, con conseguente
diminuzione del numero di relationship
sono evidenziati solo gli attributi rilevanti
L’obiettivo è quello di rendere più agevole la consultazione, non di
definire i dati e i relativi vincoli in modo esaustivo
Per aggregare le entità analitiche in macroentità è possibile
utilizzare i seguenti criteri:



aggregare le gerarchie di spec / gen (IS_A) in una macroentità
aggregare le entità di decodifica nell’entità a cui sono collegate
aggregare le entità attributive all’entità fondamentale a cui sono
collegate
©
Reverse Engineering di una base dati
Pag. 42
Produzione di uno schema
concettuale di sintesi …
Aggregare le gerarchie di specializzazione / generalizzazione (IS_A) in
una macroentità costituita dal solo supertipo:
©
Reverse Engineering di una base dati
Pag. 43
Produzione di uno schema
concettuale di sintesi …
Aggregare le entità di decodifica che hanno un’unica relationship
nell’ambito delle entità a cui sono collegate
©
Reverse Engineering di una base dati
Pag. 44
Produzione di uno schema
concettuale di sintesi …
Aggregare le entità attributive all’entità fondamentale a cui sono
collegate
©
Reverse Engineering di una base dati
Pag. 45
Dall’E/R al modello delle classi

Dallo schema concettuale, espresso in forma di Entity / Relationship
è possibile derivare senza difficoltà il diagramma delle classi di
oggetti (ovviamente solo la componente attributi delle classi)

Il modello Object Oriented è più ricco dal punto di vista semantico
rispetto all’E/R: normalmente quest’ultimo non prevede tutti i
meccanismi di astrazione del modello OO, quali ad esempio
l’aggregazione (IS_PART_OF); è bene sfruttare tutte le potenzialità
del modello OO per esprimere i vincoli sui dati
©
Reverse Engineering di una base dati
Pag. 46
Dall’E/R al modello delle classi …
©
Reverse Engineering di una base dati
Pag. 47
Dall’E/R al modello delle classi …
C lien te
O rdine
1
0 .. n
1
1 .. n
Client e_ P ers o na_ Fis ic a
Clie nt e_P ers on a_G iurid ic a
R iga _O rdin e
0 .. n
1
P ro dot to
©
Reverse Engineering di una base dati
Pag. 48
Glossario
Aggregazione
E’ il meccanismo per la costruzione di oggetti complessi aggregando oggetti componenti più semplici (es. un
ordine è un oggetto complesso costituito dalle righe ordine). Esprime una relazione IS_PART_OF tra una “parte”
e il “tutto”.
Chiave candidata
Si indica come chiave candidata di un'entità ogni attributo o insieme di attributi che permette di identificarne
univocamente le occorrenze
Se le chiavi candidate di un’entità sono più d'una, una di esse viene assunta come chiave privarimaria, quelle
restanti sono dette chiavi alternative
Es: l’entità CLIENTE ha come chiave primaria l’attributo codice cliente, come chiave alternativa il codice fiscale
DDL
Data Definition Language. Linguaggio di definizione dei dati, messo a disposizione dai DBMS.
Mapping
Corrispondenza tra gli elementi di un certo livello di astrazione e quelli di un altro livello; es. corrispondenza tra
una specifica entità del modello concettuale dei dati e la tabella o le tabelle in cui è implementata.
Normalizzazione
Tecnica del modello relazionale, che serve a semplificare le strutture dei dati, eliminandone le ridondanze. Si
possono ottenere più livelli di normalizzazione, chiamati forme normali.
Dominio
E’ un insieme di valori di significato omogeneo. Es: sigle delle province italiane, codici avviamento postale, codici
società, …
©
Reverse Engineering di una base dati
Pag. 49