進化する連絡先情報はデータベースを変更することを意味しますか？

最近誰かに連絡する方法はたくさんありますよね？

さまざまな電話があります：携帯電話と固定電話、個人用と仕事用。私たちはさまざまな住所（住宅、郵送、請求、ビジネスなど）を持っており、おそらくいくつかの電子メールアドレスもあります。 Skypeやさまざまなメッセージングアプリを忘れないでください。次に、LinkedInとFacebookを追加します。ちなみに、どちらにも独自のメッセージング要素があります。

それほど昔のことではありませんが、これらの多くは存在していませんでした。したがって、数年以内に、人々や組織に連絡するための新しい方法が提供されることをほぼ保証できます。

「最新のもの」が登場したときにデータベース設計を変更する必要がないように、このすべての連絡先情報をモデル化できますか？読んで調べてください…

パーティコンタクトポイントモデル

一言で言えば、そうです。データベースは、まだ持っていない情報に対応できるように設計できます。

すぐに飛び込んで解決策を示してから、これらの要素がどのように連携するかを説明します。関係者に連絡するさまざまな方法を連絡先と呼びます 、連絡方法を見たことがありますが さらに連絡先 使用済み。

物理的には、これらすべての連絡先は1つのテーブル列contact_point.contact_valueに保存されます。 。電話番号、メールアドレス、またはWebアドレス（URL）を考えれば、それらすべてをここに保存できる理由がわかります。このレベルでは、これらは単なる文字列（varchars）です。違いはメタデータにあります。これに対する唯一の例外は住所です。これについては後で詳しく説明します。

左側の黄色のテーブルにはメタデータが含まれ、右側の青いテーブルにはビジネスデータが含まれています。

主なカテゴリ

誰かに連絡する方法はたくさんありますが、これらの方法は実際には少数のカテゴリまたはタイプに分類されます。以下のリストを見ると、私が何を意味しているのかがわかります。

ある意味で、これらは物理的に異なります。もちろん、携帯電話を使って固定電話や別の携帯電話に電話をかけることもできます。固定電話と携帯電話の間の音声通話に関しては、区別はそれほど重要ではありません。それでも、固定電話よりも携帯電話にテキスト（SMS）を送信する可能性が高くなります。

ただし、意図的にファックス番号に音声通話をかけることはほとんどありません。結局のところ、「おっと、間違った番号」を除いて、それを聞いたときにあなたはそれに何を言うつもりですか？当然のことながら、物理的であろうとエミュレートされていようと、別のファックス機で電話をかける可能性がはるかに高くなります。固定電話に手紙を送ったり、住所に音声通話をかけたりしないでください。

これらのタイプとの相互作用は異なるため、これらのタイプを区別することが重要です。これは、アプリケーションに通信サービスと何らかの統合がある場合に特に当てはまります。対話するタイプを知る必要があります。

当事者が連絡先を使用する方法

これはおそらくもう少し直感的で、連絡先の種類についての考え方と一致しています。これらのタイプの感触をつかむのに役立つ、より長いリスト（ただし、網羅的なものではありません！）を次に示します。

住所–特別な場合

住所を除いて、これらの連絡先タイプはすべて1つのフィールドに保存されます。これには通常、複数の行（またはフィールド）が必要です。

住所を保存するためのシンプルで言語に依存しない方法を提案するブログ記事がここにあります。要件がかなり基本的な場合-例：システムに入力されたとおりに住所ラベルを印刷するには、このアプローチで十分です。ニーズがより洗練されている場合は、おそらく別のソリューションを開発する必要があります。

アドレス指定がどれほど複雑になる可能性があるかを理解するには、英国標準BS7666アドレスタイプのこのスキーマをざっと見てください。この規格は、Street Gazetteers、Land and Property Gazetteers、および配達ポイントをカバーするいくつかのパーツで構成されています。商業用不動産と住宅用不動産を区別しません。占領地、開発地、または空き地の間。都市部または農村部の間;または郵便で住所を指定できるエンティティと郵便で住所を指定できないエンティティの間 ■通信マスト（タワー）など。これを実現するために、別のアドレス指定可能なオブジェクトを参照せずにアドレス指定できるアドレス指定可能なオブジェクトに付けられた名前であるPrimary Addressable Object（PAO）など、私たちのほとんどがおそらくなじみのない用語を紹介します。 PAOのよく知られた例には、建物名や番地などがあります。セカンダリアドレス可能オブジェクト（SAO）は、PAOを参照してアドレス指定されるアドレス可能オブジェクトに与えられます。これは、名前の付いた建物の1階である可能性があります。

これを視覚化するために、UMLモデリングツールにすばやくリバースエンジニアリングしました。取得できるものは次のとおりです。

私のポイントは、それがかなり複雑で厄介になる可能性があるということです。一部のドメインでのアドレス指定は、実際には非常に複雑になる可能性があります。

これを1つのリレーショナルテーブルにフラット化すると、次のようになります。

これはBS7666アドレスコンポーネントをキャプチャしますが、モデルがどのように機能するかはわかりません。 XMLスキーマのすべてのリレーショナルロジックは、アプリケーションロジックに隠されています。

これらの2つの図は、2つのデータモデリングの極値を表しています。 。しかし、アドレスをモデル化するための中間的な方法はありますか？

柔軟で構成可能な比較的単純なアドレスモデルを持つことは確かに可能です。

アドレスコンポーネント

住所コンポーネントは通常、住所ラベル上の行、または行の種類 住所ラベルに。英国の住所に通常使用するコンポーネントの種類を次の表に示します。

