Jen velmi málo autorů databází zmiňuje výzvy globalizace a lokalizace nějakým smysluplným způsobem. Podobný nedostatek prozíravosti mají databázoví architekti. Faktem je, že mnoho autorů a designérů je často velmi „sebestředných“:vytvářejí (nebo o nich píší) datové modely, které pouze správně zpracovávají jejich místní časová pásma, adresy atd.
Sebecentrický přístup má velký problém:výsledný model bude podporovat pouze lokální data. V dnešním světě plném internetu jsou aplikace často neočekávaně přístupné uživateli po celém světě. Musíme podporovat co největší flexibilitu pro toto mezinárodní publikum. Proto musíme naše datové modely navrhovat s globalizovaným přístupem.
Mám to štěstí, že pracuji ve velmi mnohonárodním a vícejazyčném prostředí, takže jsem se naučil, jak lze řešit problémy globalizace na začátku projektu. S ohledem na to jsem dal dohromady sedm důležitých bodů pro vytvoření datového modelu, který bude podporovat mezinárodní použití.
1. Formátování čísel
Když se podíváte na formátování čísel, je třeba vzít v úvahu dvě věci:výstup, který uživatelé vidí (tj. formát), a základní datový typ.
Nemusíte se starat o to, jak budou čísla zobrazena ve vašem datovém modelu – databázový systém si poradí s ukládáním desetinných čísel a vaše aplikace by se měla přizpůsobit tomu, jak se zobrazují desetinná čísla („“ nebo „,“ jako desetinné číslo bod, například). Podobně byste se neměli starat o to, který oddělovač tisíců (jako je tečka nebo čárka) váš datový model použije.
Tady je pointa: Při modelování správně vyberte datové typy. Vaše aplikace by měla zvládnout výstupní formátování.
Například v tomto jednoduchém modelu aplikace meteorologické stanice jsou měření počasí (teplota, vlhkost, srážky) uložena jako čísla s plovoucí desetinnou čárkou. Ale informace o ceně jsou v desítkové soustavě, podobně jako GPS souřadnice každé meteorologické stanice.
2. Měny a směnné kurzy
Pokud ukládáte informace týkající se měn, musíte pro každou měnu uložit správný počet desetinných míst. Většina měn má dvě desetinná místa, ale některé nemají žádné (tj. chilské peso), jedno (malgašský ariary), tři (tuniský dinár) nebo dokonce čtyři desetinná místa (chilský Unidad de Fomento, zúčtovací jednotka používaná k vyjádření rozsah cenových hodnot.)
Ujistěte se tedy, že vaše pole „množství“ v datovém modelu podporují více než dvě desetinná místa – i když jsou čtyři desetinná místa velmi vzácná, stává se to. Běžnější jsou tři desetinná místa. Například dináry v šesti různých zemích (Bahrajn, Irák, Jordánsko, Kuvajt, Libye, Tunisko) a rialy v jedné zemi (Omán) vyžadují tři desetinná místa.
Bod číslo 1: Při modelování správně vyberte typ dat.
Dalším důležitým bodem souvisejícím s měnami jsou směnné kurzy. Ty vyžadují ještě větší přesnost. Mnoho systémů poskytuje pouze 4-6 platných číslic ve směnných kurzech; někdy existuje škálovací faktor mezi měnami, které mají výrazně odlišné hodnoty. Čtyři nebo šest platných číslic však nemusí nutně znamenat, že zde bude šest desetinných míst. Zkontrolujte směnný kurz mezi indonéskou rupií a eurem:0,0000668755. To je mnoho desetinných míst k uložení do pole směnného kurzu.
Bod číslo 2: Váš model může potřebovat zvládnout vysokou úroveň přesnosti – mnoho desetinných míst – pokud jde o směnné kurzy.
Níže jsme vytvořili příklad internetového obchodu s cenami. Přidali jsme také jednoduchou tabulku (zvýrazněnou aqua), která ukládá směnné kurzy, včetně historických směnných kurzů. Každý řádek v exchange_rate tabulka je propojena s měnou (currency_id , což je kód měny ISO 4217). Umožňujeme uložení jednoho směnného kurzu pro každou měnu v určitý den (rate_date ) a mají jeden aktivní směnný kurz pro každou měnu.
K použití této tabulky sazeb budete samozřejmě potřebovat další informace. Například vůči jaké základní měně jsou tyto směnné kurzy definovány? Typické mohou být eura nebo americké dolary, ale vaše aplikace by zde potřebovala přesné informace.
Alternativně by složitější model mohl ukládat měnové páry, střední sazbu (nebo bankovní sazbu) a kurzy „nákup“ a „prodej“ mezi těmito měnovými páry.
Bod číslo 3: Váš model musí mít dostatek informací, aby aplikace mohla data správně využívat.
3. Telefonní čísla
Často jsem viděl systémy, které podporují pouze severoamerické desetimístné telefonní číslo s třímístným předčíslím, třímístnou ústřednou a čtyřmístným předplatitelským číslem (tj. 012-345-6789). Tato zaujatost je do jisté míry pochopitelná; lidé vytvářejí systémy, které podporují jejich místní uživatele. Datové modelování by však nemělo ignorovat možnost, že do vašeho systému mohou přistupovat globální uživatelé. (Poznámka:Desetimístnou délku lze použít i pro jiná čísla, například pro francouzské mobilní telefony, ale formát je jiný (tj. 06 12 34 56 78).)
Vezměme si to jako příklad:Předpokládejme, že žiji těsně za francouzskými hranicemi, ale pracuji ve Francii. Proto, i když možná budu muset používat francouzské aplikace a poskytovatele služeb, moje číslo mobilního telefonu není francouzské číslo. Systémy, které vyžadují desetimístné mobilní číslo začínající 06 nebo 07, mi nebudou fungovat. Abych získal lístky na francouzskou železnici, koupil lístky na koncert ve Francii (atd. atd.), byl bych nucen získat francouzské telefonní číslo. Přinejmenším otravné.
Tady je pointa: Když jsou do datového modelu zabudována omezení telefonních čísel, budou vyžadovány úpravy datového modelu na podporu nemístních uživatelů. V ideálním případě by měla být do modelu začleněna dostatečná flexibilita, aby bylo možné zvládnout všechny eventuality.
Logičtější datový model by podporoval telefonní čísla různých délek (v některých oblastech až 16 číslic) a nečíselné znaky (jako univerzální symbol „+“ pro mezinárodní telefonní číslo). Některé aplikace mohou samozřejmě provádět větší ověřování implementací „místních pravidel“, která by místní vývojáři znali lépe. Jiné aplikace mohou používat místní telefonní čísla k přístupu k dalším zdrojům dat, jako je ověření nebo načtení adresy na základě telefonního čísla.
Datový model by měl podporovat flexibilitu při ukládání informací. Aplikace nebo její uživatelské rozhraní může být více omezující nebo může provádět dodatečné ověření.
4. Adresy
Jako Američan žijící v zahraničí často nacházím příklady datových modelů a vzory, které jsou příliš amerocentrické. Neameričan například nemusí rozumět tomu, co je Zip+4 je, a proto by nechápal, proč autor uvádí, že tato doména musí mít vlastnost NOT NULL.
Tento amerocentrický pohled je přítomen i v knihách. Vezměte si například poměrně rozsáhlou knihu „Data Model Patterns. Konvence myšlení“ od Davida C. Haye. Velmi složité vysvětlení adres, míst, geografických lokalit, pozemků a prvků geografické struktury pana Haye zahrnovalo příklady z Kanady, ale i tak tyto informace nemusí každý snadno pochopit.
Vzory pana Haye říkají, že atributy adresy budou zahrnovat:
"Text" adresy plus alespoň "město", "stát" a "PSČ".
Nyní pan Hay rychle vysvětluje v poznámce pod čarou, že:
Kontext modelu určí, zda je tento atribut „PSČ“ nebo „PSČ“. Pokud bude klientská organizace v dohledné době působit výhradně ve Spojených státech, lze předpokládat devítimístné dvoudílné číselné „PSČ“. Pokud ne, "PSČ" se musí změnit na "PSČ" a nejsou možné žádné předpoklady formátování.
Neuvádí však, že „stát“ může být stát v USA, provincie v Kanadě nebo atribut s možností zrušení platnosti pro téměř jakoukoli jinou zemi, protože „státy“ v rámci zemí jen zřídka existují mimo USA, Kanadu (kde se nazývají provincie, ale fungují podobně) a Austrálie. Jistě, jiné země mají provincie a regiony, ale ty se jako součást adresy používají jen zřídka.
Abych ilustroval, jak závažný může být tento problém s adresou, vytvořil jsem datový model pro americké i neamerické adresy. (Poznámka:Toto není úplný model.)
PrimaryPhone US_Customer tabulka ukládá pouze telefonní čísla s deseti nebo méně znaky. Mezinárodní design Customer PrimaryPhone stolu atribut umožňuje telefonní číslo o 15 číslicích plus „+“, což je maximum specifikované v E.164.
TimeOffset atribut v US_Customer tabulka umožňuje pouze čtyři časová pásma:východní čas, centrální čas, horský čas a tichomořský čas (uložené v datovém modelu jako:0 =východní, 1 =střední, 2 =horský, 3 =tichomořský). To mimochodem nepokrývá ani všechna časová pásma v USA a na jejich územích. Naproti tomu Timezone atributu Customer tabulka ukládá mezinárodní kód pro časové pásmo zákazníka bez ohledu na to, kde se nachází.
Dále se podívejme na poštovní směrovací číslo. USA vyžadují 5místné PSČ (Zip z US_Address tabulka) plus volitelný ZIP+4 (Zip4 z US_Address stůl). Address tabulka má flexibilnější PostCode pole. Kromě délky neexistují žádná omezení ohledně informací, které mohou být uloženy v PostCode; aplikace by samozřejmě mohla provádět kontroly poštovních směrovacích čísel.
Všimněte si také, že designy pro USA i mimo USA mají pole pro oblasti v rámci země (State v US_Address tabulka a Region v Address tabulka), ale americký návrh vyžaduje, aby byla zahrnuta 2znaková zkratka státu. Všimněte si také, že americký design nepřijímá mezinárodní adresy, zatímco verze mezinárodní adresy ano (odtud 2znakový kód země ISO země v Address tabulka).
Tady je pointa: Neomezujte svůj datový model adres na jednu lokalitu; ponechte dostatek prostoru pro různé styly.
5. Formátování data a času
Datové modely by se neměly zabývat více formáty data a času; aplikace se stará o skutečné zobrazení. To lze provést různými způsoby:
- Styl prvního měsíce, běžný v Severní Americe a jinde:mm-dd-yyyy
- Styl první den, který je v Evropě běžnější:dd-mm-yyyy
- Styl prvního roku používaný jako formát data ISO 8601:yyyy-mm-dd
Tady je pointa: Může se to opakovat, ale zopakujeme to:při modelování vyberte správně typy dat. To kódu aplikace usnadní interpretaci a zobrazení uložených hodnot.
Další položka v této kategorii může být trochu nečekaná:kterým dnem týden začíná. Pro některé je to neděle; pro ostatní je pondělí (a pak je tu perský kalendář, který začíná týden v sobotu).
Časy musí být také zobrazeny uživatelsky přívětivým způsobem. Pamatujte, že ačkoli váš datový model nepotřebuje více formátů času, můžete uložit časové preference uživatele , tedy 12hodinový nebo 24hodinový formát.
To nás vede k časovým pásmům.
6. Časová pásma
Není neobvyklé najít aplikace, které uživatelům umožňují vybrat pouze několik časových pásem:východní čas, centrální čas, horský čas a tichomořský čas. Když to vidím, vím, že mám co do činění s návrhářem aplikací zaměřeným na Ameriku. Někteří návrháři umožňují vyjádřit časové pásmo jako posun od (obvykle) GMT nebo UTC. Mnozí však dělají tu chybu, že povolují pouze celočíselné kompenzace, přičemž si neuvědomují, že některé země (Indie, Írán, Pákistán, Afghánistán a další) celočíselné kompenzace nejsou. Jsou nepatrně odlišné:Indický standardní čas je UTC+5:30. Některá místa mají dokonce menší zlomkový posun, jako je nepálský standardní čas – je to UTC+05:45.
Před časem jsem psal o modelu pro online databázi průzkumů. Zde jsem přidal časové pásmo do tabulky uživatelů, abychom mohli zobrazovat data/časy v místních časech uživatelů.
Další informace o datech, časech a časových pásmech naleznete ve standardní reprezentaci dat a časů ISO 8601 nebo v tomto článku na Wikipedii.
Tady je pointa: Naučte se myslet globálně, nejen lokálně.
7. Vícejazyčná podpora
Mnohokrát může vaše aplikace potřebovat podporu ve více jazycích. Z hlediska datového modelu možná budete potřebovat mít informace uložené ve více jazycích; většina jazykového zpracování by však měla být pokryta ve vaší aplikaci. Implementace vícejazyčné podpory je nad rámec tohoto článku, ale již jsme o tom diskutovali v tomto blogu.
Lokalizace je velmi důležitá a je potřeba s ní správně zacházet. Jak jsme již uvedli, znamená to více než jen podporu různých jazyků; jde také o preferované formáty pro data, časy, měny a dokonce i desetinné ukazatele.
Datové modelování? Myslete globálně
Při vytváření datového modelu zvažte potenciální mezinárodní využití vaší aplikace a její databáze. Během fáze návrhu myslete globálně a později se vyhnete některým problémům – pole pro telefonní číslo, které přijímá pouze 3-místné + 3-místné + 4místné číslice, funguje dobře v USA, ale ne tak dobře v Číně nebo Indii.
Jsou vaše databáze připraveny na globální expanzi? Vaším cílem by mělo být umožnit flexibilitu, aniž byste vytvářeli ohromující složitost.