Progettazione di Database 

Normalizzazione


di Mike Tossy


Traduzione in Italiano di Antonio Campagna - Novembre 2001


Introduzione 

Intendo insegnare al lettore come progettare database relazionali. Il soggetto non è difficile. L'approccio è pratico. Non ci sono pre-requisiti indispensabili. 
Chi ha affrontato questo argomento potrebbe essere sorpreso che le formali nozioni accademiche   di “normalizzazione” e “forme normali”, sono state pressoché bandite completamente da questo testo. Questo è intenzionale. La mia esperienza di insegnamento in merito alla progettazione di database, mi conduce a credere che un approccio pratico sia più facile da comprendere. 

Background

Un database logico è una raccolta di fatti. La vostra società può avere un database del personale, dove sono contenuti i fatti dei suoi impiegati. La vostra società può avere un database di inventario, dove tiene i fatti sui numeri e generi di oggetti che possiede. In un database relazionale questi fatti sono tenuti in tabelle speciali che possono essere manipolate da un computer. Un database logico può avere molte tabelle relazionate. Per esempio, un database biblioteca potrebbe avere una tabella sui libri ed una tabella che gestisce le schede dei prestiti (queste tabelle sono correlate perché tramite la scheda prestiti si può verificare se il libro è in prestito ). Progettare database significa decidere quali fatti tenere ed in quali tabelle. 
Permetteteci di cominciare con della terminologia. Nei sistemi Database Relazionali come dB2K, i dati sono memorizzati in tabelle. Queste tabelle possono essere file dBase tradizionali (.DBF), file Paradox, o tabelle tenute in un sistema database SQL come Oracle o InterBase. Tutte le tabelle dB2K (e tutte quelle di tipo relazionale) consistono di righe (i record) e colonne (i campi) [1]. 

Ecco una tipica tabella dB2K mostrata in dQuery/Web.
 

 

Notate che tutte le righe nella tabella hanno la stessa struttura. Tutte hanno lo stesso numero di colonne ed il tipo di dato di una colonna è lo stesso per tutte le righe. (vecchi database non-relazionali non avevano questa caratteristica. ) 

Un database è una raccolta di tabelle che sono usate per tenere i dati necessari per uno scopo specifico o applicazione. Così il database di "risorse umane" è un insieme  di tabelle, come impiegati, specialisti e dipendenti necessari per sostenere il reparto di "sviluppo software". 
Il database di vendite è l'insieme  di tabelle che registrano dati di vendite e probabilmente includono tabelle  come articoli, vendite, clienti e spedizioni. 

Attenzione!

La parola database è usata incoerentemente dalla comunità dei programmatori. Non tutti i database sono relazionali e database non-relazionali non possono usare tabelle per memorizzare i loro fatti. Alcuni sistemi che dichiarano di essere relazionali non lo sono (in questa sede non affronteremo questa situazione). Alcune persone usano il termine "database" come  sinonimo di "tabelle".  Altre persone usano database per intendere un insieme di tabelle che sono memorizzate fisicamente insieme, ma non possono essere relazionate in alcun modo utile. Se qualcuno vi dice che loro hanno un “database” è meglio chiedergli che cosa intendono dire con il termine "database", come é anche possibile che loro potrebbero non comprendere cosa voi volete intendere per database. In questo documento il termine database è riferito sempre ad un database relazionale logico: cioè una raccolta di una o più tabelle relazionate. Per favore notate che una tabella potrebbe essere relazionale. Il termine relazionale non è correlato alla parola inglese "relationship" (relazione, rapporto di parentela)  oppure al termine "related" (relativo), ma piuttosto ad una parola convenzionale matematica sinonimo di tabella. Una tabella  è una "relazione".

Normalizzazione

La normalizzazione è il processo che ci fa decidere il "luogo adatto" in un database, dove memorizzare i vari pezzi di dati. È parte del processo di progettazione di un database. La normalizzazione è stata il soggetto di molto studio accademico. Gli accademici hanno definito una serie di “livelli di normalizzazione”, che sono normalmente descritti in documenti di questo tipo. In passato (negli anni ottanta) insegnai progettazione di database e ritengo che l'approccio accademico alla normalizzazione, non sia utile per istruire correttamente i principianti nella progettazione di database. Invece, con questo documento offro un insieme di regole pratiche ed esempi che vi insegneranno come progettare bene un database normalizzato. E' necessario che abbiate tabelle normalizzate correttamente, perché esse sono più facili da mantenere, più facili da consultare ed permettono di ridurre al minimo le possibili discordanze. Cominciamo:

