Très peu d'auteurs de bases de données mentionnent les défis de la mondialisation et de la localisation de manière significative. Il y a un manque de prévoyance similaire de la part des architectes de bases de données. Le fait est que de nombreux auteurs et concepteurs sont souvent très « égocentriques » :ils créent (ou écrivent sur) des modèles de données qui ne gèrent correctement que leurs fuseaux horaires locaux, leurs adresses, etc.
Une approche autocentrée a un gros problème :le modèle résultant ne prendra en charge que les données locales. Dans le monde d'aujourd'hui alimenté par Internet, les utilisateurs du monde entier accèdent souvent aux applications de manière inattendue. Nous devons soutenir autant de flexibilité que possible pour ce public international. Par conséquent, nous devons concevoir nos modèles de données avec une approche globalisée.
J'ai la chance de travailler dans un environnement très multinational et multilingue, j'ai donc appris comment les problèmes de mondialisation peuvent être traités au début du projet. Dans cet esprit, j'ai rassemblé sept points importants pour créer un modèle de données qui prendra en charge l'utilisation internationale.
1. Formatage des nombres
Il y a deux éléments à prendre en compte lorsque vous examinez le formatage des nombres :la sortie que les utilisateurs voient (c'est-à-dire le format) et le type de données sous-jacent.
Vous ne devriez pas avoir à vous soucier de la façon dont les nombres seront affichés dans votre modèle de données - le système de base de données gérera le stockage des nombres décimaux et votre application doit s'adapter à la façon dont les nombres décimaux sont affichés ("." ou "," comme décimal pointe, par exemple). De même, vous ne devriez pas avoir à vous soucier du séparateur de milliers (tel qu'un point ou une virgule) que votre modèle de données utilisera.
Voici le point : Choisissez correctement vos types de données lors de la modélisation. Votre application doit gérer le formatage de sortie.
Par exemple, dans ce modèle simple d'application de station météo, les mesures météorologiques (température, humidité, précipitations) sont stockées sous forme de nombres à virgule flottante. Mais les informations sur les prix sont en décimal, similaires aux coordonnées GPS de chaque station météo.
2. Devises et taux de change
Si vous stockez des informations relatives aux devises, vous devez stocker le nombre correct de décimales pour chaque devise. La plupart des monnaies ont deux décimales, mais certaines n'en ont aucune (c'est-à-dire le peso chilien), une (l'ariary malgache), trois (le dinar tunisien) ou même quatre décimales (l'Unidad de Fomento du Chili, une unité de compte utilisée pour exprimer un gamme de valeurs de prix.)
Assurez-vous donc que vos champs "montant" dans le modèle de données prennent en charge plus de deux décimales - bien que quatre décimales soient très rares, cela arrive. Trois décimales est plus courant. Par exemple, les dinars de six pays différents (Bahreïn, Irak, Jordanie, Koweït, Libye, Tunisie) et le rial d'un pays (Oman) nécessitent trois décimales.
Point numéro 1 : Choisissez correctement votre type de données lors de la modélisation.
Un autre point important lié aux devises est le taux de change. Celles-ci exigent encore plus de précision. De nombreux systèmes ne fournissent que 4 à 6 chiffres significatifs dans les taux de change; il y a parfois un facteur d'échelle entre des devises qui ont des valeurs très différentes. Cependant, quatre ou six chiffres significatifs ne signifient pas nécessairement qu'il y aura six décimales. Vérifiez le taux de change entre la roupie indonésienne et l'euro :0,0000668755. Cela fait beaucoup de décimales à stocker dans votre champ de taux de change.
Point numéro 2 : Votre modèle peut avoir besoin de gérer un haut niveau de précision (beaucoup de décimales) en ce qui concerne les taux de change.
Ci-dessous, nous avons créé un exemple de boutique en ligne avec des prix. Nous avons également ajouté un tableau simple (surligné en aqua) qui stocke les taux de change, y compris les taux de change historiques. Chaque ligne du exchange_rate table est liée à une devise (currency_id , qui est le code de devise ISO 4217). Nous autorisons le stockage d'un taux de change pour chaque devise un jour particulier (rate_date ), et ont un taux de change actif pour chaque devise.
Évidemment, vous aurez besoin de quelques informations supplémentaires pour utiliser ce tableau de taux. Par exemple, par rapport à quelle devise de base ces taux de change sont-ils définis ? Les euros ou les dollars américains peuvent être typiques, mais votre application aurait besoin d'informations exactes ici.
Alternativement, un modèle plus complexe pourrait stocker des paires de devises, le taux moyen (ou taux bancaire) et les taux « d'achat » et de « vente » entre ces paires de devises.
Point numéro 3 : Votre modèle doit disposer de suffisamment d'informations pour que l'application puisse utiliser correctement les données.
3. Numéros de téléphone
J'ai souvent vu des systèmes qui ne prennent en charge qu'un numéro de téléphone nord-américain à dix chiffres avec un indicatif régional à trois chiffres, un échange à trois chiffres et un numéro d'abonné à quatre chiffres (c'est-à-dire 012-345-6789). Ce biais est compréhensible dans une certaine mesure; les gens créent des systèmes qui prennent en charge leurs utilisateurs locaux. Cependant, la modélisation des données ne doit pas ignorer la possibilité que des utilisateurs mondiaux puissent accéder à votre système. (Remarque :la longueur à dix chiffres peut également être utilisée pour d'autres numéros, tels que les téléphones mobiles français, mais le format est différent (par exemple, 06 12 34 56 78).)
Prenons ceci comme exemple :supposons que j'habite juste à l'extérieur de la frontière française, mais que je travaille en France. Par conséquent, bien que je puisse avoir besoin d'utiliser des applications et des fournisseurs de services français, mon numéro de téléphone mobile n'est pas un numéro français. Les systèmes qui nécessitent un numéro de téléphone mobile à dix chiffres commençant par 06 ou 07 ne fonctionneront pas pour moi. Pour obtenir des billets de train français, acheter des billets pour un concert en France (etc, etc), je serais obligé d'obtenir un numéro de téléphone français. Ennuyeux, c'est le moins qu'on puisse dire.
Voici le point : Lorsque des contraintes de numéro de téléphone sont intégrées au modèle de données, des modifications du modèle de données seront nécessaires pour prendre en charge les utilisateurs non locaux. Idéalement, suffisamment de flexibilité devrait être incorporée dans le modèle pour faire face à toutes les éventualités.
Un modèle de données plus logique prendrait en charge des numéros de téléphone de différentes longueurs (jusqu'à 16 chiffres dans certaines régions) et des caractères non numériques (comme le symbole universel "+" pour un numéro de téléphone international). Certes, certaines applications peuvent effectuer plus de validation en implémentant des « règles locales » que les développeurs locaux connaissent mieux. D'autres applications peuvent utiliser des numéros de téléphone locaux pour accéder à d'autres sources de données, telles que la vérification ou la récupération d'une adresse basée sur un numéro de téléphone.
Le modèle de données doit prendre en charge la flexibilité dans le stockage des informations. L'application ou son interface utilisateur peuvent être plus restrictives ou effectuer une validation supplémentaire.
4. Adresses
En tant qu'Américain vivant à l'étranger, je trouve souvent des exemples de modèles de données et des modèles trop centrés sur l'Amérique. Par exemple, un non-Américain peut ne pas comprendre ce qu'est un Zip+4 est et ne comprendrait donc pas pourquoi un auteur déclare que ce domaine doit avoir une caractéristique NOT NULL.
Cette vision amérocentrique est même présente dans les livres. Par exemple, prenez le livre assez complet "Data Model Patterns. Conventions de pensée » par David C. Hay. L'explication très complexe de M. Hay sur les adresses, les sites, les emplacements géographiques, les parcelles de terrain et les éléments de structure géographique comprenait des exemples du Canada, mais même ainsi, ces informations peuvent ne pas être facilement saisies par tout le monde.
Les modèles de M. Hay indiquent que les attributs d'adresse incluront :
Le "texte" de l'adresse, plus au moins "ville", "état" et "code postal (ZIP)".
Maintenant, M. Hay s'empresse d'expliquer dans une note de bas de page que :
Le contexte du modèle déterminera si cet attribut est "ZIP code" ou "postal code". Si l'organisation cliente opérera entièrement aux États-Unis dans un avenir prévisible, l'hypothèse d'un "code postal" numérique à neuf chiffres en deux parties peut être faite. Sinon, "code postal" doit devenir "code postal" et aucune hypothèse de formatage n'est possible.
Cependant, il omet de mentionner que « État » peut être un État aux États-Unis, une province au Canada ou un attribut annulable pour presque tous les autres pays, car les « États » dans les pays existent rarement en dehors des États-Unis, du Canada (où ils sont appelées provinces mais fonctionnent de manière similaire) et l'Australie. Certes, d'autres pays ont des provinces et des régions, mais celles-ci sont rarement utilisées dans le cadre d'une adresse.
Pour illustrer la gravité de ce problème d'adresse, j'ai créé un modèle de données pour les adresses américaines et non américaines. (Remarque :il ne s'agit pas du modèle complet.)
Le PrimaryPhone du US_Customer table stocke uniquement les numéros de téléphone avec dix caractères ou moins. La conception internationale du Customer PrimaryPhone de la table L'attribut autorise un numéro de téléphone de 15 chiffres plus "+", qui est le maximum spécifié par E.164.
Le TimeOffset attribut dans le US_Customer La table n'autorise que quatre fuseaux horaires :heure de l'Est, heure du Centre, heure des Rocheuses et heure du Pacifique (stockée dans le modèle de données sous la forme :0 =Est, 1 =Centre, 2 =Montagne, 3 =Pacifique). Incidemment, cela ne couvre même pas tous les fuseaux horaires des États-Unis et de ses territoires. En revanche, le Timezone attribut dans le Customer table stocke le code international du fuseau horaire du client, quel que soit l'endroit où il se trouve.
Ensuite, regardons le code postal/Zip. Les États-Unis exigent un code postal à 5 chiffres (Zip du US_Address table) plus le ZIP+4 facultatif (Zip4 du US_Address table). L'Address table a un PostCode plus flexible domaine. Hormis la longueur, il n'y a aucune contrainte sur les informations qui peuvent être stockées dans PostCode; bien sûr, l'application pourrait implémenter des contrôles sur les codes postaux.
Notez également que les conceptions américaines et non américaines ont toutes deux un champ pour les régions d'un pays (State dans le US_Address table et Region dans l'Address tableau), mais la conception américaine exige qu'une abréviation d'état à 2 caractères soit incluse. Notez également que la conception américaine n'accepte pas les adresses internationales, contrairement à la version d'adresse internationale (d'où le code de pays ISO à 2 caractères Pays de l'Address tableau).
Voici le point : Ne limitez pas votre modèle de données d'adresses à une localité; laissez suffisamment de place pour différents styles.
5. Formatage de la date et de l'heure
Les modèles de données ne doivent pas être concernés par plusieurs formats de date et d'heure ; l'application gère l'affichage proprement dit. Cela peut se faire de différentes manières :
- Le style du premier mois, courant en Amérique du Nord et ailleurs :mm-jj-aaaa
- Le style du premier jour, plus courant en Europe :jj-mm-aaaa
- Le style "année première", utilisé comme format de date ISO 8601 :aaaa-mm-jj
Voici le point : Cela peut être répétitif, mais nous le répétons :choisissez correctement vos types de données lors de la modélisation. Cela facilitera l'interprétation et l'affichage des valeurs stockées par le code de l'application.
Un autre élément de cette catégorie peut être un peu inattendu :quel jour commence la semaine. Pour certains, c'est dimanche; pour d'autres, c'est lundi (et puis il y a le calendrier persan, qui commence la semaine le samedi).
Les horaires doivent également être affichés de manière conviviale. N'oubliez pas que même si votre modèle de données n'a pas besoin de plusieurs formats d'heure, vous pouvez stocker la préférence d'heure de l'utilisateur , c'est-à-dire le format 12 ou 24 heures.
Cela nous amène aux fuseaux horaires.
6. Fuseaux horaires
Il n'est pas rare de trouver des applications qui ne permettent aux utilisateurs que quelques choix de fuseaux horaires :heure de l'Est, heure du Centre, heure des Rocheuses et heure du Pacifique. Quand je vois ça, je sais que j'ai affaire à un concepteur d'application centré sur l'améro. Certains concepteurs permettent d'exprimer un fuseau horaire sous forme de décalage par rapport (généralement) à GMT ou UTC. Cependant, beaucoup commettent l'erreur de n'autoriser que des compensations de nombres entiers, sans se rendre compte que certains pays (Inde, Iran, Pakistan, Afghanistan et autres) ne sont pas des compensations de nombres entiers. Ils sont légèrement différents :l'heure standard de l'Inde est UTC + 5:30. Certains emplacements ont même un décalage fractionnaire plus petit, comme l'heure normale du Népal - c'est UTC + 05:45.
Il y a quelque temps, j'ai écrit sur un modèle de base de données d'enquête en ligne. Ici, j'ai ajouté un fuseau horaire à la table des utilisateurs afin que nous puissions afficher les dates/heures dans les heures locales des utilisateurs.
Pour plus d'informations sur les dates, heures, fuseaux horaires, vous pouvez vous référer à la norme ISO 8601 de représentation des dates et heures ou à cet article Wikipedia.
Voici le point : Apprenez à penser globalement, pas seulement localement.
7. Assistance multilingue
Il arrive souvent que votre application doive fournir un support multilingue. Du point de vue du modèle de données, vous devrez peut-être disposer d'informations stockées dans plusieurs langues ; cependant, la plupart des manipulations linguistiques doivent être couvertes dans votre candidature. La mise en œuvre de la prise en charge multilingue dépasse le cadre de cet article, mais nous en avons déjà discuté dans ce blog.
La localisation est très importante et doit être gérée correctement. Comme nous l'avons déjà souligné, cela signifie plus que simplement prendre en charge diverses langues; il s'agit également des formats préférés pour les dates, les heures, les devises et même les indicateurs décimaux.
Modélisation des données ? Penser globalement
Lors de la création de votre modèle de données, tenez compte de l'utilisation internationale potentielle de votre application et de sa base de données. Pensez globalement pendant la phase de conception et vous éviterez certains problèmes plus tard - un champ de numéro de téléphone qui n'accepte que 3 chiffres + 3 chiffres + 4 chiffres fonctionne bien aux États-Unis, mais pas aussi bien en Chine ou en Inde.
Vos bases de données sont-elles prêtes à devenir mondiales ? Votre objectif doit être de permettre la flexibilité sans créer de complexité écrasante.
