Pochissimi autori di database menzionano le sfide della globalizzazione e della localizzazione in modo significativo. C'è una simile mancanza di previsione da parte degli architetti di database. Il fatto è che molti autori e designer sono spesso molto "egocentrici":creano (o scrivono) modelli di dati che gestiscono correttamente solo i fusi orari locali, gli indirizzi, ecc.
Un approccio egocentrico ha un grosso problema:il modello risultante supporterà solo dati locali. Nel mondo di oggi, alimentato da Internet, gli utenti di tutto il mondo accedono spesso alle applicazioni in modo imprevisto. Dobbiamo sostenere quanta più flessibilità possibile per questo pubblico internazionale. Pertanto, abbiamo bisogno di progettare i nostri modelli di dati con un approccio globalizzato.
Ho la fortuna di lavorare in un ambiente molto multinazionale e multilingue, quindi ho imparato come gestire i problemi della globalizzazione all'inizio del progetto. Con questo in mente, ho messo insieme sette punti importanti per creare un modello di dati che supporterà l'uso internazionale.
1. Formattazione dei numeri
Ci sono due cose da considerare quando si esamina la formattazione dei numeri:l'output visualizzato dagli utenti (ovvero il formato) e il tipo di dati sottostante.
Non dovresti preoccuparti di come i numeri verranno visualizzati nel tuo modello di dati:il sistema di database gestirà l'archiviazione dei numeri decimali e la tua applicazione dovrebbe adattarsi a come vengono visualizzati i numeri decimali ("." o "", come decimale punto, per esempio). Allo stesso modo, non dovresti preoccuparti di quale separatore di migliaia (come un punto o una virgola) utilizzerà il tuo modello di dati.
Ecco il punto: Scegli correttamente i tipi di dati durante la modellazione. La tua applicazione dovrebbe gestire la formattazione dell'output.
Ad esempio, in questo semplice modello di applicazione di una stazione meteorologica, le misurazioni meteorologiche (temperatura, umidità, precipitazioni) vengono memorizzate come numeri in virgola mobile. Ma le informazioni sul prezzo sono decimali, simili alle coordinate GPS di ogni stazione meteorologica.
2. Valute e tassi di cambio
Se stai memorizzando informazioni relative alle valute, devi memorizzare il numero corretto di cifre decimali per ciascuna valuta. La maggior parte delle valute ha due cifre decimali, ma alcune non ne hanno (cioè il peso cileno), una (l'ariary malgascio), tre (il dinaro tunisino) o addirittura quattro cifre decimali (l'Unidad de Fomento del Cile, un'unità di conto usata per esprimere un gamma di valori di prezzo.)
Quindi, assicurati che i tuoi campi "importo" nel modello di dati supportino più di due cifre decimali - mentre quattro cifre decimali sono molto rare, succede. Tre cifre decimali è più comune. Ad esempio, i dinari in sei paesi diversi (Bahrain, Iraq, Giordania, Kuwait, Libia, Tunisia) e il rial in un paese (Oman) richiedono tre cifre decimali.
Punto numero 1: Scegli correttamente il tipo di dati durante la modellazione.
Un altro punto importante relativo alle valute sono i tassi di cambio. Questi richiedono ancora più precisione. Molti sistemi forniscono solo 4-6 cifre significative nei tassi di cambio; a volte c'è un fattore di scala tra valute che hanno valori molto diversi. Tuttavia, quattro o sei cifre significative non significano necessariamente che ci saranno sei cifre decimali. Controlla il tasso di cambio tra Rupia indonesiana ed Euro:0.0000668755. Ci sono molte cifre decimali da memorizzare nel campo del tasso di cambio.
Punto numero 2: Il tuo modello potrebbe dover gestire un elevato livello di precisione (molte cifre decimali) quando si tratta di tassi di cambio.
Di seguito abbiamo creato un esempio di negozio online con prezzi. Abbiamo anche aggiunto una semplice tabella (evidenziata in acqua) che memorizza i tassi di cambio delle valute, inclusi i tassi di cambio storici. Ogni riga nel exchange_rate la tabella è collegata a una valuta (currency_id , che è il codice valuta ISO 4217). Consentiamo di memorizzare un tasso di cambio per ciascuna valuta in un determinato giorno (rate_date ), e hanno un tasso di cambio attivo per ciascuna valuta.
Ovviamente, avrai bisogno di alcune informazioni aggiuntive per utilizzare questo tariffario. Ad esempio, contro quale valuta di base sono definiti questi tassi di cambio? Euro o dollari USA potrebbero essere tipici, ma la tua domanda avrebbe bisogno di informazioni esatte qui.
In alternativa, un modello più complesso potrebbe memorizzare coppie di valute, il tasso medio (o tasso bancario) e i tassi di "acquisto" e "vendita" tra tali coppie di valute.
Punto numero 3: Il tuo modello deve disporre di informazioni sufficienti affinché l'applicazione possa utilizzare correttamente i dati.
3. Numeri di telefono
Ho visto spesso sistemi che supportano solo un numero di telefono a dieci cifre del Nord America con un prefisso a tre cifre, uno scambio a tre cifre e un numero di abbonato a quattro cifre (es. 012-345-6789). Questo pregiudizio è comprensibile in una certa misura; le persone creano sistemi che supportano i loro utenti locali. Tuttavia, la modellazione dei dati non dovrebbe ignorare la possibilità che utenti globali possano accedere al sistema. (Nota:la lunghezza di dieci cifre può essere utilizzata anche per altri numeri, come i telefoni cellulari francesi, ma il formato è diverso (es. 06 12 34 56 78).)
Prendiamo questo come esempio:supponiamo che io viva appena fuori dal confine francese, ma lavoro in Francia. Pertanto, anche se potrebbe essere necessario utilizzare applicazioni e fornitori di servizi francesi, il mio numero di cellulare non è un numero francese. I sistemi che richiedono un numero di cellulare a dieci cifre che inizia con 06 o 07 non funzioneranno per me. Per ottenere i biglietti ferroviari francesi, acquistare i biglietti per un concerto in Francia (ecc, ecc), sarei costretto a ottenere un numero di telefono francese. Fastidioso, per non dire altro.
Ecco il punto: Quando i vincoli del numero di telefono sono integrati nel modello dati, le modifiche del modello dati saranno necessarie per supportare utenti non locali. Idealmente, nel modello dovrebbe essere incorporata una flessibilità sufficiente per gestire tutte le eventualità.
Un modello di dati più logico supporterebbe numeri di telefono di diverse lunghezze (fino a 16 cifre in alcune aree) e caratteri non numerici (come il simbolo "+" universale per un numero di telefono internazionale). Certamente, alcune applicazioni possono eseguire una maggiore convalida implementando "regole locali" con cui gli sviluppatori locali sarebbero più familiari. Altre app potrebbero utilizzare numeri di telefono locali per accedere ad altre origini dati, come la verifica o il recupero di un indirizzo in base a un numero di telefono.
Il modello di dati dovrebbe supportare la flessibilità nella memorizzazione delle informazioni. L'applicazione o la relativa interfaccia utente può essere più restrittiva o eseguire una convalida aggiuntiva.
4. Indirizzi
Come americano che vive all'estero, trovo spesso esempi e modelli di modelli di dati che sono troppo amero-centrici. Ad esempio, un non americano potrebbe non capire cosa sia un Zip+4 è e quindi non avrebbe alcuna comprensione del motivo per cui un autore afferma che questo dominio deve avere una caratteristica NOT NULL.
Questa visione amerocentrica è presente anche nei libri. Ad esempio, prendi il libro piuttosto ampio "Modelli di modelli di dati. Convenzioni di pensiero” di David C. Hay. La spiegazione molto complessa del signor Hay di indirizzi, siti, posizioni geografiche, appezzamenti di terreno ed elementi della struttura geografica includeva esempi dal Canada, ma anche così, queste informazioni potrebbero non essere facilmente comprese da tutti.
I modelli di Mr. Hay dicono che gli attributi dell'indirizzo includeranno:
Il "testo" dell'indirizzo, più almeno "città", "stato" e "codice postale".
Ora, il signor Hay si affretta a spiegare in una nota a piè di pagina che:
Il contesto del modello determinerà se questo attributo è "codice postale" o "codice postale". Se l'organizzazione cliente opererà interamente negli Stati Uniti nel prossimo futuro, è possibile ipotizzare un "codice postale" numerico a nove cifre e due parti. In caso contrario, il "codice postale" deve diventare "codice postale" e non sono possibili ipotesi di formattazione.
Tuttavia, non menziona che "stato" potrebbe essere uno stato negli Stati Uniti, una provincia in Canada o un attributo nullable per quasi tutti gli altri paesi, poiché gli "stati" all'interno di paesi raramente esistono al di fuori degli Stati Uniti, Canada (dove sono chiamate province ma funzionano in modo simile) e Australia. Certamente, altri paesi hanno province e regioni, ma queste sono usate raramente come parte di un indirizzo.
Per illustrare la gravità di questo problema di indirizzi, ho creato un modello di dati per indirizzi americani e non americani. (Nota:questo non è il modello completo.)
Il PrimaryPhone del US_Customer la tabella memorizza solo i numeri di telefono con dieci caratteri o meno. Il design internazionale del Customer PrimaryPhone della tabella attributo consente un numero di telefono di 15 cifre più "+", che è il massimo specificato da E.164.
Il TimeOffset attributo nel US_Customer la tabella consente solo quattro fusi orari:ora orientale, ora centrale, ora di montagna e ora del Pacifico (memorizzata nel modello di dati come:0 =orientale, 1 =centrale, 2 =montagna, 3 =Pacifico). Per inciso, questo non copre nemmeno tutti i fusi orari negli Stati Uniti e nei suoi territori. Al contrario, il Timezone attributo nel Customer table memorizza il prefisso internazionale per il fuso orario del cliente indipendentemente da dove si trovi.
Quindi, diamo un'occhiata al codice postale/cap. Gli Stati Uniti richiedono un codice postale di 5 cifre (Zip del US_Address tabella) più lo ZIP+4 opzionale (Zip4 del US_Address tavolo). Il Address la tabella ha un PostCode più flessibile campo. A parte la lunghezza, non vi è alcun vincolo sulle informazioni che possono essere memorizzate in PostCode; ovviamente l'applicazione potrebbe implementare dei controlli sui codici postali.
Si noti inoltre che i modelli statunitensi e non statunitensi hanno entrambi un campo per le regioni all'interno di un paese (State nel US_Address tabella e Region nel Address tabella), ma il design statunitense richiede che sia inclusa un'abbreviazione di stato di 2 caratteri. Inoltre, si noti che il design degli Stati Uniti non accetta indirizzi internazionali, mentre la versione dell'indirizzo internazionale sì (da cui il codice paese ISO a 2 caratteri Paese dell'Address tabella).
Ecco il punto: Non limitare il tuo modello di dati di indirizzi a una località; lascia abbastanza spazio per stili diversi.
5. Formattazione di data e ora
I modelli di dati non dovrebbero riguardare più formati di data e ora; l'applicazione gestisce la visualizzazione effettiva. Questo può essere fatto in vari modi:
- Lo stile del primo mese, comune in Nord America e altrove:mm-gg-aaaa
- Lo stile del primo giorno, più comune in Europa:gg-mm-aaaa
- Lo stile del primo anno, utilizzato come formato della data ISO 8601:aaaa-mm-gg
Ecco il punto: Potrebbe essere ripetitivo, ma lo ripeto:scegli correttamente i tipi di dati durante la modellazione. Ciò renderà più semplice per il codice dell'applicazione interpretare e visualizzare i valori memorizzati.
Un altro elemento in questa categoria potrebbe essere un po' inaspettato:in che giorno inizia la settimana. Per alcuni, questa è domenica; per altri è lunedì (e poi c'è il calendario persiano, che inizia la settimana di sabato).
Anche i tempi devono essere visualizzati in modo intuitivo. Ricorda che, sebbene il tuo modello di dati non richieda più formati temporali, potresti memorizzare la preferenza temporale dell'utente , ovvero il formato 12 o 24 ore.
Questo ci porta ai fusi orari.
6. Fusi orari
Non è raro trovare app che consentono agli utenti solo alcune scelte di fuso orario:ora orientale, ora centrale, ora di montagna e ora del Pacifico. Quando lo vedo, so che ho a che fare con un designer di applicazioni incentrato su Amero. Alcuni progettisti consentono di esprimere un fuso orario come offset da (solitamente) GMT o UTC. Tuttavia, molti commettono l'errore di consentire solo offset di numeri interi, non rendendosi conto che alcuni paesi (India, Iran, Pakistan, Afghanistan e altri) non sono un offset intero. Sono leggermente diversi:l'ora solare dell'India è UTC+5:30. Alcune località hanno anche uno scostamento frazionario più piccolo, come l'ora solare del Nepal:è UTC+05:45.
Qualche tempo fa ho scritto di un modello per un database di sondaggi online. Qui ho aggiunto un fuso orario alla tabella degli utenti in modo da poter visualizzare date/ora nell'ora locale degli utenti.
Per ulteriori informazioni su date, orari, fusi orari, puoi fare riferimento alla rappresentazione standard ISO 8601 di date e orari o a questo articolo di Wikipedia.
Ecco il punto: Impara a pensare a livello globale, non solo a livello locale.
7. Supporto multilingue
Ci sono molte volte in cui la tua applicazione potrebbe dover fornire supporto multilingue. Dal punto di vista del modello di dati, potrebbe essere necessario disporre di informazioni archiviate in più lingue; tuttavia, la maggior parte della gestione linguistica dovrebbe essere trattata nella domanda. L'implementazione del supporto multilingue va oltre lo scopo di questo articolo, ma ne abbiamo già discusso in questo blog.
La localizzazione è molto importante e deve essere gestita correttamente. Come abbiamo già sottolineato, questo significa più del semplice supporto di lingue diverse; riguarda anche i formati preferiti per date, orari, valute e persino indicatori decimali.
Modellazione dei dati? Pensa globalmente
Durante la creazione del modello di dati, considera il potenziale utilizzo internazionale della tua applicazione e del relativo database. Pensa a livello globale durante la fase di progettazione ed eviterai alcuni problemi in seguito:un campo del numero di telefono che accetta solo 3 cifre + 3 cifre + 4 cifre funziona bene negli Stati Uniti, ma non così bene in Cina o in India.
I tuoi database sono pronti per diventare globali? Il tuo obiettivo dovrebbe essere quello di consentire la flessibilità senza creare una complessità eccessiva.