La Regola dei Nomi: 

La maggior parte delle tabelle contengono fatti sui nomi (persone, luoghi, o cose). Ogni riga dovrebbe contenere informazioni precise circa una di queste persone, luoghi, o cose. 

La Regola della Chiave Primaria:

Tutte le tabelle hanno chiavi primarie. Una chiave primaria è la colonna(e) che definisce una riga in modo univoco. La chiave primaria per le tabelle dei nomi è la colonna(e) che distingue unicamente quel nome da ogni altro possibile in quella tabella. [2] 

Alcune tabelle hanno una naturale chiave primaria. La tabella "componenti" probabilmente usa il campo "compno" come la sua chiave primaria. Alcune tabelle non hanno una naturale chiave primaria, esse hanno bisogno di una chiave primaria artificiale. Ogni tabella deve avere una chiave primaria - inventatene una se non esiste in modo naturale. Questo non è così strano come sembra. I sistemi manuali lo fanno tutte le volte. Numero di impiegato, numero di serie e numero di targa sono tutti  esempi di chiavi primarie inventate. Voi potete usare la colonna di tipo "autoincremento" per questo scopo. Le buone chiavi primarie non cambiano col tempo e sono uniche. Per le persone voi dovreste inventare una chiave primaria. [3] 

La Regola degli Aggettivi: 

