Muito poucos autores de banco de dados mencionam os desafios da globalização e localização de forma significativa. Há uma falta de previsão semelhante dos arquitetos de banco de dados. O fato é que muitos autores e designers são frequentemente muito “autocentrados”:eles criam (ou escrevem sobre) modelos de dados que apenas tratam adequadamente seus fusos horários locais, endereços etc.
Uma abordagem autocentrada tem um grande problema:o modelo resultante suportará apenas dados locais. No mundo atual, alimentado pela Internet, os aplicativos geralmente são acessados inesperadamente por usuários em todo o mundo. Precisamos apoiar o máximo de flexibilidade possível para esse público internacional. Portanto, precisamos projetar nossos modelos de dados com uma abordagem globalizada.
Tenho a sorte de trabalhar em um ambiente multinacional e multilíngue, então aprendi como as questões de globalização podem ser tratadas no início do projeto. Com isso em mente, reuni sete pontos importantes para criar um modelo de dados que dê suporte ao uso internacional.
1. Formatação de Número
Há duas coisas a serem consideradas quando você analisa a formatação de números:a saída que os usuários veem (ou seja, o formato) e o tipo de dados subjacente.
Você não precisa se preocupar com a forma como os números serão exibidos em seu modelo de dados – o sistema de banco de dados lidará com o armazenamento de números decimais e seu aplicativo deve ajustar como os números decimais são exibidos (“.” ou “,” como o decimal ponto, por exemplo). Da mesma forma, você não deve se preocupar com qual separador de milhares (como um ponto ou vírgula) seu modelo de dados usará.
Aqui está o ponto: Escolha seus tipos de dados corretamente ao modelar. Seu aplicativo deve lidar com a formatação de saída.
Por exemplo, neste modelo simples de um aplicativo de estação meteorológica, as medições meteorológicas (temperatura, umidade, precipitação) são armazenadas como números de ponto flutuante. Mas as informações de preço estão em decimal, semelhante às coordenadas GPS de cada estação meteorológica.
2. Moedas e taxas de câmbio
Se você estiver armazenando informações relacionadas a moedas, deverá armazenar o número correto de casas decimais para cada moeda. A maioria das moedas tem duas casas decimais, mas algumas não têm nenhuma (ou seja, o peso chileno), uma (o ariary malgaxe), três (o dinar tunisiano) ou mesmo quatro casas decimais (a Unidad de Fomento do Chile, uma unidade de conta usada para expressar um faixa de valores de preços.)
Portanto, certifique-se de que seus campos de “quantidade” no modelo de dados suportem mais de duas casas decimais – embora quatro casas decimais sejam muito raros, isso acontece. Três casas decimais é mais comum. Por exemplo, dinares em seis países diferentes (Bahrein, Iraque, Jordânia, Kuwait, Líbia, Tunísia) e rial em um país (Omã) exigem três casas decimais.
Ponto número 1: Escolha seu tipo de dados corretamente ao modelar.
Outro ponto importante relacionado às moedas são as taxas de câmbio. Estes exigem ainda mais precisão. Muitos sistemas fornecem apenas 4-6 dígitos significativos nas taxas de câmbio; às vezes há um fator de escala entre moedas que têm valores muito diferentes. No entanto, quatro ou seis dígitos significativos não significa necessariamente que haverá seis casas decimais. Verifique a taxa de câmbio entre rupias indonésias e euros:0,0000668755. São muitas casas decimais para armazenar em seu campo de taxa de câmbio.
Ponto número 2: Seu modelo pode precisar lidar com um alto nível de precisão – muitas casas decimais – quando se trata de taxas de câmbio.
Abaixo criamos um exemplo de loja online com preços. Também adicionamos uma tabela simples (destacada em aqua) que armazena as taxas de câmbio, incluindo taxas de câmbio históricas. Cada linha na
exchange_rate tabela está vinculada a uma moeda (currency_id , que é o código de moeda ISO 4217). Permitimos que uma taxa de câmbio seja armazenada para cada moeda em um determinado dia (rate_date ), e ter uma taxa de câmbio ativa para cada moeda. Obviamente, você precisará de algumas informações adicionais para usar esta tabela de taxas. Por exemplo, em relação a qual moeda base essas taxas de câmbio são definidas? Euros ou dólares americanos podem ser típicos, mas seu aplicativo precisaria de informações exatas aqui.
Alternativamente, um modelo mais complexo poderia armazenar pares de moedas, a taxa média (ou taxa bancária) e as taxas de 'compra' e 'venda' entre esses pares de moedas.
Ponto número 3: Seu modelo precisa ter informações suficientes para que o aplicativo possa usar os dados corretamente.
3. Números de telefone
Muitas vezes tenho visto sistemas que suportam apenas um número de telefone norte-americano de dez dígitos com um código de área de três dígitos, troca de três dígitos e número de assinante de quatro dígitos (ou seja, 012-345-6789). Esse viés é compreensível até certo ponto; as pessoas criam sistemas que suportam seus usuários locais. No entanto, a modelagem de dados não deve ignorar a possibilidade de que usuários globais possam acessar seu sistema. (Nota:o comprimento de dez dígitos também pode ser usado para outros números, como telefones celulares franceses, mas o formato é diferente (ou seja, 06 12 34 56 78).)
Tomemos isso como exemplo:suponha que eu more fora da fronteira francesa, mas trabalhe na França. Portanto, embora eu possa precisar usar aplicativos e provedores de serviços franceses, meu número de celular não é um número francês. Sistemas que exigem um número de celular de dez dígitos começando com 06 ou 07 não funcionarão para mim. Para conseguir passagens de trem francesas, comprar ingressos para um show na França (etc, etc), eu seria forçado a obter um número de telefone francês. Incômodo, para dizer o mínimo.
Aqui está o ponto: Quando as restrições de número de telefone são incorporadas ao modelo de dados, as modificações do modelo de dados serão necessárias para dar suporte a usuários não locais. Idealmente, flexibilidade suficiente deve ser incorporada ao modelo para lidar com todas as eventualidades.
Um modelo de dados mais lógico suportaria números de telefone de comprimentos diferentes (até 16 dígitos em algumas áreas) e caracteres não numéricos (como o símbolo universal “+” para um número de telefone internacional). Certamente, alguns aplicativos podem realizar mais validação implementando “regras locais” com as quais os desenvolvedores locais estariam mais familiarizados. Outros aplicativos podem usar números de telefone locais para acessar outras fontes de dados, como verificar ou recuperar um endereço com base em um número de telefone.
O modelo de dados deve suportar flexibilidade no armazenamento de informações. O aplicativo ou sua interface do usuário pode ser mais restritivo ou realizar validação adicional.
4. Endereços
Como um americano que vive no exterior, muitas vezes encontro exemplos e padrões de modelos de dados que são muito centrados em Amero. Por exemplo, um não americano pode não entender o que um Zip+4 é e, portanto, não entenderia por que um autor afirma que esse domínio deve ter uma característica NOT NULL.
Essa visão amerocêntrica está presente até nos livros. Por exemplo, pegue o livro bastante extenso “Data Model Patterns. Convenções do Pensamento” por David C. Hay. A explicação muito complexa do Sr. Hay sobre endereços, locais, localizações geográficas, parcelas de terra e elementos de estrutura geográfica incluiu exemplos do Canadá, mas mesmo assim, essas informações podem não ser facilmente compreendidas por todos.
Os padrões do Sr. Hay dizem que os atributos de endereço incluirão:
O "texto" do endereço, mais pelo menos "cidade", "estado" e "código postal (CEP)".
Agora, o Sr. Hay é rápido em explicar em uma nota de rodapé que:
O contexto do modelo determinará se este atributo é "CEP" ou "código postal". Se a organização cliente operar inteiramente dentro dos Estados Unidos em um futuro previsível, a suposição de um "CEP" numérico de nove dígitos e duas partes pode ser feito. Caso contrário, "CEP" deve se tornar "código postal" e nenhuma suposição de formatação é possível.
No entanto, ele não menciona que “estado” pode ser um estado nos EUA, uma província no Canadá ou um atributo anulável para quase qualquer outro país, já que “estados” dentro de países raramente existem fora dos EUA, Canadá (onde eles são chamados de províncias, mas funcionam de forma semelhante) e Austrália. Certamente, outros países têm províncias e regiões, mas raramente são usadas como parte de um endereço.
Para ilustrar a gravidade desse problema de endereço, criei um modelo de dados para endereços americanos e não americanos. (Nota:Este não é o modelo completo.)
O
PrimaryPhone do US_Customer table armazena apenas números de telefone com dez ou menos caracteres. O design internacional do Customer PrimaryPhone da tabela O atributo permite um número de telefone de 15 dígitos mais “+”, que é o máximo especificado por E.164. O
TimeOffset atributo no US_Customer A tabela permite apenas quatro fusos horários:Hora do Leste, Hora Central, Hora da Montanha e Hora do Pacífico (armazenados no modelo de dados como:0 =Oriental, 1 =Central, 2 =Montanha, 3 =Pacífico). Aliás, isso nem abrange todos os fusos horários nos EUA e seus territórios. Por outro lado, o Timezone atributo no Customer table armazena o código internacional do fuso horário do cliente, independentemente de onde ele esteja. Em seguida, vamos ver o código postal/CEP. Os EUA exigem um CEP de 5 dígitos (
Zip do US_Address table) mais o ZIP+4 opcional (Zip4 do US_Address tabela). O Address tabela tem um PostCode mais flexível campo. Além do comprimento, não há restrição sobre as informações que podem ser armazenadas em PostCode; é claro, o aplicativo poderia implementar verificações em códigos postais. Observe também que os designs dos EUA e de fora dos EUA têm um campo para regiões dentro de um país (
State no US_Address tabela e Region no Address tabela), mas o design dos EUA exige que uma abreviação de estado de 2 caracteres seja incluída. Além disso, observe que o design dos EUA não aceita endereços internacionais, enquanto a versão de endereço internacional aceita (daí o código de país ISO de 2 caracteres País do Address tabela). Aqui está o ponto: Não limite seu modelo de dados de endereços a uma localidade; deixe espaço suficiente para diferentes estilos.
5. Formatação de data e hora
Os modelos de dados não devem se preocupar com vários formatos de data e hora; o aplicativo lida com a exibição real. Isso pode ser feito de várias maneiras:
- O estilo do primeiro mês, comum na América do Norte e em outros lugares:mm-dd-aaaa
- O estilo do primeiro dia, que é mais comum na Europa:dd-mm-aaaa
- O estilo do primeiro ano, usado como formato de data ISO 8601:aaaa-mm-dd
Aqui está o ponto: Isso pode ser repetitivo, mas vamos repetir:escolha seus tipos de dados corretamente ao modelar. Isso tornará mais fácil para o código do aplicativo interpretar e exibir os valores armazenados.
Outro item desta categoria pode ser um pouco inesperado:em que dia a semana começa. Para alguns, é domingo; para outros, é segunda-feira (e depois há o calendário persa, que começa a semana no sábado).
Os horários também devem ser exibidos de forma amigável. Lembre-se de que, embora seu modelo de dados não precise de vários formatos de hora, você pode armazenar a preferência de hora do usuário , ou seja, o formato de 12 ou 24 horas.
Isso nos leva a fusos horários.
6. Fusos horários
Não é incomum encontrar aplicativos que permitem aos usuários apenas algumas opções de fuso horário:Hora do Leste, Hora Central, Hora das Montanhas e Hora do Pacífico. Quando vejo isso, sei que estou lidando com um designer de aplicativos centrado no Amero. Alguns designers permitem que um fuso horário seja expresso como um deslocamento de (geralmente) GMT ou UTC. No entanto, muitos cometem o erro de permitir apenas deslocamentos de números inteiros, não percebendo que alguns países (Índia, Irã, Paquistão, Afeganistão e outros) não são um deslocamento de números inteiros. Eles são ligeiramente diferentes:o horário padrão da Índia é UTC+5:30. Alguns locais ainda têm um deslocamento fracionário menor, como o horário padrão do Nepal – é UTC + 05:45.
Algum tempo atrás, escrevi sobre um modelo para um banco de dados de pesquisa online. Aqui eu adicionei um fuso horário à tabela de usuários para que possamos exibir datas/horas nos horários locais dos usuários.
Para obter mais informações sobre datas, horas, fusos horários, você pode consultar a representação padrão ISO 8601 de datas e horas ou este artigo da Wikipedia.
Aqui está o ponto: Aprenda a pensar globalmente, não apenas localmente.
7. Suporte multilíngue
Há várias ocasiões em que seu aplicativo pode precisar fornecer suporte multilíngue. De uma perspectiva de modelo de dados, pode ser necessário ter informações armazenadas em vários idiomas; no entanto, a maior parte do tratamento linguístico deve ser abordada em seu aplicativo. A implementação do suporte multilíngue está além do escopo deste artigo, mas já discutimos isso neste blog.
A localização é muito importante e precisa ser tratada adequadamente. Como já apontamos, isso significa mais do que apenas oferecer suporte a diversos idiomas; trata-se também dos formatos preferidos para datas, horas, moedas e até indicadores decimais.
Modelagem de dados? Pense globalmente
Ao criar seu modelo de dados, considere o potencial uso internacional de seu aplicativo e seu banco de dados. Pense globalmente durante a fase de design e você evitará alguns problemas mais tarde – um campo de número de telefone que aceita apenas 3 dígitos + 3 dígitos + 4 dígitos funciona bem nos EUA, mas não tão bem na China ou na Índia.
Seus bancos de dados estão preparados para se tornarem globais? Seu objetivo deve ser permitir a flexibilidade sem criar uma complexidade esmagadora.
