Meget få databaseforfattere nævner udfordringerne ved globalisering og lokalisering på nogen meningsfuld måde. Der er en lignende mangel på fremsyn fra databasearkitekter. Faktum er, at mange forfattere og designere ofte er meget 'selvcentrerede':de skaber (eller skriver om) datamodeller, der kun håndterer deres lokale tidszoner, adresser osv. korrekt.
En selvcentreret tilgang har et stort problem:den resulterende model vil kun understøtte lokale data. I dagens internetdrevne verden får applikationer ofte uventet adgang af brugere over hele kloden. Vi er nødt til at støtte så meget fleksibilitet som muligt for dette internationale publikum. Derfor er vi nødt til at designe vores datamodeller med en globaliseret tilgang.
Jeg er så heldig at arbejde i et meget multinationalt og flersproget miljø, så jeg har lært, hvordan globaliseringsproblemer kan håndteres ved projektets start. Med det i tankerne har jeg samlet syv vigtige punkter for at skabe en datamodel, der understøtter international brug.
1. Talformatering
Der er to ting at overveje, når du ser på talformatering:det output, som brugerne ser (dvs. formatet), og den underliggende datatype.
Du skal ikke bekymre dig om, hvordan tal vil blive vist i din datamodel – databasesystemet vil håndtere lagringen af decimaltal, og din applikation skal tilpasse sig, hvordan decimaltal vises (“.” eller “,” som decimaltallet punkt, for eksempel). På samme måde skal du ikke bekymre dig om, hvilken tusindseparator (såsom et punktum eller komma) din datamodel vil bruge.
Her er pointen: Vælg dine datatyper korrekt ved modellering. Din applikation skal håndtere outputformateringen.
For eksempel, i denne simple model af en vejrstationsapplikation gemmes vejrmålingerne (temperatur, fugtighed, nedbør) som flydende kommatal. Men prisoplysningerne er i decimal, svarende til GPS-koordinaterne for hver vejrstation.
2. Valutaer og valutakurser
Hvis du gemmer information relateret til valutaer, skal du gemme det korrekte antal decimaler for hver valuta. De fleste valutaer har to decimaler, men nogle har ingen (dvs. den chilenske peso), en (den madagaskiske ariary), tre (den tunesiske dinar) eller endda fire decimaler (Chiles Unidad de Fomento, en regningsenhed, der bruges til at udtrykke en række af prisværdier.)
Så vær sikker på, at dine "beløb"-felter i datamodellen understøtter mere end to decimaler - mens fire decimaler er meget sjældent, sker det. Tre decimaler er mere almindeligt. For eksempel kræver dinarer i seks forskellige lande (Bahrain, Irak, Jordan, Kuwait, Libyen, Tunesien) og rial i ét land (Oman) tre decimaler.
Punkt nummer 1: Vælg din datatype korrekt ved modellering.
Et andet vigtigt punkt relateret til valutaer er valutakurser. Disse kræver endnu mere præcision. Mange systemer giver kun 4-6 signifikante cifre i valutakurser; nogle gange er der en skaleringsfaktor mellem valutaer, som har vidt forskellige værdier. Fire eller seks signifikante cifre betyder dog ikke nødvendigvis, at der vil være seks decimaler. Tjek vekselkursen mellem indonesiske rupiah og euro:0,0000668755. Det er mange decimaler at gemme i dit valutakursfelt.
Punkt nummer 2: Din model skal muligvis håndtere et højt niveau af præcision – mange decimaler – når det kommer til valutakurser.
Nedenfor har vi lavet et eksempel på en netbutik med priser. Vi har også tilføjet en simpel tabel (fremhævet i aqua), der gemmer valutakurser, inklusive historiske valutakurser. Hver række i exchange_rate tabel er knyttet til en valuta (currency_id , som er ISO 4217 valutakoden). Vi tillader, at der gemmes én vekselkurs for hver valuta på en bestemt dag (rate_date ), og har én aktiv vekselkurs for hver valuta.
Det er klart, at du skal bruge nogle yderligere oplysninger for at bruge denne pristabel. For eksempel, mod hvilken basisvaluta er disse valutakurser defineret? Euro eller amerikanske dollars kan være typiske, men din ansøgning kræver nøjagtige oplysninger her.
Alternativt kunne en mere kompleks model gemme valutapar, mellemkursen (eller bankkursen) og 'køb'- og 'salgs'-kurserne mellem disse valutapar.
Punkt nummer 3: Din model skal have nok information, så applikationen kan bruge dataene korrekt.
3. Telefonnumre
Jeg har ofte set systemer, der kun understøtter et nordamerikansk ti-cifret telefonnummer med et trecifret områdenummer, trecifret centralnummer og firecifret abonnentnummer (dvs. 012-345-6789). Denne skævhed er til en vis grad forståelig; folk skaber systemer, der understøtter deres lokale brugere. Datamodellering bør dog ikke ignorere muligheden for, at globale brugere kan få adgang til dit system. (Bemærk:Den ti-cifrede længde kan også bruges til andre numre, såsom franske mobiltelefoner, men formatet er anderledes (dvs. 06 12 34 56 78).
Lad os tage dette som et eksempel:Antag, at jeg bor lige uden for den franske grænse, men jeg arbejder i Frankrig. Derfor, selvom jeg muligvis skal bruge franske applikationer og tjenesteudbydere, er mit mobiltelefonnummer ikke et fransk nummer. Systemer, der kræver et ti-cifret mobilnummer, der starter med 06 eller 07, vil ikke fungere for mig. For at få franske jernbanebilletter, købe billetter til en koncert i Frankrig (osv, osv.), ville jeg være tvunget til at få et fransk telefonnummer. Besværligt, for at sige det mildt.
Her er pointen: Når begrænsninger for telefonnummer er indbygget i datamodellen, vil datamodelændringer være påkrævet at støtte ikke-lokale brugere. Ideelt set bør der indarbejdes tilstrækkelig fleksibilitet i modellen til at håndtere alle eventualiteter.
En mere logisk datamodel ville understøtte telefonnumre af forskellig længde (op til 16 cifre i nogle områder) og ikke-numeriske tegn (som det universelle "+"-symbol for et internationalt telefonnummer). Bestemt, nogle applikationer kan udføre mere validering ved at implementere "lokale regler", som lokale udviklere ville være mere fortrolige med. Andre apps bruger muligvis lokale telefonnumre til at få adgang til andre datakilder, såsom at bekræfte eller hente en adresse baseret på et telefonnummer.
Datamodellen skal understøtte fleksibilitet i lagring af information. Applikationen eller dens brugergrænseflade kan være mere restriktiv eller udføre yderligere validering.
4. Adresser
Som amerikaner, der bor i udlandet, finder jeg ofte eksempler på datamodeller og mønstre, der er for Amero-centrerede. For eksempel kan en ikke-amerikaner måske ikke forstå, hvad en Zip+4 er og ville derfor ikke have nogen forståelse af, hvorfor en forfatter siger, at dette domæne skal have en IKKE NULL-karakteristik.
Denne Amero-centrerede opfattelse er endda til stede i bøger. Tag for eksempel den ganske omfattende bog “Data Model Patterns. Tankekonventioner” af David C. Hay. Mr. Hays meget komplekse forklaring af adresser, lokaliteter, geografiske placeringer, jordpakker og geografiske strukturelementer inkluderede eksempler fra Canada, men alligevel er denne information måske ikke let at forstå af alle.
Mr. Hays mønstre siger, at adresseattributterne vil omfatte:
Adressens "tekst" plus mindst "by", "stat" og "postnummer".
Nu er hr. Hay hurtig til at forklare i en fodnote, at:
Konteksten for modellen vil afgøre, om denne attribut er "postnummer" eller "postnummer". Hvis klientorganisationen vil operere udelukkende inden for USA i en overskuelig fremtid, kan antagelsen om et ni-cifret, todelt numerisk "postnummer" gøres. Hvis ikke, skal "postnummer" blive til "postnummer", og ingen formateringsantagelser er mulige.
Han undlader dog at nævne, at "stat" kan være en stat i USA, en provins i Canada eller en nullbar egenskab for næsten ethvert andet land, da "stater" i lande sjældent eksisterer uden for USA, Canada (hvor de kaldes provinser, men fungerer på samme måde) og Australien. Bestemt, andre lande har provinser og regioner, men disse bruges sjældent som en del af en adresse.
For at illustrere, hvor alvorligt dette adresseproblem kan være, lavede jeg en datamodel for både amerikanske og ikke-amerikanske adresser. (Bemærk:Dette er ikke den komplette model.)
PrimaryPhone af US_Customer tabel gemmer kun telefonnumre med ti eller færre tegn. Det internationale design af Customer tabellens PrimaryPhone attribut tillader et telefonnummer på 15 cifre plus "+", som er det maksimale angivet af E.164.
TimeOffset attribut i US_Customer tabel tillader kun fire tidszoner:Eastern Time, Central Time, Mountain Time og Pacific Time (lagret i datamodellen som:0 =Eastern, 1 =Central, 2 =Mountain, 3 =Pacific). Dette dækker i øvrigt ikke engang alle tidszonerne i USA og dets territorier. I modsætning hertil er Timezone attribut i Customer tabel gemmer den internationale kode for kundens tidszone, uanset hvor den er.
Lad os derefter se på postnummeret. USA kræver et 5-cifret postnummer (Zip af US_Address tabel) plus den valgfri ZIP+4 (Zip4 af US_Address bord). Address tabellen har et mere fleksibelt PostCode Mark. Bortset fra længden er der ingen begrænsning på de oplysninger, der kan gemmes i PostCode; selvfølgelig kunne applikationen implementere kontrol af postnumre.
Bemærk også, at de amerikanske og ikke-amerikanske designs begge har et felt for regioner i et land (State i US_Address tabel og Region i Address tabel), men det amerikanske design kræver, at en statsforkortelse på 2 tegn er inkluderet. Bemærk også, at det amerikanske design ikke accepterer internationale adresser, mens den internationale adresseversion gør det (deraf ISO-landekoden på 2 tegn Land for Address tabel).
Her er pointen: Begræns ikke din datamodel af adresser til én lokalitet; efterlad nok plads til forskellige stilarter.
5. Dato- og tidsformatering
Datamodeller bør ikke bekymre sig om flere dato- og tidsformater; applikationen håndterer selve visningen. Dette kan gøres på forskellige måder:
- Den måned-første stil, almindelig i Nordamerika og andre steder:mm-dd-åååå
- Den første dag, som er mere almindelig i Europa:dd-mm-åååå
- År-første stil, brugt som ISO 8601-datoformat:åååå-mm-dd
Her er pointen: Dette kan være gentaget, men vi siger det igen:vælg dine datatyper korrekt, når du modellerer. Dette vil gøre det lettere for applikationskoden at fortolke og vise lagrede værdier.
Et andet punkt i denne kategori kan være lidt uventet:hvilken dag ugen starter på. For nogle er det søndag; for andre er det mandag (og så er der den persiske kalender, som starter ugen om lørdagen).
Tiderne skal også vises på en brugervenlig måde. Husk, at selvom din datamodel ikke har brug for flere tidsformater, kan du muligvis gemme brugerens tidspræference , dvs. 12- eller 24-timers formatet.
Dette fører os til tidszoner.
6. Tidszoner
Det er ikke usædvanligt at finde apps, der kun tillader brugere nogle få tidszonevalg:Eastern Time, Central Time, Mountain Time og Pacific Time. Når jeg ser det, ved jeg, at jeg har at gøre med en Amero-centreret applikationsdesigner. Nogle designere tillader en tidszone at blive udtrykt som en offset fra (normalt) GMT eller UTC. Mange begår dog den fejl, at de kun tillader forskydning af hele tal, uden at være klar over, at nogle lande (Indien, Iran, Pakistan, Afghanistan og andre) ikke er et heltal. De er brøkdele forskellige:Indien Standard Time er UTC+5:30. Nogle steder har endda en mindre delforskydning, såsom Nepal Standard Time – det er UTC+05:45.
For noget tid siden skrev jeg om en model til en online undersøgelsesdatabase. Her har jeg tilføjet en tidszone til brugertabellen, så vi kan vise datoer/klokkeslæt i brugernes lokale tider.
For mere information om datoer, klokkeslæt, tidszoner, kan du henvise til ISO 8601 standardrepræsentationen af datoer og klokkeslæt eller denne Wikipedia-artikel.
Her er pointen: Lær at tænke globalt, ikke kun lokalt.
7. Flersproget support
Der er adskillige tidspunkter, hvor din applikation muligvis skal yde flersproget support. Fra et datamodelperspektiv skal du muligvis have information lagret på flere sprog; dog bør det meste af den sproglige håndtering være dækket af din ansøgning. Implementeringen af flersproget support ligger uden for denne artikels omfang, men vi har allerede diskuteret det i denne blog.
Lokalisering er meget vigtig og skal håndteres ordentligt. Som vi allerede har påpeget, betyder dette mere end blot at støtte forskellige sprog; det handler også om de foretrukne formater for datoer, klokkeslæt, valutaer og endda decimalindikatorer.
Datamodellering? Tænk globalt
Mens du opretter din datamodel, skal du overveje den potentielle internationale brug af din applikation og dens database. Tænk globalt i designfasen, og du vil undgå nogle problemer senere – et telefonnummerfelt, der kun accepterer 3-cifre + 3-cifre + 4-cifre, fungerer fint i USA, men ikke så godt i Kina eller Indien.
Er dine databaser parate til at blive globale? Dit mål bør være at muliggøre fleksibilitet uden at skabe overvældende kompleksitet.