グローバリゼーションとローカリゼーションの課題について、意味のある方法で言及しているデータベース作成者はほとんどいません。データベースアーキテクトからの同様の先見性の欠如があります。実際のところ、多くの作成者や設計者は非常に「自己中心的」であることがよくあります。ローカルのタイムゾーンや住所などを適切に処理するだけのデータモデルを作成（または記述）します。
自己中心的なアプローチには大きな問題があります。結果のモデルはローカルデータのみをサポートします。今日のインターネットを利用した世界では、世界中のユーザーがアプリケーションに予期せずアクセスすることがよくあります。私たちは、この国際的な聴衆のために可能な限り多くの柔軟性をサポートする必要があります。したがって、グローバル化されたアプローチでデータモデルを設計する必要があります。
私は幸運にも非常に多国籍で多言語の環境で働くことができるので、プロジェクトの開始時にグローバリゼーションの問題をどのように処理できるかを学びました。そのことを念頭に置いて、国際的な使用をサポートするデータモデルを作成するための7つの重要なポイントをまとめました。
1。数値の書式設定
数値の書式設定を検討する際には、ユーザーに表示される出力（つまり、書式）と基になるデータ型の2つを考慮する必要があります。
データモデルでの数値の表示方法について心配する必要はありません。データベースシステムが10進数の格納を処理し、アプリケーションは10進数の表示方法（「。」または「、」を10進数として）に調整する必要があります。たとえば、ポイント）。同様に、データモデルが使用する千単位の区切り文字（ピリオドやコンマなど）について心配する必要はありません。
要点は次のとおりです： モデリング時にデータ型を正しく選択してください。アプリケーションが出力フォーマットを処理する必要があります。
たとえば、気象観測所アプリケーションのこの単純なモデルでは、気象測定値（温度、湿度、降雨量）が浮動小数点数として格納されます。ただし、価格情報は10進数で、各気象観測所のGPS座標と同様です。
2。通貨と為替レート
通貨に関連する情報を保存する場合は、通貨ごとに正しい小数点以下の桁数を保存する必要があります。ほとんどの通貨には小数点以下2桁がありますが、小数点以下1桁（チリペソ）、1桁（マダガスカルアリアリ）、3桁（チュニジアディナール）、さらには小数点以下4桁（チリのユニダッドデフォメント、チリのユニダッドデフォメント、価格値の範囲。）
したがって、データモデルの「金額」フィールドが小数点以下2桁以上をサポートしていることを確認してください。小数点以下4桁は非常にまれですが、実際に発生します。小数点以下3桁がより一般的です。たとえば、6つの異なる国（バーレーン、イラク、ヨルダン、クウェート、リビア、チュニジア）のディナールと、1つの国（オマーン）のリアルには、小数点以下3桁が必要です。
ポイント番号1： モデリング時にデータ型を正しく選択してください。
通貨に関するもう一つの重要なポイントは為替レートです。これらはさらに高い精度を要求します。多くのシステムは、為替レートで4〜6桁の有効数字しか提供しません。値が大きく異なる通貨間にはスケーリング係数がある場合があります。ただし、有効数字4桁または6桁は、必ずしも小数点以下6桁になることを意味するわけではありません。インドネシアルピアとユーロの為替レートを確認してください：0.0000668755。これは、為替レートのフィールドに格納する小数点以下の桁数が多いです。
ポイント番号2： 為替レートに関しては、モデルで高レベルの精度（小数点以下の桁数が多い）を処理する必要がある場合があります。
以下に、価格のあるオンラインストアの例を作成しました。また、過去の為替レートを含む為替レートを格納する簡単なテーブル（水色で強調表示）を追加しました。 exchange_rate テーブルは通貨にリンクされています（currency_id 、これはISO 4217通貨コードです）。特定の日に通貨ごとに1つの為替レートを保存できます（rate_date ）、通貨ごとに1つのアクティブな為替レートがあります。
もちろん、このレート表を使用するには、いくつかの追加情報が必要です。たとえば、これらの為替レートはどの基本通貨に対して定義されていますか？ユーロまたは米ドルが一般的かもしれませんが、アプリケーションにはここで正確な情報が必要になります。
あるいは、より複雑なモデルでは、通貨ペア、中間レート（または銀行レート）、およびそれらの通貨ペア間の「購入」レートと「販売」レートを格納できます。
ポイント番号3： アプリケーションがデータを適切に使用できるように、モデルには十分な情報が必要です。
3。電話番号
北米の10桁の電話番号と、3桁の市外局番、3桁の交換機、および4桁の加入者番号（012-345-6789）のみをサポートするシステムをよく目にします。このバイアスはある程度理解できます。人々はローカルユーザーをサポートするシステムを作成します。ただし、データモデリングでは、グローバルユーザーがシステムにアクセスする可能性を無視してはなりません。 （注：10桁の長さは、フランスの携帯電話などの他の番号にも使用できますが、形式は異なります（つまり、06 12 34 56 78）。）
これを例として取り上げましょう。私がフランスの国境のすぐ外に住んでいるが、フランスで働いているとします。したがって、フランスのアプリケーションとサービスプロバイダーを使用する必要があるかもしれませんが、私の携帯電話番号はフランスの番号ではありません。 06または07で始まる10桁の携帯電話番号を必要とするシステムは、私には機能しません。フランスの鉄道の切符を手に入れたり、フランスでのコンサートの切符を購入したりするために（など）、私はフランスの電話番号を取得することを余儀なくされました。控えめに言っても面倒です。
要点は次のとおりです： 電話番号の制約がデータモデルに組み込まれている場合、データモデルの変更が必要になります 非ローカルユーザーをサポートします。理想的には、すべての不測の事態に対処するために十分な柔軟性をモデルに組み込む必要があります。
より論理的なデータモデルは、さまざまな長さの電話番号（一部の地域では最大16桁）と数字以外の文字（国際電話番号のユニバーサル「+」記号など）をサポートします。確かに、一部のアプリケーションは、ローカル開発者がよく知っている「ローカルルール」を実装することで、より多くの検証を実行できます。他のアプリは、電話番号に基づいて住所を確認または取得するなど、ローカルの電話番号を使用して他のデータソースにアクセスする場合があります。
データモデルは、情報を保存する際の柔軟性をサポートする必要があります。アプリケーションまたはそのUIは、より制限されたり、追加の検証を実行したりできます。
4。住所
海外に住むアメリカ人として、私はデータモデルの例やパターンがアメロ中心すぎることに気付くことがよくあります。たとえば、非アメリカ人は Zip + 4が何であるかを理解していない可能性があります したがって、このドメインにはNOTNULL特性が必要であると作成者が述べている理由がわかりません。
このアメロ中心の見方は、本にも見られます。たとえば、非常に広範な本「データモデルパターン」を取り上げます。デビッドC.ヘイによる「思考の慣習」。ヘイ氏の住所、場所、地理的位置、土地区画、地理的構造要素に関する非常に複雑な説明には、カナダの例が含まれていましたが、それでも、この情報を誰もが簡単に把握できるとは限りません。
ヘイ氏のパターンによると、住所の属性には次のものが含まれます。
住所の「テキスト」に加えて、少なくとも「市」、「州」、「郵便番号」。
さて、ヘイ氏は脚注で次のようにすばやく説明します。
モデルのコンテキストによって、この属性が「郵便番号」か「郵便番号」かが決まります。クライアント組織が当面の間完全に米国内で運営される場合、9桁の2つの部分からなる数値の「ZIPコード」を想定することができます。そうでない場合、「郵便番号」は「郵便番号」になる必要があり、フォーマットを想定することはできません。
ただし、国の「州」が米国外に存在することはめったにないため、「州」は米国の州、カナダの州、または他のほとんどの国のnull許容属性である可能性があることについては言及していません。州と呼ばれますが、同様に機能します）およびオーストラリア。確かに、他の国には州や地域がありますが、これらが住所の一部として使用されることはめったにありません。
この住所の問題がどれほど深刻であるかを説明するために、私はアメリカ人と非アメリカ人の両方の住所のデータモデルを作成しました。 （注：これは完全なモデルではありません。）
PrimaryPhone US_Customer テーブルには、10文字以下の電話番号のみが格納されます。 Customer テーブルのPrimaryPhone 属性は、15桁の電話番号にE.164で指定された最大値である「+」を加えたものを許可します。
TimeOffset US_Customer テーブルでは、東部時間、中央時間、山岳時間、太平洋時間の4つのタイムゾーンのみが許可されます（データモデルに0 =東部、1 =中央、2 =山、3 =太平洋として格納されます）。ちなみに、これは米国とその領土のすべてのタイムゾーンをカバーしているわけではありません。対照的に、Timezone Customer テーブルには、場所に関係なく、顧客のタイムゾーンの国際コードが格納されます。
次に、郵便番号/郵便番号を見てみましょう。米国では5桁の郵便番号（Zip）が必要です US_Address 表）に加えて、オプションのZIP + 4（Zip4 US_Address テーブル）。 Address テーブルには、より柔軟なPostCodeがあります 分野。長さを除けば、PostCodeに保存できる情報に制約はありません。;もちろん、アプリケーションは郵便番号のチェックを実装できます。
米国と米国以外のデザインの両方に、国内の地域（State）のフィールドがあることにも注意してください。 US_Address テーブルとRegion Address 表）、ただし、米国の設計では、2文字の州の略語を含める必要があります。また、米国のデザインは国際アドレスを受け入れませんが、国際アドレスバージョンは受け入れます（したがって、2文字のISO国コードAddress 表）。
要点は次のとおりです： アドレスのデータモデルを1つの地域に限定しないでください。さまざまなスタイルに十分なスペースを残してください。
5。日付と時刻のフォーマット
データモデルは、複数の日付と時刻の形式に関係するべきではありません。アプリケーションが実際の表示を処理します。これはさまざまな方法で実行できます：
- 北米やその他の地域で一般的な月初のスタイル： mm-dd-yyyy
- ヨーロッパでより一般的な初日スタイル： dd-mm-yyyy
- ISO 8601の日付形式として使用される年初のスタイル： yyyy-mm-dd
要点は次のとおりです： これは繰り返される可能性がありますが、もう一度言います。モデリング時にデータ型を正しく選択してください。これにより、アプリケーションコードが保存された値を解釈して表示しやすくなります。
このカテゴリの別の項目は、少し予想外のことかもしれません。週が何日から始まるかです。一部の人にとっては、これは日曜日です。他の人にとっては、月曜日です（そして、土曜日に週が始まるペルシャ暦があります）。
時間もユーザーフレンドリーな方法で表示する必要があります。データモデルには複数の時間形式は必要ありませんが、ユーザーの時間設定を保存する場合があることに注意してください。 つまり、12時間形式または24時間形式です。
これにより、タイムゾーンが表示されます。
6。タイムゾーン
東部標準時、中央時間、山岳時間、太平洋標準時のいくつかのタイムゾーンの選択肢しかユーザーに許可しないアプリを見つけることは珍しいことではありません。それを見ると、私はAmero中心のアプリケーションデザイナーを扱っていることがわかります。一部の設計者は、タイムゾーンを（通常）GMTまたはUTCからのオフセットとして表現することを許可しています。ただし、一部の国（インド、イラン、パキスタン、アフガニスタンなど）が整数オフセットではないことに気づかずに、整数オフセットのみを許可するという間違いを犯す人も少なくありません。それらはわずかに異なります。インド標準時はUTC+5：30です。ネパール標準時（UTC + 05：45）など、一部の場所では分数オフセットが小さくなっています。
少し前に、私はオンライン調査データベースのモデルについて書きました。ここでは、ユーザーの現地時間で日付/時刻を表示できるように、ユーザーテーブルにタイムゾーンを追加しました。
日付、時刻、タイムゾーンの詳細については、日付と時刻のISO8601標準表現またはこのウィキペディアの記事を参照してください。
要点は次のとおりです： ローカルだけでなく、グローバルに考えることを学びましょう。
7。多言語サポート
アプリケーションが多言語サポートを提供する必要がある場合が何度もあります。データモデルの観点からは、情報を複数の言語で保存する必要がある場合があります。ただし、ほとんどの言語処理はアプリケーションでカバーする必要があります。多言語サポートの実装はこの記事の範囲を超えていますが、このブログですでに説明しています。
ローカリゼーションは非常に重要であり、適切に処理する必要があります。すでに指摘したように、これは単に多様な言語をサポートするだけではありません。また、日付、時刻、通貨、さらには小数インジケーターの推奨フォーマットについても説明します。
データモデリング？グローバルに考える
データモデルを作成するときは、アプリケーションとそのデータベースの潜在的な国際的な使用法を考慮してください。設計段階でグローバルに考えれば、後でいくつかの問題を回避できます。3桁+3桁+4桁のみを受け入れる電話番号フィールドは、米国では正常に機能しますが、中国やインドではうまく機能しません。
データベースはグローバル化する準備ができていますか？目標は、圧倒的な複雑さを生み出すことなく柔軟性を実現することです。