Facoltà di Architettura e Società
Facoltà di Ingegneria Civile, Ambientale e Territoriale
Centro per lo Sviluppo del Polo di Cremona, Politecnico di Milano
Via Sesto 41 – 26100 Cremona
Master universitario interfacoltà di II livello in
Governo del territorio e delle risorse fisiche
Ingegneria del suolo e delle acque
http://www.cremona.polimi.it/msa
Direzione del Master universitario:
prof. Enrico Larcan (Facoltà di Ingegneria Civile, Ambientale e Territoriale, Politecnico di Milano)
prof. Pier Luigi Paolillo (Facoltà di Architettura e Società, Politecnico di Milano)
Commissione di Master universitario:
prof. Enrico Larcan – Facoltà di Ingegneria Civile, Ambientale e Territoriale, Politecnico di Milano
ing. Stefano Loffi – Direttore del Consorzio per l’Incremento dell’Irrigazione nel Territorio Cremonese
prof. Claudio Maffezzoni – Presidente del Centro per lo Sviluppo del Polo di Cremona, Politecnico di Milano
prof. Enrico Orsi – Facoltà di Ingegneria Civile, Ambientale e Territoriale, Politecnico di Milano
prof. Pier Luigi Paolillo (presidente) – Facoltà di Architettura e Società, Politecnico di Milano
Dispense dell’insegnamento di
Sistemi informativi territoriali e basi di dati
Concorrono al Master universitario in Governo del territorio e delle risorse fisiche – Ingegneria del suolo e delle acque:
Consorzio per l’incremento dell’irrigazione nel territorio cremonese
http://www.consorzioirrigazioni.it
Ordine degli ingegneri della provincia di Cremona
http://www.ording.cr.it
POLITECNICO DI MILANO
Master universitario interfacoltà di II livello in
Governo del territorio e delle risorse fisiche
Ingegneria del suolo e delle acque
http://www.cremona.polimi.it/msa
Indice
Introduzione
1
Parte I
La cartografia utile per i Sistemi Informativi Territoriali
1
1.1
1.2
I sistemi di riferimento
Il geoide come prima approssimazione della Terra
L’ellissoide di rotazione come sistema di rappresentazione finale della terra.
2
2.1
2.2
2.2.1
2.2.2
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.4
2.4.1
2.4.2
La rappresentazione della superficie della terra
Le coordinate geografiche
Le carte isogoniche, equivalenti ed afilattiche
La realizzazione di cartografia mediante le proiezioni prospettiche
La realizzazione di cartografia mediante le tecniche di sviluppo
Differenti tipi di cartografia utilizzabile
La carta di Mercatore
La cartografia Gauss Boaga o UTM
La proiezione stereografica polare
Carta Cassini-Soldner
La cartografia Italiana
La cartografia dell’Istituto Geografico Militare (IGM)
La Cartografia tecnica regionale della Regione Lombardia
9
10
10
11
11
14
3.
3.1
3.1.1
3.1.2
3.2
Alcune tecniche di rilevazione dei dati
Il telerilevamento
Un caso particolare di scanner nel telerilevamento: il MIVIS
Lo strumento del radar per la ricostruzione degli aspetti morfologici del terreno
Il sistema satellitare GPS e le sue implicazioni nei processi di governo del territorio
15
17
18
19
4
5
5
6
7
8
Parte II
I dati trattati nei Sistemi Informativi Territoriali
1
1.1.
1.2.
1.3
1.4.
1.5.
Le differenti tipologie di dati trattare da un SIT
I dati vettoriali
I dati raster
Gli attributi alfanumerici
Overlay topologico
Le tecniche di Buffering
21
21
22
23
24
25
POLITECNICO DI MILANO
Master universitario interfacoltà di II livello in
Governo del territorio e delle risorse fisiche
Ingegneria del suolo e delle acque
http://www.cremona.polimi.it/msa
2
2.1.
2.2.
2.3
2.4
2.5
2.6
Le principali caratteristiche dei dati e i software per il loro utilizzo
La conversione raster - vettoriale
Vantaggi e svantaggi delle rappresentazioni vettoriali o raster
Modalità di acquisizione dei formati vettoriali o raster
I software che trattano formati raster e vettoriali
I Data Base Management System (DBMS)
Le differenti tipologie di database
25
26
27
28
29
30
3.
3.1
3.2
3.3.
La qualità nei dati trattati da un SIT
Una prima distinzione delle scale di rappresentazione
Alcuni elementi di qualità dei dati
La congruenza del dato rispetto alla base di riferimento
31
32
32
4
4.1.
4.2.
4.3
La Rappresentazione del territorio in continuo/discreto
Il sistema di rappresentazione discreta
I vantaggi della discretizzazione del territorio
Esempi di trattamento dei dati per celle
32
33
34
Parte III
Le basi di dati
1
Il ciclo di vita di un sistema informativo
1.1
Lo studio di fattibilità
1.2.
Raccolta e analisi dei requisiti
1.3
La progettazione della base di dati
1.3.1 La progettazione concettuale
1.3.2 La progettazione logica della banca dati
1.3.3. La progettazione fisica del database
1.4.
Implementazione della base di dati
1.5.
Collaudo e operatività
36
37
37
37
37
43
44
45
45
36
1.
Il ciclo di vita di un sistema informativo
Uno degli aspetti più importanti di un sistema informativo che tendenzialmente rischia di essere sottovalutato soprattutto da coloro che per la prima volta si avvicinano a questo affascinante strumento, è l’organizzazione logica,
strutturale e contenutistica della base di dati.
Molto spesso infatti ci si limita ad inserire nuovi strati descrittivi, nuovi layer che rappresentano differenti fenomeni più o meno complessi, senza preoccuparsi tuttavia di relazionare tale strato con le informazioni già presenti nella banca dati. Questo rappresenta il più comune, ma anche il più grave errore che si possa commettere durante la
realizzazione di una banca dati e che determina la “vita o la morte” di un sistema informativo. Per ovviare a questo
problema che nel tempo potrebbe comportare ingenti risorse umane ed economiche per correggere tale errata impostazione, si dedicherà successivamente una breve spiegazione sui metodi di relazione delle differenti banche dati. L’esatta e corretta realizzazione di una banca dati determinerà la possibilità di tale “contenitore” di espandersi
ed adattarsi alla mutevole realtà, oppure di rimanere inerte ai cambiamenti che inevitabilmente nel corso del tempo si verificheranno. Ovviamente, la progettazione di un sistema informativo si basa sia su capacità tecniche sulla
sensibilità e l’esperienza di colui che è chiamato a realizzare la base di dati. Analizziamo brevemente qual è il ciclo di vita di un sistema informativo, in quanto solo conoscendo i passi fondamentali per realizzare una base di dati, è possibile fin da subito evitare errori che compromettono l’efficacia e l’efficienza della base di dati.
Solitamente colui che si accinge a realizzare una base di dati deve seguire una percorso ben definito, come una
successione passi, che possono essere ripercorsi ciclicamente.
Studio di fattibilità preliminare
Analisi dei
requisiti
Operatività
SIT
Collaudo
Progettazione
Implementazione
37
1.1.
Lo studio di fattibilità
Lo studio di fattibilità si pone principalmente 3 obiettivi e precisamente i) la valutazione delle differenti alternative
tenendo in debita considerazione sia gli aspetti economici, quali i costi relativi all’acquisto della strumentazione,
alla gestione del SIT, all’implementazione della base di dati ecc…., i vincoli fisici e in questo caso ci si riferisce
specificatamente alle dotazioni strumentali e i vincoli normativi.; ii) stabilire le priorità di realizzazione delle varie
parti del sistema informativo territoriale. A tal proposito è auspicabile lo sviluppo in via prioritaria di una parte della banca dati, lasciando l’implementazione di una seconda parte a tempi tecnico e normativi più maturi. Ad esempio la realizzazione di un DTM su vasta scala può essere effettuato solo con una strumentazione tecnica sufficientemente potente da contenere ed elaborare migliaia/milioni di dati, cosa che non può essere fatta con i computer
ormai datati. Un ulteriore esempio può essere quello della Valutazione Ambientale Strategica (VAS). Come si sa
la Regione Lombardia ha in cantiere una nuova legge urbanistica che prevede l’obbligo da parte dei comuni di
realizzare una VAS in casi di trasformazione del territorio. Tale necessità comporta senza dubbio uno sviluppo
della banca dati orientata verso le interazioni antropiche ed ambientali, ma che possono essere implementate solo
dopo l’entrata in vigore della legge. Di conseguenza è necessario iii) all’interno dell’architettura di un database definire con chiarezza le componenti indispensabili e necessarie da quelle facoltative o esclusivamente descrittive.
Inoltre all’interno di questa fase è di fondamentale importanza ottemperare le seguenti questioni: iv)
l’individuazione delle esigenze che un sistema informativo dovrà assolvere; v) l’individuazione della disponibilità
dei dati esistenti o reperibili presso i vari enti; vi) l’individuazione delle modalità di raccolta dei dati non esistenti,
ma necessari;
1.2
Raccolta e analisi dei requisiti
Nella fase di raccolta dei requisiti vengono definiti e focalizzati i problemi che il nuovo Sistema Informativo in
studio deve assolvere. Per far fronte a questa richiesta, è necessario in prima battuta conoscere i dati che si intendono trattare, e in seconda battuta le operazioni che si intendono effettuare su tali dati. Per ottemperare nel migliore dei modi questa fase, è sicuramente opportuno coinvolgere i futuri operatori del sistema informativo. In particolare è possibile definire, attraverso ripetute interviste, le necessità operative del sistema informativo. Risulta inoltre
necessario selezionare ed acquisire tutta la documentazione che deve essere gestita dagli utenti in modo da riuscire
a strutturare una sistema di acquisizione dati che abbracci tutto il panorama dei dati necessari. E’ sicuramente necessario effettuare un confronto sia con eventuali realizzazione di SIT preesistenti mediante la verifica di ciò che è
stato utilizzato sia con la normativa vigente e in particolare quella relativa alla privacy. Infatti da tale normativa è
possibile individuare limiti di accesso e di consultazione a banche dati che contengono dati personali e/o sensibili.
L’analisi dei requisiti deve inoltre definire i limiti di hardware e software per il funzionamento della banca dati.
1.3.
La progettazione della base di dati
La progettazione di una base di dati consente di approfondire e meglio definire l’impostazione del lavoro consentendo di stabilire le caratteristiche tecniche e funzionali del sistema. Nello specifico, possiamo far riferimento a 3
tipi di progettazione che rappresentano passi sequenziali necessari per la realizzazione della banca dati.
1.3.1. La progettazione concettuale
La progettazione concettuale che è certamente la fese più delicata e complessa in quanto richiede competenza,
professionalità ed esperienza. In questa fase è necessario ridurre di complessità la realtà nella quale viviamo descrivendola comunque in modo completo e rigoroso (in relazione agli obiettivi prefissati) utilizzando dei costrutti
e indipendente dalla realizzazione fisica. Deve essere formalizzato cioè, un modello concettuale in grado di descrivere l’organizzazione dei dati ad un alto livello di astrazione, senza tenere conto degli aspetti implementativi.
DI conseguenza si realizza uno schema concettuale denominato anche Schema Entità – Relazione in grado di descrivere al meglio le proprietà del dato ritenute importanti. L’utilità di questo schema è quello di semplificare no-
38
tevolmente la realtà del data base che si vuole realizzare, rendendo di conseguenza leggibile a tutti le intenzioni e i
passi necessari per raggiungere l’obiettivo dell’implementazione fisica.
Elemento
Simbolo grafico
Entità primitiva
Relazione
Attributo semplice
Attributo composto
Cardinalità di relazione
n 1; N 1
n 2; N 2
n;N
Cardinalità di attributo
A
Chiavi
Generalizzazione
B
39
Analizziamo ora singolarmente ogni singolo elemento della tabella sopra riportata.
Le entità rappresentano gli insiemi di oggetti di interesse della parte di mondo reale che si vuole descrivere. Da
un punto di vista concettuale le entità sono costruite per classificazione. Ad esempio possiamo creare un’entità
chiamata CITTA’ ed un’entità chiamata PERSONA. All’interno di uno schema E-R, ogni entità viene rappresentata da un rettangolo con scritto all’interno il suo nome univoco.
Le relazioni rappresentano legami ritenuti significativi per la descrizione della realtà di interesse tra due o più
entità. All’interno di uno schema E-R , ogni relazione viene rappresentata da un rombo con scritto dentro il suo
nome che deve essere univoco collegato alle entità con delle linee.
Gli attributi descrivono proprietà elementari di entità o relazioni che si giudicano rilevanti per la descrizione della realtà considerata. Ad esempio nome, cognome, età possono essere attributi dell’entità persona, mentre popolazione può essere attributo dell’entità città. Ciascun attributo può assumere un determinato insieme di valori che
viene chiamato dominio dell’attributo. In particolare il dominio può essere caratterizzato o da stringhe di caratteri, o da numeri interi, o da numeri decimali o da un insieme di elementi. A volte si usa accorpare attributi che
hanno affinità tra loro nei cosiddetti attributi composti. Ogni attributo viene rappresentato da un cerchietto collegato alla sua entità con scritto a lato il suo nome che deve essere univoco per ogni entità.
I principali elementi con i quali è possibile dare vita a un modello Entità - Relazioni sono gli attributi con i quali
si possono descrivere molti dati relativi ai sistemi. La progettazione avviene quasi sempre per affinamenti continui. Si parte da una prima ipotesi, si verifica se permette di catturare tutti gli elementi necessari e nel caso negativo si amplia lo schema”1
Nome
Impiegato
Partecipazione
Nome
Progetto
Matricola
Data Inizio
Budget
Codice
Data Fine
Altri costrutti del modello E-R sono la cardinalità di relazioni e la cardinalità degli attributi, gli identificatori e le
generalizzazioni. Anche in questo caso analizziamole singolarmente
Le cardinalità delle relazioni definiscono il numero massimo e minimo di volte di istanza della relazione cui le entità possono partecipar2e. Per chiarire il concetto di cardinalità delle relazione prendiamo in considerazione il prestito di libri in una qualunque biblioteca. Utilizzando come relazione il prestito in corso, possiamo affermare che
ogni libro può essere dato in prestito ad una sola persona per volta (da 0 a 1), mentre ogni persona può prendere in
prestito al massimo N libri.
Le cardinalità non sono nuovi elementi del modello E-R, bensì vincoli di integrità che si aggiungono alla relazione, sono cioè delle condizioni che le relazioni devono soddisfare per la loro validità.
All’interno di uno schema E-R, le cardinalità delle relazioni sono rappresentati da una coppia di parentesi posta
sulla linea di collegamento tra entità e relazione e contenente i valori di cardinalità minima e massima separati
da virgola. Ad esempio nel caso di cardinalità fino ad un massimo di 1 abbiamo (0,1)
Da un punto di vista delle cardinalità massime, si possono distinguere tre tipi di relazione tra due entità: i) relazione uno a uno; ii) relazione uno a molti; iii) relazione molti a molti3
1
Tratto dal libro Broglia, M “Il sistema Informativo Territoriale – Esperienza e Metodi”, Guerrini Associati, 2004
Tratto dal libro Broglia, M “Il sistema Informativo Territoriale – Esperienza e Metodi”, Guerrini Associati, 2004
3
Tratto dal libro Broglia, M “Il sistema Informativo Territoriale – Esperienza e Metodi”, Guerrini Associati, 2004
2
40
Per quanto riguarda le relazioni uno a uno esse presentano una cardinalità massima per entrambe le entità pari a 1.
Ad esempio nel caso delle relazioni tra nazione e capitale, ogni nazione ha una ed una sola capitale, così come la
capitale può fare riferimento ad una sola nazione.
(0,1)
(0,1)
Altro paio di maniche è quello che caratterizza la relazioni uno a molti, ove la cardinalità massima di una entità è
pari ad uno, mentre per l’altra entità è pari a N (numero indefinito). Ad esempio, se consideriamo la relazione della residenza, ogni singola persona possiede una, ed una sola, residenza in una città definita, mentre tale città, può
fungere da residenza ad un numero non definito di persone.
(1,1)
Persona
Residenza
(0,N)
Città
Per finire le relazioni molti a molti hanno entrambi le cardinalità massime pari a N. Un classico esempio di tale
relazione può essere la distribuzione commerciale dei libri da parte di differenti librerie. Ogni libro può essere distribuito da N librerie e viceversa ogni libreria può distribuire N libri.
(0,N)
(1,N)
Distribuzione
Libro
Librerie
Come è facilmente osservabile dagli schemi concettuali sopra riportati, la cardinalità relativa agli attributi identifica con estrema chiarezza il massimo e minimo numero di valori relativi a singolo attributo e che possono essere
relazionati ad ogni istanza di entità o relazione. In via del tutto approssimativa è possibile constatare che la maggior parte dei casi reali le cardinalità sono del tipo uno a uno (1, 1). A livello grafico la rappresentazione della cardinalità è affidata ad una coppia di parentesi posta sulla linea di collegamento tra entità ed attributo, all’interno delle quali si riportano i valori di cardinalità minima e massima, separati da virgola.
Cardinalità opzionale
Cardinalità obbligatoria
Cognome
PERSONA
(0,1)
(0,N)
Partita IVA
Conto Corrente
Cardinalità multivalore
Ogni persona detiene uno ed un solo cognome, ogni persona può possedere o meno una partita IVA, ogni persona può possedere o meno N conti correnti.
41
Per poter chiaramente identificare un’istanza è necessario fare affidamento alle cosiddette chiavi primarie le quali
possono essere costituite o da un solo attributo (e il caso della partita IVA o del Codice Fiscale) o da più attributi
nel momento in cui l’identificazione univoca di una entità avviene tramite l’unione di più elementi (ad esempio
volendo identificare correttamente un dipendente all’interno di una struttura universitaria non è sufficiente far riferimento al numero di matricola, in quanto lo stesso numero può essere riproposto a differenti studenti in differenti
atenei. E’ quindi necessario associare al numero di matricola anche la chiave primaria relativa l’attributo della facoltà rendendo univoci tutti gli studenti. Questo caso mette in evidenza che in alcune situazioni non è sufficiente la
chiave primaria per identificare un oggetto, ma è necessario aggiungere un’ulteriore chiave definita chiave esterna.
Tuttavia, perché la relazioni funzioni è necessario che Si noti che un identificatore esterno si può costruire solo se
l’entità esterna è in relazione con quella da identificare e quest’ultima partecipa alla relazione con cardinalità (1, 1).
Nello specifico è necessario che ogni studente sia iscritto ad una sola facoltà. Anche in questo caso le chiavi primarie non rappresentano esclusivamente degli elementi del modello E-R, ma attribuiscono il valore di vincoli sugli attributi. Un aspetto fondamentale da tenere in considerazione quando si progetta un database è che ogni entità
deve possedere almeno una chiave primaria.
Nell’immagine si riportano le chiavi primarie per l’identificazione di ogni singola area. Nello specifico è possibile
leggere il campo denominato ID_Zona_PRG_V con il quale si stabilisce la relazione univoca con il layer dei Piani regolatori vigenti e il campo ID_AREA_SU con il quale si stabilisce la relazione univoca con il layer delle a ree
soggette a sportello unico. Come è possibile osservare esistono altre chiavi che consento di identificare chiaramen-
42
te il comune di appartenenza COD_ISTAT nonché il codice catastale. Queste ultime chiavi consentono di relazionarsi con la banca dati ISTAT e con la banca dati CATASTALE.
Vediamo ora come di identifica la chiave primaria all’interno del modello entità relazione. Come è facilmente osservabile dalle immagini sotto riportate, se l’identificatore è costituito da un solo attributo, si disegna il suo cerchietto in colore pieno. Se sono necessari più attributi o una entità esterna relazionata, si uniscono i tratti di questi
elementi con una linea che termina in cerchietto con un colore pieno.
Anno
Cognome
PRATICA
PERSONA
Partita IVA
ProtGen
Conto Corrente
ProtInt
Come è osservabile sia dall’immagine che dallo scheda descrittivo posto a destra, ogni pratica dello Sportello Unico viene identificata da tre elementi: i) anno; ii) protocollo generale; iii) protocollo interno. Data la struttura del
database è possibile identificare univocamente l’entità anche utilizzando due soli attributi (Anno e protocollo generale). Il terzo attributo è inserito solo per rafforzare univocità e per facilitare la ricerca da parte del personale dello Sportello Unico.
43
Le generalizzazione rappresentano il rapporto gerarchico tra entità le cui istanze sono in rapporto di insieme e sottoinsieme. Le generalizzazioni possono essere parziali o totali. Sono totali quando le istanze della classe specifiche
coprono completamente le istanze della classe generale, in altre parole quando ogni istanza dell’entità generale è
almeno istanza di una delle entità specifiche. Sono parziali se ciò non avviene.
Un’altra delle proprietà delle generalizzazioni è quella di essere esclusive o sovrapposte. Una generalizzazione è
esclusiva quando le entità specifiche non hanno istanze in comune tra loro; è sovrapposta in caso contrario.
Per esempio “persona”è una generalizzazione totale ed esclusiva delle entità “uomo” e “donna”. “persona” è invece una generalizzazione parziale e sovrapposta di “studente” e “lavoratore”.
Elettrodomestico ad esempio è una generalizzazione parziale ed esclusiva delle entità “frigorifero”, “lavatrice” e
“televisore”.
Tutti colore che hanno a che fare con sistemi informativi di tipo territoriale hanno a che fare con le caratteristiche
geometriche delle entità che vanno a caratterizzare e trattare. Risulta quindi necessario inserire questa ulteriore variabile ossia quella della geometria delle entità. Il modello relazione sopra descritto prende in questo caso il nome
di Geo E-R e utilizza la seguente simbologia.:
1.3.2
La progettazione logica della banca dati
Il secondo passo della progettazione è rappresentato dalla progettazione logica la quale intende tradurre lo schema
concettuale del modello di rappresentazione di dati in uno schema di base dati aderente al modello effettivamente
presente nel sistema che gestirà la base dati stessa.
Schema concettuale
Progettazione logica
Schema logico
Lo schema logico è rappresentato da tabelle
con opportuni campi comuni. Lo schema
logico è ancora indipendente dagli aspetti
fisici, ma è molto vicino agli elementi
primitivi gestiti dal sistema reale. In tale
schema non vengono ancora identificati
esplicitamente i singoli campi di ogni tabella,
ma vengono identificati i legami intercorrenti
tra le varie tabelle o basi di dati.
Come
è
facilmente
osservabile
dall’immagine qui a fianco riportata è
possibile individuare con estrema facilità il
legame intercorrente tra le varie tabelle che
costituiscono il database.
44
1.3.3. La progettazione fisica del database
Il terzo passo è rappresentato dalla progettazione fisica e la si ottiene aggiungendo allo schema logico informazioni riguardanti le modalità fisiche di archiviazione dei dati.
Il prodotto di questa fase si chiama schema fisico dei dati. che, in pratica, è un diagramma disegnato usando simboli convenzionati. Questo diagramma viene poi tradotto in uno schema logico caratterizzata da una serie di tabelle relazionate tra di loro mediante l’identificazione di relazioni . A questo punto è possibile passare alla progettazione fisica consiste sostanzialmente nell’organizzazione dei file fisici e nella scelta di quali indici associare alle
tabelle.
L’immagine sopra riportata mette in evidenza un esempio di archivio realizzato in Access per la realizzazione della banca dati del Consorzio Area Alto Milanese.
Schema logico
Progettazione fisica
Schema fisico
45
Per riassumere la fase di progettazione si concretizza in 3 passaggi che determinano a loro volta 3 prodotti
Azione
Risultato
Progettazione concettuale
Schema concettuale
Progettazione logica
Schema logico
Progettazione fisica
Schema fisico
1.4.
Implementazione della base di dati
In questa fase si realizza materialmente la base di dati, sia in termini di costruzione del modello relazionale (mediante l’utilizzo di software Access o Excel), sia in termini di caricamento dei dati raccolti e/o disponibili in termini di riconoscimento per una loro classificazione. Solitamente si tratta della fase più lunga, nella quale il “data
entry” inserisce manualmente o con tecniche automatiche i dati relativi alle entità. Normalmente è anche il momento nel quale si determinano i maggiori errori: i) errori di ridondanza; ii) errori nella digitalizzazione dei dati;
iii) errori nella realizzazione della banca dati alfanumerica
1.5.
Collaudo e operatività
Conclusa la fase di implementazione dei dati, è necessario certificarne la qualità, ossia è necessario eliminare
scrupolosamente tutte le ridondanze e le anomalie dei dati allo scopo di garantire una maggiore qualità del sistema. Quando la qualità minima del progetto non è soddisfacente è perché si manifestano ridondanze dei dati
all’interno di differenti tabelle menomando la facilità d’uso e l’aggiornabilità dei dati.
Ad esempio uno dei casi che maggiormente di presentano all’interno di una base di dati e la ripetizione del dato
originario in più archivi creando problemi di ridondanza informativa. Tale errore può essere corretto mediante un
procedimento definito di normalizzazione consentendo la realizzazione di nuove relazioni correggendo le anomalie identificate.
