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

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)

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)

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…

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

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

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

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

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 logico-fisico (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

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

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)

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)

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”

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

Denormalizzazioni – attributi ridondanti L’attributo rag_soc_forn nella tabella Ordine è da eliminare dallo schema concettuale, in quanto ridondante

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

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

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à:

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

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

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à:

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à:

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.

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

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

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à

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

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

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:

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.

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

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:

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):

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:

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)

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

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, …)

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)

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

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

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

Produzione di uno schema concettuale di sintesi … Aggregare le gerarchie di specializzazione / generalizzazione (IS_A) in una macroentità costituita dal solo supertipo:

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

Produzione di uno schema concettuale di sintesi … Aggregare le entità attributive all’entità fondamentale a cui sono collegate

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

Dall’E/R al modello delle classi …

Dall’E/R al modello delle classi …

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à, …