Muy pocos autores de bases de datos mencionan los desafíos de la globalización y la localización de manera significativa. Hay una falta de previsión similar por parte de los arquitectos de bases de datos. El hecho es que muchos autores y diseñadores suelen ser muy "egocéntricos":crean (o escriben sobre) modelos de datos que solo manejan correctamente sus zonas horarias locales, direcciones, etc.
Un enfoque egocéntrico tiene un gran problema:el modelo resultante solo admitirá datos locales. En el mundo actual impulsado por Internet, los usuarios de todo el mundo a menudo acceden inesperadamente a las aplicaciones. Necesitamos apoyar la mayor flexibilidad posible para esta audiencia internacional. Por lo tanto, necesitamos diseñar nuestros modelos de datos con un enfoque globalizado.
Tengo la suerte de trabajar en un entorno muy multinacional y multilingüe, por lo que aprendí cómo se pueden manejar los problemas de globalización al comienzo del proyecto. Con eso en mente, he reunido siete puntos importantes para crear un modelo de datos que admita el uso internacional.
1. Formato de números
Hay dos cosas a considerar cuando observa el formato de números:la salida que ven los usuarios (es decir, el formato) y el tipo de datos subyacente.
No debería preocuparse por cómo se mostrarán los números en su modelo de datos:el sistema de base de datos manejará el almacenamiento de números decimales y su aplicación se ajustará a cómo se muestran los números decimales (“.” o “,” como el decimal punto, por ejemplo). Del mismo modo, no debería tener que preocuparse por qué separador de miles (como un punto o una coma) utilizará su modelo de datos.
Este es el punto: Elija sus tipos de datos correctamente al modelar. Su aplicación debe manejar el formato de salida.
Por ejemplo, en este modelo simple de una aplicación de estación meteorológica, las mediciones meteorológicas (temperatura, humedad, lluvia) se almacenan como números de coma flotante. Pero la información de precios está en decimal, similar a las coordenadas GPS de cada estación meteorológica.
2. Monedas y tipos de cambio
Si está almacenando información relacionada con monedas, debe almacenar el número correcto de lugares decimales para cada moneda. La mayoría de las monedas tienen dos decimales, pero algunas no tienen ninguno (es decir, el peso chileno), uno (el ariary malgache), tres (el dinar tunecino) o incluso cuatro decimales (la Unidad de Fomento de Chile, una unidad de cuenta utilizada para expresar un rango de valores de precio.)
Por lo tanto, asegúrese de que sus campos de "cantidad" en el modelo de datos admitan más de dos lugares decimales, mientras que cuatro lugares decimales es muy raro, sucede. Tres lugares decimales es más común. Por ejemplo, los dinares en seis países diferentes (Bahrein, Irak, Jordania, Kuwait, Libia, Túnez) y el rial en un país (Omán) requieren tres decimales.
Punto número 1: Elija su tipo de datos correctamente al modelar.
Otro punto importante relacionado con las monedas son los tipos de cambio. Estos exigen aún más precisión. Muchos sistemas solo proporcionan de 4 a 6 dígitos significativos en los tipos de cambio; a veces hay un factor de escala entre monedas que tienen valores muy diferentes. Sin embargo, cuatro o seis dígitos significativos no significan necesariamente que habrá seis decimales. Consulta el tipo de cambio entre Rupia Indonesia y Euros:0.0000668755. Son muchos lugares decimales para almacenar en su campo de tipo de cambio.
Punto número 2: Es posible que su modelo deba manejar un alto nivel de precisión (muchos decimales) cuando se trata de tipos de cambio.
A continuación, hemos creado un ejemplo de una tienda en línea con precios. También agregamos una tabla simple (resaltada en agua) que almacena los tipos de cambio de moneda, incluidos los tipos de cambio históricos. Cada fila en el exchange_rate la tabla está vinculada a una moneda (currency_id , que es el código de moneda ISO 4217). Permitimos que se almacene un tipo de cambio para cada moneda en un día en particular (rate_date ) y tener un tipo de cambio activo para cada moneda.
Obviamente, necesitará información adicional para usar esta tabla de tarifas. Por ejemplo, ¿contra qué moneda base se definen estos tipos de cambio? Euros o dólares estadounidenses pueden ser típicos, pero su solicitud necesitaría información exacta aquí.
Alternativamente, un modelo más complejo podría almacenar pares de divisas, la tasa media (o tasa bancaria) y las tasas de "compra" y "venta" entre esos pares de divisas.
Punto número 3: Su modelo debe tener suficiente información para que la aplicación pueda usar los datos correctamente.
3. Números de teléfono
A menudo he visto sistemas que solo admiten un número de teléfono norteamericano de diez dígitos con un código de área de tres dígitos, un intercambio de tres dígitos y un número de suscriptor de cuatro dígitos (es decir, 012-345-6789). Este sesgo es comprensible hasta cierto punto; la gente crea sistemas que apoyan a sus usuarios locales. Sin embargo, el modelado de datos no debe ignorar la posibilidad de que los usuarios globales puedan acceder a su sistema. (Nota:la longitud de diez dígitos también se puede usar para otros números, como los teléfonos móviles franceses, pero el formato es diferente (es decir, 06 12 34 56 78).)
Tomemos esto como ejemplo:Supongamos que vivo fuera de la frontera francesa, pero trabajo en Francia. Por lo tanto, si bien es posible que necesite usar aplicaciones y proveedores de servicios franceses, mi número de teléfono móvil no es un número francés. Los sistemas que requieren un número de teléfono móvil de diez dígitos que comience con 06 o 07 no me van a funcionar. Para conseguir billetes de tren en Francia, comprar entradas para un concierto en Francia (etc., etc.), me vería obligado a conseguir un número de teléfono francés. Molesto, por decir lo menos.
Este es el punto: Cuando las restricciones de número de teléfono están integradas en el modelo de datos, se requerirán modificaciones del modelo de datos para apoyar a los usuarios no locales. Idealmente, debería incorporarse suficiente flexibilidad en el modelo para manejar todas las eventualidades.
Un modelo de datos más lógico admitiría números de teléfono de diferentes longitudes (hasta 16 dígitos en algunas áreas) y caracteres no numéricos (como el símbolo universal "+" para un número de teléfono internacional). Ciertamente, algunas aplicaciones pueden realizar una mayor validación mediante la implementación de "reglas locales" con las que los desarrolladores locales estarían más familiarizados. Otras aplicaciones pueden usar números de teléfono locales para acceder a otras fuentes de datos, como verificar o recuperar una dirección basada en un número de teléfono.
El modelo de datos debe admitir flexibilidad en el almacenamiento de información. La aplicación o su interfaz de usuario pueden ser más restrictivas o realizar una validación adicional.
4. Direcciones
Como estadounidense que vive en el extranjero, a menudo encuentro ejemplos y patrones de modelos de datos que están demasiado centrados en Amero. Por ejemplo, es posible que un no estadounidense no comprenda lo que es un Zip+4 es y, por lo tanto, no entendería por qué un autor afirma que este dominio debe tener una característica NOT NULL.
Esta visión amerocéntrica está incluso presente en los libros. Por ejemplo, tome el libro bastante extenso “Data Model Patterns. Convenciones de pensamiento” por David C. Hay. La explicación muy compleja del Sr. Hay de direcciones, sitios, ubicaciones geográficas, parcelas de tierra y elementos de estructura geográfica incluye ejemplos de Canadá, pero aún así, esta información puede no ser captada fácilmente por todos.
Los patrones del Sr. Hay dicen que los atributos de la dirección incluirán:
El "texto" de la dirección, más al menos "ciudad", "estado" y "código postal".
Ahora, el Sr. Hay se apresura a explicar en una nota al pie que:
El contexto del modelo determinará si este atributo es "código postal" o "código postal". Si la organización cliente operará completamente dentro de los Estados Unidos en el futuro previsible, se puede hacer la suposición de un "código postal" numérico de dos partes y nueve dígitos. De lo contrario, el "código postal" debe convertirse en "código postal" y no es posible realizar suposiciones de formato.
Sin embargo, no menciona que "estado" puede ser un estado de los EE. UU., una provincia de Canadá o un atributo anulable para casi cualquier otro país, ya que los "estados" dentro de los países rara vez existen fuera de los EE. UU., Canadá (donde se llaman provincias pero funcionan de manera similar) y Australia. Ciertamente, otros países tienen provincias y regiones, pero rara vez se usan como parte de una dirección.
Para ilustrar cuán serio puede ser este problema de dirección, hice un modelo de datos para direcciones estadounidenses y no estadounidenses. (Nota:este no es el modelo completo).
El PrimaryPhone del US_Customer la tabla solo almacena números de teléfono con diez o menos caracteres. El diseño internacional del Customer PrimaryPhone de la tabla El atributo permite un número de teléfono de 15 dígitos más “+”, que es el máximo especificado por E.164.
El TimeOffset atributo en el US_Customer La tabla solo permite cuatro zonas horarias:Hora del Este, Hora del Centro, Hora de la Montaña y Hora del Pacífico (almacenadas en el modelo de datos como:0 =Este, 1 =Central, 2 =Montaña, 3 =Pacífico). Por cierto, esto ni siquiera cubre todas las zonas horarias de los EE. UU. y sus territorios. Por el contrario, la Timezone atributo en el Customer table almacena el código internacional para la zona horaria del cliente, independientemente de dónde se encuentre.
A continuación, veamos el código postal. EE. UU. requiere un código postal de 5 dígitos (Zip de la US_Address table) más el ZIP+4 opcional (Zip4 de la US_Address mesa). La Address la tabla tiene un PostCode más flexible campo. Aparte de la longitud, no hay restricciones sobre la información que se puede almacenar en PostCode; por supuesto, la aplicación podría implementar controles en los códigos postales.
Tenga en cuenta también que los diseños de EE. UU. y fuera de EE. UU. tienen un campo para regiones dentro de un país (State en el US_Address tabla y Region en la Address tabla), pero el diseño de EE. UU. requiere que se incluya una abreviatura de estado de 2 caracteres. Además, tenga en cuenta que el diseño de EE. UU. no acepta direcciones internacionales, mientras que la versión de dirección internacional sí lo hace (de ahí el código de país ISO de 2 caracteres País de la Address tabla).
Este es el punto: No limite su modelo de datos de direcciones a una localidad; deja suficiente espacio para diferentes estilos.
5. Formato de fecha y hora
Los modelos de datos no deberían preocuparse por múltiples formatos de fecha y hora; la aplicación maneja la pantalla real. Esto se puede hacer de varias maneras:
- El estilo de primer mes, común en América del Norte y en otros lugares:mm-dd-yyyy
- El estilo del primer día, que es más común en Europa:dd-mm-yyyy
- El estilo del primer año, utilizado como formato de fecha ISO 8601:yyyy-mm-dd
Este es el punto: Esto puede ser repetitivo, pero lo diremos nuevamente:elija sus tipos de datos correctamente al modelar. Esto facilitará que el código de la aplicación interprete y muestre los valores almacenados.
Otro elemento en esta categoría puede ser un poco inesperado:qué día comienza la semana. Para algunos, este es el domingo; para otros, es lunes (y luego está el calendario persa, que comienza la semana en sábado).
Los tiempos también deben mostrarse de una manera fácil de usar. Recuerde que si bien su modelo de datos no necesita múltiples formatos de tiempo, puede almacenar la preferencia de tiempo del usuario , es decir, el formato de 12 o 24 horas.
Esto nos lleva a las zonas horarias.
6. Zonas horarias
No es inusual encontrar aplicaciones que solo permiten a los usuarios unas pocas opciones de zona horaria:hora del este, hora central, hora de la montaña y hora del Pacífico. Cuando veo eso, sé que estoy tratando con un diseñador de aplicaciones centrado en Amero. Algunos diseñadores permiten que una zona horaria se exprese como un desplazamiento de (generalmente) GMT o UTC. Sin embargo, muchos cometen el error de permitir solo compensaciones de números enteros, sin darse cuenta de que algunos países (India, Irán, Pakistán, Afganistán y otros) no son una compensación de números enteros. Son ligeramente diferentes:la hora estándar de la India es UTC+5:30. Algunas ubicaciones incluso tienen un desplazamiento fraccional más pequeño, como la hora estándar de Nepal:es UTC+05:45.
Hace algún tiempo, escribí sobre un modelo para una base de datos de encuestas en línea. Aquí he agregado una zona horaria a la tabla de usuarios para que podamos mostrar las fechas/horas en las horas locales de los usuarios.
Para obtener más información sobre fechas, horas, zonas horarias, puede consultar la representación estándar ISO 8601 de fechas y horas o este artículo de Wikipedia.
Este es el punto: Aprende a pensar globalmente, no solo localmente.
7. Soporte multilingüe
Hay numerosas ocasiones en las que su aplicación puede necesitar proporcionar soporte multilingüe. Desde la perspectiva del modelo de datos, es posible que necesite tener información almacenada en varios idiomas; sin embargo, la mayor parte del manejo lingüístico debe estar cubierto en su aplicación. La implementación del soporte multilingüe está más allá del alcance de este artículo, pero ya lo hemos discutido en este blog.
La localización es muy importante y debe manejarse adecuadamente. Como ya hemos señalado, esto significa más que solo admitir diversos idiomas; también se trata de los formatos preferidos para fechas, horas, monedas e incluso indicadores decimales.
¿Modelado de datos? Piense Globalmente
Al crear su modelo de datos, considere el posible uso internacional de su aplicación y su base de datos. Piense globalmente durante la fase de diseño y evitará algunos problemas más adelante:un campo de número de teléfono que solo acepta 3 dígitos + 3 dígitos + 4 dígitos funciona bien en EE. UU., pero no tan bien en China o India.
¿Están preparadas sus bases de datos para globalizarse? Su objetivo debe ser permitir la flexibilidad sin crear una complejidad abrumadora.
