Vincoli di integrità (integrity constraints)

martedì 5 giugno 2007 alle 05:04 | Pubblicato su Diario, SQL | Lascia un commento

Colgo lo spunto da questo thread del gruppo USENET cdos per scrivere questo post di tipo pseudo-didattico sui vincoli di intergrità referenziale.

Cosa sono i vincoli di integrità?

Si tratta di regole che il sistema RDBMS permette all’utente di definire sullo schema dei dati che impongono dei vincoli su come i dati possono essere salvati dal sistema. Detto con la terminologia in uso oggi sono delle regole per garantire il rispetto delle business rules. Gli standard ANSI/ISO SQL definiscono varie tipologie di vincoli, Oracle non le implementa tutte. In altri termini si tratta di un meccanismo di controllo della consistenza dei dati attuato dallo stesso RDBMS anzichè dal software o dall’utente che immette i dati.

Nel proseguo farò un po’ di confusione con la terminologia, parlando di tabelle, record, campi dove forse si dovrebbe parlare di insiemi, tuple e non so cos’altro.

Quali sono i vincoli di integrità?

Vado secondo un mio ordine mentale ad elencare i più noti e importanti vincoli di integrità che si definiscono sui database:

  • Chiave Primaria (Primary Key) si tratta (attingo dalla mia memoria degli studi accademici) dell’insieme minimo di campi (o colonne) che permette di identificare in modo univoco un record all’interno di una tabella. In tale definizione credo rientri anche il vincolo tali campi non assumano mai valore “null”. Se non rientre nella definizione si tratta in ogni caso di una regola secondo me da rispettare.
  • Chiave Esterna (Foreign Key) serve a gestire il classico caso di relazione (vedi teoria database relazionale), si tratta di un insieme di campi (o colonne) che fa riferimento alla chiave primaria di un’altra tabella, significa che i valori di una chiave esterna identificano in modo univoco un record in un’altra tabella
  • Chiave Univoca (Unique Key) è un vincolo più leggero di quello di chiave primaria: impone che per un certo insieme di campi (o colonne) non vi possono essere più record con gli stessi valori. La differenza con la chiave primaria è che non si tratta dell’insieme minimo di campi o colonne, e forse si rilassa anche il vincolo di non nullità.
  • Check Constraint (non so come tradurlo bene) si tratta di un vincolo molto generico, permette di usare delle funzioni per controllare la conformità dei dati a determinate regole che possono essere anche piuttosto complesse.

Ora, a rigore dovrei proseguire nell’esposizione delle modalità di definizione e utilizzo in Oracle di tali vincoli di integrità, invece, essendo questo un BLOG, da me usato come calderone di idee sparse voglio fare le mie considerazione sull’argomento anche in aggiunta a quando già detto nel thread sopra citato che ha ispirato questo post. Sulla base teorica, la definizione dei vincoli di integrità su una base dati è un’attività imprescindibile la realizzazione di un progetto software con ambizione di successo. Ne parla molto, anche in modo convincente, Thomas Kyte nel suo libro. Però voglio confessare una cosa: il software sviluppato dove lavoro utilizza un database su cui non sono definiti vincoli di integrità (salvo qualche eccezione), non vi è traccia di vincoli di integrità referenziale.

Pare che anche chi ha inizialmente preso tale decisione sia un po’ pentito di tale scelta. Il rispetto delle regole sui dati è stato lasciato quasi interamente al software e non al RDBMS, nonostante ciò non vi sono state catastrofi, vi sono stati alcuni casi di dati inconsistenti ma nulla che abbia fatto naufragare l’azienda ed il prodotto. A me viene spontaneo fare l’analogia con la teoria dell’ingegneria del software e il ciclo di vita del software così come li ho studiati all’università. Nella mia breve vita lavorativa non ho visto nulla di ciò che mi è stato raccontato all’università riguardo al modo di creare un prodotto software, partendo da precise e dettagliate specifiche ecc. ecc. Allo stesso modo anche rinunciare alla definizione precisa di tutti i vincoli di integrità sul database ha significato un minimo risparmio di energie (soldi per l’azienda) che non hanno provocato un costo successivo, per lo meno non superiore al beneficio.

Quindi voglio fare un po’ “l’avvocato del diavolo” dicendo che forse non è così grave iniziare un progetto software senza definire sulla base dati gli opportuni vincoli di integrità. D’altronde devo con rammarico fare una constatazione, che troppo spesso il successo di un’azienda e dei suoi prodotti non sono dati dalla qualità intrinseca ma dalle politiche di marketing, oggi la concorrenza sul mercato dell’IT sembra veramente spietata

Lascia un commento »

RSS feed for comments on this post. TrackBack URI

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: