Väldigt få databasförfattare nämner globaliseringens och lokaliseringens utmaningar på något meningsfullt sätt. Det finns en liknande brist på framförhållning från databasarkitekter. Faktum är att många författare och designers ofta är väldigt "självcentrerade":de skapar (eller skriver om) datamodeller som bara hanterar sina lokala tidszoner, adresser, etc.
Ett självcentrerat tillvägagångssätt har ett stort problem:den resulterande modellen kommer endast att stödja lokal data. I dagens internet-drivna värld nås applikationer ofta oväntat av användare över hela världen. Vi måste stödja så mycket flexibilitet som möjligt för denna internationella publik. Därför måste vi utforma våra datamodeller med ett globaliserat tillvägagångssätt.
Jag har turen att arbeta i en mycket multinationell och flerspråkig miljö, så jag har lärt mig hur globaliseringsfrågor kan hanteras i projektets start. Med det i åtanke har jag sammanställt sju viktiga punkter för att skapa en datamodell som kommer att stödja internationell användning.
1. Nummerformatering
Det finns två saker att tänka på när du tittar på talformatering:utdata som användarna ser (dvs formatet) och den underliggande datatypen.
Du ska inte behöva oroa dig för hur siffror kommer att visas i din datamodell – databassystemet kommer att hantera lagringen av decimaltal och din applikation bör anpassa sig till hur decimaltal visas (“.” eller “,” som decimaltal punkt, till exempel). På samma sätt ska du inte behöva oroa dig för vilken tusentalsavgränsare (som en punkt eller komma) som din datamodell kommer att använda.
Det här är poängen: Välj dina datatyper korrekt vid modellering. Din applikation bör hantera utdataformateringen.
Till exempel, i denna enkla modell av en väderstationstillämpning, lagras vädermätningarna (temperatur, luftfuktighet, nederbörd) som flyttal. Men prisinformationen är i decimal, liknande GPS-koordinaterna för varje väderstation.
2. Valutor och växelkurser
Om du lagrar information relaterad till valutor måste du lagra korrekt antal decimaler för varje valuta. De flesta valutor har två decimaler, men vissa har ingen (d.v.s. den chilenska peson), en (den madagaskiska ariaryen), tre (den tunisiska dinaren) eller till och med fyra decimaler (Chiles Unidad de Fomento, en beräkningsenhet som används för att uttrycka en prisintervall.)
Så se till att dina "belopp"-fält i datamodellen stöder mer än två decimaler – medan fyra decimaler är mycket sällsynt, händer det. Tre decimaler är vanligare. Till exempel kräver dinarer i sex olika länder (Bahrain, Irak, Jordanien, Kuwait, Libyen, Tunisien) och rial i ett land (Oman) tre decimaler.
Punkt nummer 1: Välj din datatyp korrekt vid modellering.
En annan viktig punkt relaterad till valutor är växelkurser. Dessa kräver ännu mer precision. Många system ger bara 4-6 signifikanta siffror i växelkurser; ibland finns det en skalningsfaktor mellan valutor som har väldigt olika värden. Men fyra eller sex signifikanta siffror betyder inte nödvändigtvis att det kommer att finnas sex decimaler. Kontrollera växelkursen mellan indonesiska rupiah och euro:0,0000668755. Det är många decimaler att lagra i ditt växelkursfält.
Punkt nummer 2: Din modell kan behöva hantera en hög precision – många decimaler – när det gäller växelkurser.
Nedan har vi skapat ett exempel på en webbutik med priser. Vi har också lagt till en enkel tabell (markerad i aqua) som lagrar valutakurser, inklusive historiska växelkurser. Varje rad i exchange_rate tabellen är länkad till en valuta (currency_id , vilket är ISO 4217-valutakoden). Vi tillåter att en växelkurs lagras för varje valuta en viss dag (rate_date ), och har en aktiv växelkurs för varje valuta.
Självklart behöver du lite ytterligare information för att använda denna pristabell. Till exempel, mot vilken basvaluta definieras dessa växelkurser? Euro eller US-dollar kan vara typiska, men din ansökan skulle behöva exakt information här.
Alternativt kan en mer komplex modell lagra valutapar, mellankurs (eller bankkurs) och "köp" och "sälj"-kurser mellan dessa valutapar.
Punkt nummer 3: Din modell måste ha tillräckligt med information så att applikationen kan använda data på rätt sätt.
3. Telefonnummer
Jag har ofta sett system som bara stöder ett nordamerikanskt tiosiffrigt telefonnummer med ett tresiffrigt riktnummer, tresiffrigt växel och fyrsiffrigt abonnentnummer (dvs. 012-345-6789). Denna partiskhet är förståelig till viss del; människor skapar system som stödjer sina lokala användare. Datamodellering bör dock inte ignorera möjligheten att globala användare kan komma åt ditt system. (Obs:Den tiosiffriga längden kan också användas för andra nummer, som franska mobiltelefoner, men formatet är annorlunda (dvs. 06 12 34 56 78).)
Låt oss ta detta som ett exempel:Anta att jag bor strax utanför den franska gränsen, men jag arbetar i Frankrike. Därför, även om jag kan behöva använda franska applikationer och tjänsteleverantörer, är mitt mobiltelefonnummer inte ett franskt nummer. System som kräver ett tiosiffrigt mobilnummer som börjar med 06 eller 07 kommer inte att fungera för mig. För att få franska järnvägsbiljetter, köpa biljetter till en konsert i Frankrike (etc, etc), skulle jag bli tvungen att skaffa ett franskt telefonnummer. Besvärligt, minst sagt.
Det här är poängen: När telefonnummerbegränsningar är inbyggda i datamodellen kommer modifieringar av datamodeller att krävas för att stödja icke-lokala användare. Idealt sett bör tillräcklig flexibilitet införlivas i modellen för att hantera alla eventualiteter.
En mer logisk datamodell skulle stödja telefonnummer av olika längd (upp till 16 siffror i vissa områden) och icke-numeriska tecken (som den universella "+"-symbolen för ett internationellt telefonnummer). Visst kan vissa applikationer utföra mer validering genom att implementera "lokala regler" som lokala utvecklare skulle vara mer bekanta med. Andra appar kan använda lokala telefonnummer för att komma åt andra datakällor, som att verifiera eller hämta en adress baserad på ett telefonnummer.
Datamodellen bör stödja flexibilitet vid lagring av information. Applikationen eller dess användargränssnitt kan vara mer restriktiv eller utföra ytterligare validering.
4. Adresser
Som en amerikan som bor utomlands hittar jag ofta datamodellexempel och mönster som är för Amero-centriska. Till exempel kanske en icke-amerikan inte förstår vad en Zip+4 är och skulle därför inte ha någon förståelse för varför en författare säger att denna domän måste ha en INTE NULL-egenskap.
Denna Amero-centrerade syn finns till och med i böcker. Ta till exempel den ganska omfattande boken ”Data Model Patterns. Conventions of Thought” av David C. Hay. Mr. Hays mycket komplicerade förklaring av adresser, platser, geografiska platser, markskiften och geografiska strukturelement inkluderade exempel från Kanada, men trots detta är det inte säkert att alla förstår den här informationen.
Mr. Hays mönster säger att adressattributen inkluderar:
Adressens "text" plus åtminstone "stad", "stat" och "postnummer".
Nu är Mr Hay snabb med att förklara i en fotnot att:
Modellens sammanhang avgör om detta attribut är "postnummer" eller "postnummer". Om kundorganisationen kommer att verka helt inom USA under överskådlig framtid, kan antagandet om ett niosiffrigt, tvådelat numeriskt "postnummer" göras. Om inte, måste "postnummer" bli "postnummer" och inga formateringsantaganden är möjliga.
Han misslyckas dock med att nämna att "stat" kan vara en stat i USA, en provins i Kanada eller ett nullbart attribut för nästan vilket annat land som helst, eftersom "stater" i länder sällan existerar utanför USA, Kanada (där de kallas provinser men fungerar på liknande sätt) och Australien. Visst, andra länder har provinser och regioner, men dessa används sällan som en del av en adress.
För att illustrera hur allvarligt detta adressproblem kan vara gjorde jag en datamodell för både amerikanska och icke-amerikanska adresser. (Obs:Detta är inte hela modellen.)
PrimaryPhone av US_Customer Tabellen lagrar endast telefonnummer med tio eller färre tecken. Customer tabellens PrimaryPhone attribut tillåter ett telefonnummer med 15 siffror plus "+", vilket är det maximala som anges av E.164.
TimeOffset attribut i US_Customer Tabellen tillåter endast fyra tidszoner:Eastern Time, Central Time, Mountain Time och Pacific Time (lagrade i datamodellen som:0 =Eastern, 1 =Central, 2 =Mountain, 3 =Pacific). För övrigt täcker detta inte ens alla tidszoner i USA och dess territorier. Däremot Timezone attribut i Customer Tabellen lagrar den internationella koden för kundens tidszon oavsett var den är.
Låt oss sedan titta på postnumret. USA kräver ett femsiffrigt postnummer (Zip av US_Address tabell) plus den valfria ZIP+4 (Zip4 av US_Address tabell). Address tabellen har en mer flexibel PostCode fält. Bortsett från längden finns det inga begränsningar för informationen som kan lagras i PostCode; Naturligtvis kan applikationen implementera kontroller av postnummer.
Lägg också märke till att USA och icke-amerikanska design båda har ett fält för regioner inom ett land (State i US_Address tabell och Region i Address tabell), men den amerikanska designen kräver att en statförkortning med två tecken ingår. Observera också att den amerikanska designen inte accepterar internationella adresser, medan den internationella adressversionen gör det (därav ISO-landskoden på två tecken Land för Address tabell).
Det här är poängen: Begränsa inte din datamodell av adresser till en ort; lämna tillräckligt med utrymme för olika stilar.
5. Formatering av datum och tid
Datamodeller bör inte ägna sig åt flera datum- och tidsformat; applikationen hanterar själva visningen. Detta kan göras på olika sätt:
- Månaden-första stilen, vanlig i Nordamerika och på andra håll:mm-dd-åååå
- Den första stilen, som är vanligare i Europa:dd-mm-åååå
- Årets första stil, använd som ISO 8601 datumformat:åååå-mm-dd
Det här är poängen: Detta kan vara repetitivt, men vi säger det igen:välj dina datatyper korrekt när du modellerar. Detta kommer att göra det lättare för applikationskoden att tolka och visa lagrade värden.
En annan post i den här kategorin kan vara lite oväntad:vilken dag veckan börjar på. För vissa är det söndag; för andra är det måndag (och sedan finns det den persiska kalendern, som börjar veckan på lördag).
Tider ska också visas på ett användarvänligt sätt. Kom ihåg att även om din datamodell inte behöver flera tidsformat, kan du lagra användarens tidspreferens , det vill säga 12- eller 24-timmarsformatet.
Detta leder oss till tidszoner.
6. Tidszoner
Det är inte ovanligt att hitta appar som bara tillåter användarna ett fåtal tidszonval:Eastern Time, Central Time, Mountain Time och Pacific Time. När jag ser det vet jag att jag har att göra med en Amero-centrerad applikationsdesigner. Vissa designers tillåter att en tidszon uttrycks som en offset från (vanligtvis) GMT eller UTC. Men många gör misstaget att endast tillåta helnummerförskjutningar, utan att inse att vissa länder (Indien, Iran, Pakistan, Afghanistan och andra) inte är en heltalsförskjutning. De är bråkdels olika:Indiens standardtid är UTC+5:30. Vissa platser har till och med en mindre delförskjutning, som Nepal Standard Time – det är UTC+05:45.
För en tid sedan skrev jag om en modell för en onlineundersökningsdatabas. Här har jag lagt till en tidszon i användartabellen så att vi kan visa datum/tider i användarnas lokala tider.
För mer information om datum, tider, tidszoner, kan du hänvisa till ISO 8601 standardrepresentation av datum och tider eller denna Wikipedia-artikel.
Det här är poängen: Lär dig att tänka globalt, inte bara lokalt.
7. Flerspråkig support
Det finns många tillfällen då din applikation kan behöva tillhandahålla flerspråkig support. Ur ett datamodellperspektiv kan du behöva ha information lagrad på flera språk; det mesta av den språkliga hanteringen bör dock täckas in i din ansökan. Implementeringen av flerspråkig support ligger utanför ramen för denna artikel, men vi har redan diskuterat det i den här bloggen.
Lokalisering är mycket viktigt och måste hanteras på rätt sätt. Som vi redan har påpekat betyder detta mer än att bara stödja olika språk; Det handlar också om de föredragna formaten för datum, tider, valutor och till och med decimalindikatorer.
Datamodellering? Tänk globalt
När du skapar din datamodell, överväg den potentiella internationella användningen av din applikation och dess databas. Tänk globalt under designfasen så slipper du några problem senare – ett telefonnummerfält som bara accepterar 3-siffror + 3-siffror + 4-siffror fungerar bra i USA, men inte så bra i Kina eller Indien.
Är dina databaser beredda att bli globala? Ditt mål bör vara att möjliggöra flexibilitet utan att skapa överväldigande komplexitet.