Reverse Engineering di una base dati. Reverse Engineering di una base dati Pag. 2 ©Contenuti m...

Reverse Engineering Reverse Engineering di una base datidi una base dati

Reverse Engineering di una base dati Pag. 2©

ContenutiContenuti

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


IntroduzioneIntroduzione

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)


ScenarioScenario

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 …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 datiLa 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 concettualeLa 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 logicaLa 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 …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 La progettazione delle basi dati – differenze metodologiche – 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-fisicaLa 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 Dallo schema logico-fisico allo schema concettualeschema 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 Assegnare nomi significativi agli oggetti del modello conc.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 Normalizzare e rimuovere i dati “tecnici”“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”


DenormalizzazioniDenormalizzazioni

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 Denormalizzazioni – attributi ridondantiridondanti

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


Denormalizzazioni – indicatoriDenormalizzazioni – indicatori

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

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


Denormalizzazioni – attributi Denormalizzazioni – attributi derivati derivati

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

Gli attributi derivati sono attributi il cui valore è ricavato dal valore di altri attributi, ad esempio applicando algoritmi di calcolo


Denormalizzazioni – vettori 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 Denormalizzazioni – entità di decodifica decodifica

La normalizzazione della struttura produce lo schema che segue, in cui compaiono le due entità di decodifica: Tipo_Fornitura e Tipo_Contratto


ScomposizioniScomposizioni

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 Scomposizione verticale

Operando in modo inverso alla scomposizione, le due tabelle saranno ricomposte nel modello concettuale in un’unica entità:

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.


Scomposizione orizzontale Scomposizione orizzontale

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

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.


Introduzione di dati di natura Introduzione di dati di natura “tecnica”“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 Determinare le chiavi candidatecandidate 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 associazioniDeterminare 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 Integrare e “aggiustare” le entità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 Integrare e “aggiustare” le entità …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 Integrare e “aggiustare” le entità …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 Integrare e “aggiustare” le entità …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 Integrare e “aggiustare” le entità …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 Definire le gerarchie di specializzazionespecializzazione 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 Definire le gerarchie di specializzazione …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 Definire le gerarchie di specializzazione …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 Definire le gerarchie di specializzazione …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 Mapping tra gli schemi concettuale e logico-fisicoconcettuale 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 Mapping tra gli schemi concettuale e logico-fisico …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 Mapping tra gli schemi concettuale e logico-fisico …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à Approccio “misto” alle attività di R.E. 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à Approccio “misto” alle attività di R.E.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 Produzione di uno schema concettuale di sintesiconcettuale 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 Produzione di uno schema concettuale di sintesi …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 Produzione di uno schema concettuale di sintesi …concettuale di sintesi …Aggregare le gerarchie di specializzazione / generalizzazione (IS_A) in una macroentità costituita dal solo supertipo:


Produzione di uno schema Produzione di uno schema concettuale di sintesi …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 Produzione di uno schema concettuale di sintesi …concettuale di sintesi …Aggregare le entità attributive all’entità fondamentale a cui sono collegate


Dall’E/R al modello delle classiDall’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 …


Dall’E/R al modello delle classi …Dall’E/R al modello delle classi …

Cliente_Persona_Fisica Cliente_Persona_Giuridica

Cliente Ordine

0..n11 0..n

Prodotto

Riga_Ordine

1

1..n

1

1..n

0..n

1

0..n

1


GlossarioGlossarioAggregazioneE’ 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 candidataSi indica come chiave candidata di un'entità ogni attributo o insieme di attributi che permette di identificarne univocamente le occorrenzeSe 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

DDLData Definition Language. Linguaggio di definizione dei dati, messo a disposizione dai DBMS.

MappingCorrispondenza 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.

NormalizzazioneTecnica del modello relazionale, che serve a semplificare le strutture dei dati, eliminandone le ridondanze. Si possono ottenere più livelli di normalizzazione, chiamati forme normali.

DominioE’ un insieme di valori di significato omogeneo. Es: sigle delle province italiane, codici avviamento postale, codici società, …

Reverse Engineering di una base dati. Reverse Engineering di una base dati Pag. 2 ©Contenuti m...

Documents

Transcript of Reverse Engineering di una base dati. Reverse Engineering di una base dati Pag. 2 ©Contenuti m...