mini Appunti

Ridondanza

Ridondanza: si possono avere due tipi di ridondanze e cioè la ridondanza di database e la ridondanza di tabella (in realtà in un campo della tabella).

• Si ha ridondanza di database quando ci sono dati ripetuti in più tabelle (es. due tabelle con gli stessi campi o due tabelle che hanno alcuni campi con contenuti identici)È importante quindi non ripetere i contenuti nelle varie tabelle, ma questo si fa rispettando le regole della progettazione concettuale che impongono che ogni Entità debba avere delle caratteristiche opportune.
• Si ha ridondanza in un campo di una tabella quando ci sono troppi dati ripetuti nel campo.
  Ad esempio nella tabella:
  persone(id_persona, nome, cognome, comune)
  si ha ridondanza nel campo comune in quanto in questo campo si ripetono spesso gli stessi dati (i nomi dei comuni), proprio perché ci sono più persone dello stesso comune.

Ci occuperemo della ridondanza di tabella (visto che quella di database si risolve con una buona progettazione concettuale).

La ridondanza porta due problemi che sono:

• troppo spazio occupato per dei dati identici (che vengono conservati in genere come stringhe più o meno lunghe )
• anomalie: ovvero problemi che si possono presentare in un database mal progettato. Un database è mal progettato se ad esempio presenta tabelle con campi ridondanti oppure contenuti ripetuti su più tabelle o altro. Ci sono in particolare tre tipi di anomalie: anomalie da inserimento, anomalie da modifica, anomalie da cancellazione.
  • anomalie da inserimento: si hanno quando si cerca di inserire dati in un database mal progettato
  • anomalie da modifica: si hanno quando si cerca di modificare dati in un database mal progettato
  • anomalie da cancellazione: si hanno quando si cerca di cancellare dati in un database mal progettato

Per risolvere (diminuire) la ridondanza in un campo si procede nel seguente modo:

1. Si crea un’altra tabella contenente (almeno) due campi: il campo contenente i dati (ripetuti una volta sola) e un campo chiave primaria
2. Al posto del campo ridondante si mette un campo di tipo numerico che diventa chiave esterna.

Esempio:
persone(idpersona, nome, cognome, idcomune)
comuni(idcomune, comune)
dove il campo idcomune della tabella persone diventa chiave esterna e
tra persone e comuni si crea una relazione molti a uno (M-1) che vuol dire che più persone risiedono o nascono (a seconda di come viene usato il campo) nello stesso comune.

In realtà, ha senso creare questa seconda tabella (nell’esempio: comuni), solo se, essa stessa, rappresenta un’entità e cioè un elenco di cose, oggetti, persone che ha delle caratteristiche.

In questo modo non si risolve del tutto il problema legato allo spazio ma di sicuro lo spazio occupato dopo aver seguito questa procedura risulta di molto inferiore a quello occupato con campi ridondanti (si passa dalla memorizzazione di stringhe più o meno lunghe alla memorizzazione di numeri interi). Viene invece eliminato il problema delle anomalie.

NB: nella progettazione concettuale non esiste il concetto di chiave esterna perché questa deriva dalla traduzione di un’associazione tra entità. Cioè ad esempio l’associazione “nascere” tra le entità: “Persona” e “Comune” nel diagramma E/R si traduce nello schema logico inserendo il campo “idcomune” come chiave esterna della tabella “Persone” che fa riferimento al campo “idcomune” della tabella “Comuni” che lì è chiave primaria.