Progettazione di Database
&
Normalizzazione
di Mike
Tossy
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:
Che cosa succede se un impiegato ha più bambini di quanto voi avete previsto? Quanto è abbastanza Cinque? Dieci? Venti? Cento?
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. )
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.
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 |
|
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:
Il 3 Maggio, il cliente 127 effettua un ordine.
Il 4 Maggio l'ufficio spedizioni evade l'ordine.
Il 5 maggio, il cliente 127 vi chiama per darvi il loro nuovo indirizzo, trascura di dirvi che hanno un ordine in transito ed il vostro personale non ne tiene conto.
Il 7 maggio, il cliente chiama lamentandosi che la merce ordinata non è arrivata.
Se state usando la progettazione "scarsa". Dove avete inviato realmente l'ordine? Dove il vostro database mostra a quale indirizzo avete inviato la merce? Sono gli stessi?
Se state usando la progettazione "buona". Dove avete inviato la merce? Dove i vostri record mostrano a chi avete inviato la merce?
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.
Quando una Tabella di Convalidazione diviene una Tabella dei NomiLa 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.
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".