A parte la chiave primaria, pensate ad ogni colonna della tabella come un aggettivo. Contiene informazioni descrittive, fatti o attributi del nome rappresentate dalla riga. Ogni colonna in quella riga dovrebbe aderire a questa regola. Una colonna deve contenere costantemente lo stesso attributo da riga a riga. (Se quel attributo non si applica, la colonna è nulla o spazio vuoto.

Questo insieme di regole è quasi completo. Ecco un'utile prova per vedere se avete progettato bene la vostra tabella. 

La Frase Prova: 

Scrivete una frase che descriva la riga nella tabella. La frase risultante dovrebbe essere semplice, come “Ogni riga è un impiegato nella nostra società.” 

Una frase complessa come: 

Se il valore contenuto nel campo "tipo"  è il carattere 'I', la riga fa riferimento ad  un impiegato, se il valore è 'D' si tratta di un "dipendente" dell'impiegato(moglie, figlio,ecc),  è un cattivo segnale. Sicuramente avete  bisogno di ri-progettare le vostre tabelle. 

La frase si applica ad ogni colonna in ogni possibile riga? 

Deve
!!! 

Una frase come:

se il campo  "lunghezza cavo" contiene il valore falso, allora nel campo "lunghezza" ci sarà la lunghezza del totale del cavo, se invece "lunghezza cavo"  è vero, allora il campo "lunghezza"  conterrà la lunghezza di solo questo intervallo. [6], 

è guaio notevole. 

La vostra frase dovrebbe essere semplice, senza “se", "e", " o", "ma".

Facciamo degli esempi per mostrare le conseguenze di queste regole. Poi,  riprenderemo il discorso ed enunceremo le ultime due regole. 

Un semplice (sbagliato) esempio: 

Avere i nomi dei bambini del vostro impiegato nella tabella "impiegato" è sbagliato. Ecco tre ragioni:

  1. Che cosa succede se un impiegato ha più bambini di quanto voi avete previsto? Quanto è abbastanza Cinque? Dieci? Venti? Cento? 

  2. Avete sprecato spazio. La maggior parte degli impiegati avranno meno bambini di quanto voi possiate ritenere sia abbastanza. (Spazio su disco rovinato. Non è un grosso problema visto che la tecnologia offre dischi di notevoli dimensioni, ma sicuramente le operazioni di I/O  non saranno ottimali: lettura e scrittura di campi vuoti che inevitabilmente rallentano il sistema. ) 

  3. Tentate di scrivere un semplice query SQL che trovi tutti i bambini chiamati 'Mike.' Non può essere fatto facilmente e più campi aggiungete peggio sarà. ( Questa è la più importante ragione per cui bisognerebbe evitare di usare questo tipo di progettazione. ) 
     

Nota: nomi colonna con numeri, come quelli mostrati nella tabella impiegati, sono quasi sempre un indizio che la tabella è scarsamente normalizzata. Dalla definizione della Regola degli Aggettivi su citata dovreste capire che la progettazione di questa tabella è sbagliata, nameOfChildX è un attributo del bambino, non dell'impiegato. 

Sarebbe meglio: 

 

Il processo di "spezzettare" la prima tabella in due tabelle è chiamato normalizzazione. 

Finora abbiamo un semplice caso di tabelle che contengono solamente informazioni su persone. È abbastanza facile vedere come ciò potrebbe essere esteso a luoghi o cose. Questo genere di relazione è chiamata "relazione uno-a-molti" (o 1:M). È una relazione 1:M perché ogni impiegato può avere zero o più figli e ciascun figlio ha precisamente un impiegato. Questa situazione copre la maggior parte, ma non tutti i casi. Nelle tabelle precedenti abbiamo supposto che tutti i bambini erano i figli di un determinato impiegato. È probabile che questa situazione sia OK, ma potrebbe non esserlo. [4] 

Supponiamo che abbiate la necessità di rappresentare la possibilità che un bambino sia un figlio di due impiegati. Abbiamo bisogno di alcune nuove regole: 

La Regola delle Relazioni: 

Entrambe le tabelle contengono fatti su nomi o fatti su relazioni tra nomi (Chi possiede un'auto? in quale reparto lavora? Quale prodotto fu inviato a quale cliente?) 

La Regola della Chiave Primaria per le Relazioni: 

Le tabelle delle relazioni hanno una naturale chiave primaria. È la colonna(e) della chiave primaria di entrambe le tabelle che sono in relazione. ( Non usate una colonna di tipo  autoincremento  come chiave primaria in una tabella di relazioni. ) 

La Regola di Aggettivi (Corretta): 

A parte la chiave primaria, pensate ad ogni colonna come un aggettivo. Un aggettivo contiene informazioni descrittive, fatti, o attributi del nome o della relazione rappresentata dalla riga. Ogni colonna in quella riga dovrebbe aderire a questa regola. Una colonna deve contenere costantemente lo stesso attributo da riga a riga. (Se quel attributo non si applica, la colonna è nulla o spazio vuoto. )

Perché le relazioni? Torniamo indietro all'esempio impiegati/figli 

sarebbe meglio: 

Clark ha due bambini (John e Joanne). Gretchen ha un bambino (Joanne) per cui lei divide la responsabilità con Clark ( Clark e Gretchen potrebbero essere sposati). Joanne potrebbe essere il risultato del loro matrimonio. È probabile che John sia il risultato del precedente matrimonio di Clark. (Il database non ha abbastanza informazioni  che ci diano la certezza di questa situazione. ) Mark Jones ha un bambino (Tom). (Il database non registra se Mark sia sposato o celibe. Ma sappiamo che Tom non è registrato come figlio di alcun altro impiegato. ) Mary Ann Singleton non ha figli. 

Questa situazione  é  chiamata relazione molti-a-molti  (o M:M). È una relazione M:M perché, un impiegato può avere zero o più figli, ed un figlio può avere zero o più impiegati. ( Se volete limitare che a ciascun figlio ci sia almeno 1 e non più di 2 impiegati, avrete bisogno di costruire delle "regole di gestione". La progettazione di database - da sola - non può offrire questi  limiti. ) 

Credetelo o no, ora avete abbastanza regole per normalizzare un database. Comunque un altro poco di esempi potrebbe essere di maggiore aiuto. 

Esempio: Sistema di Gestione degli Ordini di Riparazione 

Supponete che stiate realizzando un sistema che tenga "traccia" delle  riparazioni effettuate in un garage. I nomi (persone, luoghi, o cose) che potrebbero essere necessari controllare sono: clienti, ordini riparazioni e personale. Queste tre tabelle sono un buon inizio:
 

 

Adesso quali sono le relazioni che bisogna individuare?  

Le tabelle Repair_Order e Service_Staff sono relative a chi esegue il lavoro. Poiché un impiegato del servizio di assistenza  può lavorare su più di una riparazione, le tabelle Repair_Order e Service_Staff devono avere almeno una relazione M:1 (molti ad uno). 
Ma, hanno anche una relazione M:M? Probabilmente sì. 
Quindi vediamo di identificarla. (Possiamo sempre provvedere a definire "regole di gestione" che impediscano la relazione. Ma se la progettazione del database e delle sue relazioni viene fatta erroneamente potremmo incontrare successivamente molti problemi. )  Quindi aggiungiamo una tabella di relazione. 

 

Ora abbiamo una relazione M:M (molti a molti) tra le tabelle Repair_Orders e Service_Staff, poiché un ordine di lavoro può essere eseguito da più persone ed ogni persona può lavorare a diversi ordini. C'è anche una relazione 1:M (uno a molti) tra le tabelle Repair_Orders e Tasks, poiché una riparazione potrebbe consistere in uno o più compiti, ma una attività si applica precisamente ad un ordine. 
C'è anche, una relazione 1:M tra le tabelle Service_Staff e Tasks,   un impiegato svolge molti compiti, ma un compito è svolto solamente da un impiegato.
 
Che tipo di relazione intercorre tra le tabelle Customers e Repair_Order? È di tipo  1:M? 
Basta
solo aggiungere la chiave primaria della tabella Customers  alla tabella Repair_Order, come mostrato nella figura seguente: 

 

A proposito, quel campo di collegamento é  tecnicamente chiamato "chiave straniera". [5] Una chiave dicesi " straniera" se essa è la chiave primaria in un'altra tabella. I sistemi relazionali supportano le relazioni 1:M tramite l'uso di questa tecnica. 

Se decidete che c'è una relazione M:M tra le tabelle Repair_Order e Customers (non mi sembra probabile, ma forse),  avrete bisogno di una nuova tabella:

 


 
Attenzione!

La frase "genitore-figlio" è qualche volta usata per descrivere una relazione 1:M. In dB2K,  frequentemente costruiamo applicazioni dove la relazione 1:M è espressa come un collegamento tra genitore-figlio. Ma, in dB2K in un collegamento genitore-figlio, entrambe le tabelle coinvolte possono essere 'il genitore ' e ciò in funzione delle vostre necessità applicative. Per questa ragione, consiglio di evitare il termine genitore-figlio quando si parla di progettazione di database all'interno della nostra comunità. Fuori di questa comunità, usate cautela quando sentite che il termine 'genitore-figlio'  potrebbe essere usato in riferimento alla progettazione di database! 

Esempio: Tabella "Time History" 

La maggior parte dei database descrivono i fatti correnti di un sistema. Registrano la paga corrente degli impiegati,  gli ordini correnti. 

Molti database hanno anche tabelle "Time History". Queste tabelle registrano fatti accaduti in un preciso momento. Dovete essere accurati sull'interazione tra le tabelle correnti e quelle "Time History". Ecco un esempio, basato su un sistema di vendite: 
 Progettazione Scarsa  Progettazione  Buona
Clienti          // Nome della tabella
Cod_Clien      // Chiave Primaria IndirSpediz 
(più altri campi relativi al cliente.)

OrdiniHistory // Nome  della tabella Cod_Ord     // Chiave Primaria 
Cod_Clien      // Chiave straniera dalla tabella Clienti  
(più altri campi relativi all'ordine.)

(Più altre tabelle) 

Clienti    // Nome della Tabella 
Cod_Clien   // Chiave Primaria 
IndirSpediz 
(Più altri campi relativi al cliente.)

OrdiniHistory // Nome Tabella 
Cod_Ord      // Chiave Primaria Cod_Clien    // Chiave straniera dalla tabella Clienti 
IndirSpediz
(Più altri campi relativi all'ordine.)

(Più altre tabelle) 

In quella che è stata indicata come "progettazione buona" la tabella OrdiniHistory ha più campi. 

Perché le tabelle Clienti e OrdiniHistory , hanno entrambe il campo IndirSpediz ?

È corretto?
 

Il campo IndirSpediz  é già nella tabella Clienti  ed esso è uno degli attributi del cliente, No? 

Bene non realmente, ed ecco il trucco delle tabelle "time history". Il campo IndirSpediz  nella tabella clienti è l'indirizzo corrente. Il campo IndirSpediz  nella tabella OrdiniHistory è l'indirizzo "storico" copiato dalla tabella cliente al momento dell'ordine. Ecco una possibile situazione per capire l'importanza dell'affermazione precedente:

Nella progettazione "buona" ai record corrisponde la vera spedizione. Nella progettazione "scarsa" l'indirizzo del cliente è cambiato dopo la spedizione e  dai vostri record modificati risulta che gli ordini sono stati   inviati al nuovo indirizzo quando realmente la merce è stata inviata al vecchio indirizzo. 
Nelle progettazione "scarsa" il progettista ha pensato erroneamente che IndirSpediz fosse un attributo del cliente. Ma possiamo vedere che in effetti è  un attributo dell'ordine. 
Se pensate al campo IndirSpediz come un attributo dell'etichetta che dovete mettere nella scatola della spedizione risulterà un po' più chiaro. Le "regole di gestione"  funzionano, anche se dovete essere attenti quando le applicate, specialmente con le tabelle "Time History". 

 Esempio: Convalidazione

Torniamo molto indietro al primo esempio.

Come possiamo essere certi di avere dati di alta qualità e consistenza? 

Una tecnica a tal scopo consiste nell'usare una tabella di convalidazione. Per esempio, come possiamo essere sicuri che soltanto i "titoli" consentiti siano immessi nel campo employees.title? 

Potreste realizzare le vostre schede di immissione dati inserendo un controllo di tipo ComboBox, così  da permettere all'utente di selezionare solamente i titoli consentiti.  I dati (cioè i titoli)  che dovranno essere visualizzati nel controllo di tipo ComboBox possono fare riferimento ad una tabella di convalidazione  come questa:

Le tabelle di convalidazione di questo tipo sono simili alle tabelle dei nomi, ma  essendo tabelle cosi piccole e semplificate,  non sono vere tabelle dei nomi. 
Nell'esempio della tabella Employee_Title_Validation mostrata su, notate che "Title"  non è un vero nome. Non c'è nessuna persona, luogo o cosa che siano un titolo. La tabella  Employee_Title_Validation è solo un elenco di aggettivi validi che possono essere applicati al campo di employees.title. 

 La Regola della Convalidazione: 

Le tabelle di Convalidazione possono essere utili per garantire la consistenza dei dati. Le tabelle di convalidazione  dovrebbero avere una sola  colonna che rappresenta l'elenco dei valori validi. La chiave primaria della tabella di convalidazione è quella sola  colonna.

Quando una Tabella di Convalidazione diviene una Tabella dei Nomi 

Per favore notate che se avete necessità di memorizzare altre informazione rispetto a quelle relative alla sola convalidazione avrete una tabella dei nomi e non una tabella di convalidazione. Per esempio, la vostra tabella Employee_Title_Validation potrebbe ampliarsi per includere informazioni sul salario. Così avete una nuova tabella dei nomi chiamata jobs:
 

 

dovete modificare la tabella employees  come mostrato:

Un commento sul campo Title(Titolo): In funzione delle regole "organizzative" dell'azienda a cui state progettando il sistema informativo, è probabile che Title sia un aggettivo relativo al lavoro (job) o un aggettivo dell'impiegato. Se è un aggettivo del lavoro, allora il mio esempio è scorretto ed il campo Title dovrebbe essere nella tabella jobs. In questo esempio ho stabilito che Title sia un aggettivo dell'impiegato e perciò  mostro il titolo come una colonna della tabella employee. Per esempio osservate gli impiegati 1 e 3 in quanto il titolo dell'impiegato potrebbe non corrispondere al lavoro indicato dal titolo. L'ubicazione corretta per le colonne dipende frequentemente dalle regole di gestione (od organizzazione). 

Pensate ad una società per la quale  avete lavorato. Quali erano le loro regole riguardo i titoli? 
Quale progettazione avete usato per implementare quelle regole?
 
Uno dei vantaggi per la progettazione che ho qui mostrato si rifà alla mia personale esperienza presso  alcune compagnie degli Stati Uniti. Questa progettazione è più flessibile rispetto a quella che richiede che un impiegato riporti il titolo del loro lavoro. Potete sempre fare una progettazione flessibile più rigida tramite le regole di gestione. Progettazioni inflessibili sono comunque semplicemente, inflessibili. Le regole di gestione sono più facili da cambiare rispetto alla progettazione del database. I sistemi tendono ad essere in servizio per molto tempo. È probabile che la condizioni di "gestione" cambino durante l'esercizio stesso del sistema informativo che avete progettato. Quando possibile, progettate i vostri database per essere flessibili e rafforzare la vostra rigidità con regole di gestione. 

Esempio Contrario: Codifica 

Alcune  persone asseriscono che l'esempio di convalidazione precedente è sbagliato. Loro dicono che per una normalizzazione corretta valori simili a Title non dovrebbero essere memorizzati direttamente nella tabella employee. Essi  affermano che Title  dovrebbe essere memorizzato in una tabella collegata simile alla seguente:

 

con la tabella  employees come mostrato: 

Ma, questo è un caso di codifica non di normalizzazione. Come potete dire? Notate che non ci sono più informazioni qui che nell'esempio di convalidazione.  La Codifica  può ridurre la dimensione di un database, ma ha lo svantaggio di richiedere un collegamento ogni volta che voi desiderate visualizzare un leggibile titolo umano. In più casi si raccomanda l'uso di tabelle di convalidazione rispetto la codifica. 

Sommario

Riassumendo, una buona progettazione di database migliorerà le prestazioni  del vostro sistema facendo si che ogni operazione di I/O sia più produttiva e riducendo lo spazio rovinato. Rende anche più facile le operazioni di "query" nel database.  Anche se qui non abbiamo mostrato esempi una buona progettazione può ridurre l'ammontare di dati duplicati e dati potenzialmente contraddittori. Le regole per la progettazione di database sono: 

La Regola dei Nomi: 

La maggior parte delle tabelle contengono fatti sui nomi (persone, luoghi, o cose). Ogni riga dovrebbe contenere informazioni precise circa una di queste persone, luoghi, o cose. 

La Regola delle Relazioni: 

Entrambe le tabelle contengono fatti su nomi o fatti su relazioni tra nomi (Chi possiede un'auto? in quale reparto lavora? Quale prodotto fu inviato a quale cliente?) 

La Regola della Chiave Primaria:

Tutte le tabelle hanno chiavi primarie. Una chiave primaria è la colonna(e) che definisce una riga in modo univoco. La chiave primaria per le tabelle dei nomi, è la colonna(e) che distingue unicamente quel nome da ogni altro possibile in quella tabella. [2] 

Alcune tabelle hanno una naturale chiave primaria. La tabella "componenti" probabilmente usa il campo "compno" come la sua chiave primaria. Alcune tabelle non hanno una naturale chiave primaria, esse hanno bisogno di una chiave primaria artificiale. Ogni tabella deve avere una chiave primaria - inventatene una se non esiste in modo naturale. Questo non è così strano come sembra. I sistemi manuali lo fanno tutte le volte. Numero di impiegato, numero di serie e numero di targa sono tutti  esempi di chiavi primarie inventate. Voi potete usare la colonna di tipo "autoincremento" per questo scopo. Le buone chiavi primarie non cambiano col tempo e sono uniche. Per le persone voi dovreste inventare una chiave primaria. [3] 

La Regola degli Aggettivi: 

A parte la chiave primaria, pensate ad ogni colonna della tabella come un aggettivo. Contiene informazioni descrittive, fatti o attributi del nome rappresentate dalla riga. Ogni colonna in quella riga dovrebbe aderire a questa regola. Una colonna deve contenere costantemente lo stesso attributo da riga a riga. (Se quel attributo non si applica, la colonna è nulla o spazio vuoto.

 La Regola della Convalidazione: 

Le tabelle di Convalidazione possono essere utili per garantire la consistenza dei dati. Le tabelle di convalidazione  dovrebbero avere una sola  colonna che rappresenta l'elenco dei valori validi. La chiave primaria della tabella di convalidazione è quella sola  colonna.

La Frase Prova: 

Scrivete una frase che descriva ogni riga nella tabella. La frase risultante dovrebbe essere semplice, come “Ogni riga è un impiegato nella nostra società.” 

Una frase complessa, come: 

Se il valore contenuto nel campo "tipo"  è il carattere 'I', la riga fa riferimento ad  un impiegato, se il valore è 'D' si tratta di un "dipendente" dell'impiegato(moglie, figlio,ecc),  è un cattivo segnale. Sicuramente avete  bisogno di ri-progettare le vostre tabelle. 

La frase si applica ad ogni colonna in ogni possibile riga? 

Deve
!!! 

Una frase come:

se il campo  "lunghezza cavo" contiene il valore falso, allora nel campo "lunghezza" ci sarà la lunghezza del totale del cavo, se invece "lunghezza cavo"  è vero, allora il campo "lunghezza"  conterrà la lunghezza di solo questo intervallo. [6], 

è guaio notevole. 

La vostra frase dovrebbe essere semplice, senza “se", "e", " o", "ma".


La GIF animata  usata all'inizio di questo articolo è stata realizzata da  Ronnie MacGregor.