3つまたは4つの住所行に加えて、ポストタウンと郵便番号を設定できます。ただし、遭遇する困難は、これらの行に実際に含まれているものを特定することです。 重要な場合-例：システム間でデータをマッピングする場合。データプロファイリングを実行すると、住所行3に依存する地域が含まれる場合もあれば、郡または地域が含まれる場合もあります。これで、自然言語処理（NLP）に興味があります。 違いを認識する必要があります 地方と郡の間。そして、国を追加すると順列が増えます。

したがって、事業を行うすべての国のすべての住所コンポーネントを定義する必要があります。

アドレス形式

アドレス形式は、ヘッダーとその詳細の2つの部分で構成されています。ヘッダーは基本的に、アドレス形式の名前またはタイトルです。 によって知られています。例としては、次のものがあります。

例として英国の完全な郵便局住所形式（PAF）を取り上げ、次の住所形式コンポーネントを定義します。

アプリケーションはこのメタデータを読み取り、アドレスコンポーネントを正しい順序で表示します。アドレスキャプチャが必要な場合、メタデータはアドレスコンポーネントが必須かどうかを示します。

多くの場合、アプリケーションはエンドユーザーに郵便番号を要求し、対応する値を検索して、住所コンポーネントに自動的に入力します。一部のアプリケーションでは、ユーザーがアドレスを編集できます。他の[迷惑な]ものはしません！

PDMには表示されませんが、組織が国際的に運営されている場合は、address_format_type間に多対多の関係を定義できます。 およびcountry 正しい住所形式（ユーザーの国に基づく）がエンドユーザー（party）に提示されるようにします 。

contact_pointの場合のみ 住所はcontact_point_type 、address_format_typeとの関係が必要です。逆に、郵便以外の住所タイプは決してないということになります。 address_format_typeと関係があります 。さらに、フォーマットは固定されたままである必要があります contact_pointの存続期間中 、それ以外の場合は、データの整合性の問題が発生する可能性があります。 （このそうではない 、ターゲットのaddress_format_components ソースのaddress_format_componentsのサブセットである必要があります 。

列contact_value 値はddress_line.line_contentに保存されているため、住所には意味がありません。 。逆に、contact_value 他のすべてのcontact_point_typesには必須です 。基本的に、contact_point.contact_value およびaddress_line.line_content 相互に排他的です。

当事者と連絡先の間の多対多の関係

あなたはcontact_pointについて考えることができます （さらにaddress_line ）値とparty_contactを含むものとして 使用法を定義するものとして。これにより、単一のcontact_pointが可能になります 複数回使用する 。状況によっては、自宅の[郵便]住所が請求先住所と配送先住所になる場合もあります。

これまでのところ、物語は、当事者が特定のcontact_pointを所有していることを前提としています。 。 ただし、データモデルはこの所有権ルールを課していません！ そのような制限は一切ありません。この設計には別の可能性があります。同じ連絡先に対して複数の関係者がいることです。

このルートを進む前に、その影響を慎重に検討する必要があります。

これが例です。英国では、授与機関（AO）は通常、教師を試験官として雇用しています。教師には2つの関係があります。1つは彼または彼女が働いている学校との関係であり、もう1つは試験官としてのAOとの関係です。学校にはcontact_pointsの銀行があります さまざまな電話番号と、場合によっては1つ以上の住所が含まれます。これらは、学校のメインアドレス（郵​​便アドレス）、メインメール（メールアドレス）、メインファックス（ファックス番号）、メイン電話（電話番号）などになります。

審査官がまったく同じcontact_pointsを使用できることは完全に実現可能です。 彼または彼女の学校として、しかし彼または彼女はparty_contactを使用します それらを仕事関連として定義します。学校のメインの電話番号が変更されると、教師の勤務先番号が自動的に更新されます。これは非常に便利です。

このルートをたどる場合は、アプリケーションレベルで定義する必要があります。 contact_pointsの更新が許可されている当事者 。

パフォーマンスに関する簡単な説明

黄色のメタデータテーブルは、クエリによって常に使用されます。その結果、それらはメモリに残る可能性があります。ほとんどのRDBMSでは、これを確実にするためにテーブルをメモリに固定できます。 Oracleでは、これらをインデックス編成のテーブルとして作成します。これらのテーブルは小さく、パフォーマンスが優れています。 RDBMSに相当するものは何でもしてください。

また、party_contact 行は、party_idのクラスター化インデックスを使用して、同じブロック（またはページ）に同じ場所に配置されます 。 address_line.contact_point_idでも同じようにします 。これにより、IOの量が削減されます。

partyが必要な場合は、別のオプションがあります contact_pointを独占的に所有する 。その後、contact_pointをマージできます party_contactに party_contact_pointを作成するには （まだparty_idにクラスター化されています ）。これによりモデルが簡素化され、パフォーマンスが向上する可能性があります。

連絡先の変更はデータベースの変更を意味しません

私たちは変化が唯一の不変であると言える時代に生きています。

これは、何かが変更されるたびにデータベースに影響を与える必要があるという意味ではありません。少し考えれば、将来を見据えた設計が可能になります。おそらく、これまでよりも多くのことが可能になります。そうすることで、避けられない変化に迅速に対応することができます。

グリーンフィールドプロジェクトに着手する場合は、組織や人々にパーティモデル（コンタクトポイントが含まれている）を使用することをお勧めします。モデルを開いて、ニーズに合わせて調整してみませんか？お気軽にコピーを入手して、自分のものにしてください。

ただし、1つまたは複数のデータベースがすでに決定されている場合でも、ここで示したスキーマをXML形式で使用して、システム間でデータを統合するときにペイロードを定義できます。