Nur sehr wenige Datenbankautoren erwähnen die Herausforderungen der Globalisierung und Lokalisierung in sinnvoller Weise. Es gibt einen ähnlichen Mangel an Voraussicht bei Datenbankarchitekten. Tatsache ist, dass viele Autoren und Designer häufig sehr „egozentrisch“ sind:Sie erstellen (oder schreiben über) Datenmodelle, die nur ihre lokalen Zeitzonen, Adressen usw. richtig behandeln.
Ein selbstzentrierter Ansatz hat ein großes Problem:Das resultierende Modell unterstützt nur lokale Daten. In der heutigen internetbasierten Welt wird von Benutzern auf der ganzen Welt häufig unerwartet auf Anwendungen zugegriffen. Wir müssen diesem internationalen Publikum so viel Flexibilität wie möglich bieten. Daher müssen wir unsere Datenmodelle mit einem globalisierten Ansatz entwerfen.
Ich habe das Glück, in einem sehr multinationalen und mehrsprachigen Umfeld zu arbeiten, daher habe ich zu Beginn des Projekts gelernt, wie mit Globalisierungsproblemen umgegangen werden kann. Vor diesem Hintergrund habe ich sieben wichtige Punkte für die Erstellung eines Datenmodells zusammengestellt, das eine internationale Nutzung unterstützt.
1. Zahlenformatierung
Bei der Zahlenformatierung sind zwei Dinge zu beachten:die Ausgabe, die Benutzer sehen (d. h. das Format), und der zugrunde liegende Datentyp.
Sie sollten sich keine Gedanken darüber machen müssen, wie Zahlen in Ihrem Datenmodell angezeigt werden – das Datenbanksystem übernimmt die Speicherung von Dezimalzahlen, und Ihre Anwendung sollte sich daran anpassen, wie Dezimalzahlen angezeigt werden („.“ oder „,“ als Dezimalzahl). Punkt zum Beispiel). Ebenso sollten Sie sich keine Gedanken darüber machen müssen, welches Tausendertrennzeichen (z. B. Punkt oder Komma) Ihr Datenmodell verwenden wird.
Hier ist der Punkt: Wählen Sie Ihre Datentypen bei der Modellierung richtig aus. Ihre Anwendung sollte die Ausgabeformatierung übernehmen.
Beispielsweise werden in diesem einfachen Modell einer Wetterstationsanwendung die Wettermesswerte (Temperatur, Luftfeuchtigkeit, Niederschlag) als Fließkommazahlen gespeichert. Aber die Preisangaben sind dezimal, ähnlich wie die GPS-Koordinaten jeder Wetterstation.
2. Währungen und Wechselkurse
Wenn Sie währungsbezogene Informationen speichern, müssen Sie für jede Währung die korrekte Anzahl an Dezimalstellen speichern. Die meisten Währungen haben zwei Dezimalstellen, aber einige haben keine (z. B. der chilenische Peso), eine (der madagassische Ariary), drei (der tunesische Dinar) oder sogar vier Dezimalstellen (Chiles Unidad de Fomento, eine Rechnungseinheit, die verwendet wird, um a auszudrücken Bereich von Preiswerten.)
Stellen Sie also sicher, dass Ihre „Betrags“-Felder im Datenmodell mehr als zwei Dezimalstellen unterstützen – obwohl vier Dezimalstellen sehr selten sind, kommt es vor. Drei Dezimalstellen sind häufiger. Zum Beispiel erfordern Dinar in sechs verschiedenen Ländern (Bahrain, Irak, Jordanien, Kuwait, Libyen, Tunesien) und Rial in einem Land (Oman) drei Dezimalstellen.
Punkt Nummer 1: Wählen Sie Ihren Datentyp beim Modellieren richtig aus.
Ein weiterer wichtiger Punkt im Zusammenhang mit Währungen sind Wechselkurse. Diese verlangen noch mehr Präzision. Viele Systeme bieten nur 4-6 signifikante Stellen in Wechselkursen; Manchmal gibt es einen Skalierungsfaktor zwischen Währungen, die sehr unterschiedliche Werte haben. Vier oder sechs signifikante Ziffern bedeuten jedoch nicht unbedingt, dass es sechs Dezimalstellen gibt. Überprüfen Sie den Wechselkurs zwischen Indonesischer Rupiah und Euro:0,0000668755. Das sind viele Dezimalstellen, die Sie in Ihrem Wechselkursfeld speichern können.
Punkt Nummer 2: Ihr Modell muss möglicherweise ein hohes Maß an Genauigkeit – viele Dezimalstellen – verarbeiten, wenn es um Wechselkurse geht.
Unten haben wir ein Beispiel für einen Online-Shop mit Preisen erstellt. Wir haben auch eine einfache Tabelle (in Aqua hervorgehoben) hinzugefügt, in der Wechselkurse gespeichert sind, einschließlich historischer Wechselkurse. Jede Zeile im exchange_rate Tabelle ist mit einer Währung verknüpft (currency_id , dem Währungscode nach ISO 4217). Wir erlauben die Speicherung eines Wechselkurses für jede Währung an einem bestimmten Tag (rate_date ) und haben einen aktiven Wechselkurs für jede Währung.
Natürlich benötigen Sie einige zusätzliche Informationen, um diese Tariftabelle zu verwenden. Gegen welche Basiswährung werden diese Wechselkurse beispielsweise definiert? Euro oder US-Dollar könnten typisch sein, aber Ihre Bewerbung benötigt hier genaue Informationen.
Alternativ könnte ein komplexeres Modell Währungspaare, den Mittelkurs (oder Bankkurs) und die „Kauf“- und „Verkaufs“-Kurse zwischen diesen Währungspaaren speichern.
Punkt Nummer 3: Ihr Modell muss über genügend Informationen verfügen, damit die Anwendung die Daten richtig verwenden kann.
3. Telefonnummern
Ich habe oft Systeme gesehen, die nur eine nordamerikanische zehnstellige Telefonnummer mit einer dreistelligen Vorwahl, einer dreistelligen Vermittlungsstelle und einer vierstelligen Teilnehmernummer (z. B. 012-345-6789) unterstützen. Diese Voreingenommenheit ist bis zu einem gewissen Grad verständlich; Menschen erstellen Systeme, die ihre lokalen Benutzer unterstützen. Bei der Datenmodellierung sollte jedoch die Möglichkeit nicht außer Acht gelassen werden, dass globale Benutzer auf Ihr System zugreifen könnten. (Hinweis:Die zehnstellige Länge kann auch für andere Nummern verwendet werden, z. B. für französische Mobiltelefone, aber das Format ist anders (z. B. 06 12 34 56 78).)
Nehmen wir dies als Beispiel:Angenommen, ich wohne direkt außerhalb der französischen Grenze, arbeite aber in Frankreich. Obwohl ich möglicherweise französische Anwendungen und Dienstanbieter verwenden muss, ist meine Mobiltelefonnummer daher keine französische Nummer. Systeme, die eine zehnstellige Handynummer benötigen, die mit 06 oder 07 beginnt, werden für mich nicht funktionieren. Um französische Bahntickets zu bekommen, Tickets für ein Konzert in Frankreich zu kaufen (etc, etc), wäre ich gezwungen, eine französische Telefonnummer zu bekommen. Lästig, um es gelinde auszudrücken.
Hier ist der Punkt: Wenn Telefonnummerneinschränkungen in das Datenmodell integriert sind, sind Datenmodelländerungen erforderlich um nicht-lokale Benutzer zu unterstützen. Idealerweise sollte genügend Flexibilität in das Modell eingebaut werden, um mit allen Eventualitäten umgehen zu können.
Ein logischeres Datenmodell würde Telefonnummern unterschiedlicher Länge (bis zu 16 Ziffern in einigen Gebieten) und nicht numerische Zeichen (wie das universelle „+“-Symbol für eine internationale Telefonnummer) unterstützen. Sicherlich können einige Anwendungen mehr Validierung durchführen, indem sie „lokale Regeln“ implementieren, mit denen lokale Entwickler besser vertraut wären. Andere Apps verwenden möglicherweise lokale Telefonnummern, um auf andere Datenquellen zuzugreifen, z. B. um eine Adresse basierend auf einer Telefonnummer zu überprüfen oder abzurufen.
Das Datenmodell sollte die Flexibilität beim Speichern von Informationen unterstützen. Die Anwendung oder ihre Benutzeroberfläche kann restriktiver sein oder eine zusätzliche Validierung durchführen.
4. Adressen
Als im Ausland lebender Amerikaner finde ich oft Beispiele und Muster von Datenmodellen, die zu amerikanisch sind. Beispielsweise versteht ein Nicht-Amerikaner möglicherweise nicht, was ein Zip+4 bedeutet ist und hätte daher kein Verständnis dafür, warum ein Autor angibt, dass diese Domain ein NOT NULL-Merkmal haben muss.
Diese amerozentrische Sichtweise findet sich sogar in Büchern. Nehmen Sie zum Beispiel das recht umfangreiche Buch „Data Model Patterns. Denkkonventionen“ von David C. Hay. Mr. Hays sehr komplexe Erläuterung von Adressen, Standorten, geografischen Standorten, Grundstücken und geografischen Strukturelementen enthielt Beispiele aus Kanada, aber selbst dann sind diese Informationen möglicherweise nicht für jeden leicht verständlich.
Die Muster von Mr. Hay besagen, dass die Adressattribute Folgendes enthalten:
Der "Text" der Adresse, plus mindestens "Stadt", "Staat" und "Postleitzahl".
Nun erklärt Mr. Hay schnell in einer Fußnote:
Der Kontext des Modells bestimmt, ob dieses Attribut "Postleitzahl" oder "Postleitzahl" ist. Wenn die Kundenorganisation auf absehbare Zeit vollständig in den Vereinigten Staaten tätig sein wird, kann von einer neunstelligen, zweiteiligen numerischen „Postleitzahl“ ausgegangen werden. Wenn nicht, muss aus „Postleitzahl“ „Postleitzahl“ werden und es sind keine Formatierungsannahmen möglich.
Er erwähnt jedoch nicht, dass „Staat“ ein Staat in den USA, eine Provinz in Kanada oder ein nullable Attribut für fast jedes andere Land sein könnte, da „Staaten“ innerhalb von Ländern selten außerhalb der USA, Kanadas (wo sie werden Provinzen genannt, funktionieren aber ähnlich) und Australien. Natürlich haben andere Länder Provinzen und Regionen, aber diese werden selten als Teil einer Adresse verwendet.
Um zu veranschaulichen, wie ernst dieses Adressproblem sein kann, habe ich ein Datenmodell für amerikanische und nichtamerikanische Adressen erstellt. (Hinweis:Dies ist nicht das vollständige Modell.)
Das PrimaryPhone des US_Customer Tabelle speichert nur Telefonnummern mit zehn oder weniger Zeichen. Das internationale Design des Customer PrimaryPhone der Tabelle Das Attribut lässt eine Telefonnummer mit 15 Ziffern plus „+“ zu, was das von E.164 festgelegte Maximum ist.
Der TimeOffset -Attribut im US_Customer Die Tabelle lässt nur vier Zeitzonen zu:Eastern Time, Central Time, Mountain Time und Pacific Time (gespeichert im Datenmodell als:0 =Eastern, 1 =Central, 2 =Mountain, 3 =Pacific). Das deckt übrigens noch nicht einmal alle Zeitzonen in den USA und ihren Territorien ab. Im Gegensatz dazu die Timezone -Attribut im Customer Die Tabelle speichert den internationalen Code für die Zeitzone des Kunden, unabhängig davon, wo er sich befindet.
Als nächstes schauen wir uns die Postleitzahl an. Die USA erfordern eine 5-stellige Postleitzahl (Zip der US_Address Tabelle) plus die optionale ZIP+4 (Zip4 der US_Address Tisch). Die Address Tabelle hat einen flexibleren PostCode Feld. Abgesehen von der Länge gibt es keine Einschränkung für die Informationen, die in PostCode gespeichert werden können; Natürlich könnte die Anwendung Überprüfungen von Postleitzahlen implementieren.
Beachten Sie auch, dass sowohl das US- als auch das Nicht-US-Design ein Feld für Regionen innerhalb eines Landes haben (State in US_Address Tabelle und Region in der Address Tabelle), aber das US-Design erfordert, dass eine 2-stellige Staatsabkürzung enthalten ist. Beachten Sie auch, dass das US-Design keine internationalen Adressen akzeptiert, während die internationale Adressversion dies tut (daher der zweistellige ISO-Ländercode Land der Address Tabelle).
Hier ist der Punkt: Beschränken Sie Ihr Datenmodell von Adressen nicht auf einen Ort; genug Platz für verschiedene Stile lassen.
5. Formatierung von Datum und Uhrzeit
Datenmodelle sollten sich nicht mit mehreren Datums- und Zeitformaten befassen; die Anwendung übernimmt die eigentliche Anzeige. Dies kann auf verschiedene Weise geschehen:
- Der in Nordamerika und anderswo übliche Monatserststil:MM-TT-JJJJ
- Der Day-First-Stil, der in Europa häufiger vorkommt:dd-mm-yyyy
- Der Stil für das erste Jahr, der als ISO 8601-Datumsformat verwendet wird:yyyy-mm-dd
Hier ist der Punkt: Dies könnte sich wiederholen, aber wir sagen es noch einmal:Wählen Sie Ihre Datentypen beim Modellieren richtig aus. Dies erleichtert es dem Anwendungscode, gespeicherte Werte zu interpretieren und anzuzeigen.
Ein weiterer Punkt in dieser Kategorie könnte etwas unerwartet sein:an welchem Tag die Woche beginnt. Für einige ist dies Sonntag; für andere ist es Montag (und dann gibt es noch den persischen Kalender, der die Woche am Samstag beginnt).
Auch Zeiten müssen benutzerfreundlich dargestellt werden. Denken Sie daran, dass Ihr Datenmodell zwar nicht mehrere Zeitformate benötigt, Sie aber möglicherweise die Zeitpräferenz des Nutzers speichern , also das 12- oder 24-Stunden-Format.
Dies führt uns zu den Zeitzonen.
6. Zeitzonen
Es ist nicht ungewöhnlich, Apps zu finden, die Benutzern nur wenige Zeitzonen zur Auswahl bieten:Eastern Time, Central Time, Mountain Time und Pacific Time. Wenn ich das sehe, weiß ich, dass ich es mit einem Amero-zentrischen Anwendungsdesigner zu tun habe. Einige Designer lassen zu, dass eine Zeitzone als Offset von (normalerweise) GMT oder UTC ausgedrückt wird. Viele machen jedoch den Fehler, nur ganzzahlige Offsets zuzulassen, ohne zu erkennen, dass einige Länder (Indien, Iran, Pakistan, Afghanistan und andere) keine ganzzahligen Offsets sind. Sie unterscheiden sich geringfügig:India Standard Time ist UTC+5:30. Einige Standorte haben sogar einen kleineren Bruchteil-Offset, z. B. Nepal Standard Time – es ist UTC+05:45.
Vor einiger Zeit habe ich über ein Modell für eine Online-Umfragedatenbank geschrieben. Hier habe ich der Benutzertabelle eine Zeitzone hinzugefügt, damit wir Daten/Uhrzeiten in der Ortszeit der Benutzer anzeigen können.
Weitere Informationen zu Daten, Uhrzeiten und Zeitzonen finden Sie in der ISO 8601-Standarddarstellung von Datums- und Uhrzeitangaben oder in diesem Wikipedia-Artikel.
Hier ist der Punkt: Lernen Sie global zu denken, nicht nur lokal.
7. Mehrsprachige Unterstützung
Es gibt zahlreiche Fälle, in denen Ihre Anwendung mehrsprachige Unterstützung bieten muss. Aus Sicht des Datenmodells müssen Sie möglicherweise Informationen in mehreren Sprachen speichern. der Großteil der sprachlichen Handhabung sollte jedoch in Ihrer Bewerbung abgedeckt sein. Die Implementierung der mehrsprachigen Unterstützung würde den Rahmen dieses Artikels sprengen, aber wir haben sie bereits in diesem Blog besprochen.
Die Lokalisierung ist sehr wichtig und muss richtig gehandhabt werden. Wie wir bereits betont haben, bedeutet dies mehr als nur die Unterstützung verschiedener Sprachen; Es geht auch um die bevorzugten Formate für Datumsangaben, Uhrzeiten, Währungen und sogar Dezimalzahlen.
Datenmodellierung? Global denken
Berücksichtigen Sie beim Erstellen Ihres Datenmodells die potenzielle internationale Nutzung Ihrer Anwendung und ihrer Datenbank. Denken Sie während der Designphase global und vermeiden Sie später einige Probleme – ein Telefonnummernfeld, das nur 3-stellig + 3-stellig + 4-stellig akzeptiert, funktioniert gut in den USA, aber nicht so gut in China oder Indien.
Sind Ihre Datenbanken bereit, global zu werden? Ihr Ziel sollte es sein, Flexibilität zu ermöglichen, ohne überwältigende Komplexität zu schaffen.
