チェックポイント1、Steve Truckingのデータ設計を描いて弁護する

ほかに 28 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

オリジナルの、シナリオに基づく演習です。実際の試験問題をもとにしたことは一度もありません。「私ならこう設計する」のスタイルで書かれていて、大事なのは記号を選ぶことではなく、あなたの判断を見えるようにすることです。この課題はData Architectコースの第1部を締めくくります。私の解説はチェックポイント1にあるので、先に取り組んでください。

シナリオ

Steve Truckingはラストマイルの配送会社です。大型量販店の小売パートナー（Retail Partner）が家電、テレビ、家具を販売し、Steve Truckingの2人1組のクルーがそれを小売パートナーの顧客（受取人、Recipient）に届け、一部を設置し、古いものを引き取ります。Steve Truckingの概要資料（英語）のセクション1〜8を読んでください。セクション9（後からの変更）は置いておきましょう。 それはコースの最後に登場します。

要件

概要資料のセクション5（R1〜R15）とセクション6（S1〜S5）のすべてです。このチェックポイントで最も重要なのは次のものです。

R1. それぞれの小売パートナーの積荷目録を独自の形式（SFTPのファイル、API、EDI）で受け取り、打ち直すことなくルート、停車地、品目にする。
R3. それぞれの小売パートナーの物流センターの責任者は、ポータルで自分の配送、例外、写真、クレームを見ることができ、別のパートナーのものは決して見ない。
R4. 積荷目録は当日に修正される。ルートを組んだ後の変更に対応しなければならない。
S2. 小売パートナーは、別のパートナーの配送、価格、ボリューム、受取人を決して見てはならない。
S3. 受取人の追跡リンクは、アカウントなしでその一つの配送だけを表示し、期限切れになる。
S4. 受取人の住所、電話番号、配送メモは個人データである。クルーがそれを見られるのは自分の停車地について、その日だけ。

制約

営業日1日あたり約3,300件、年100万件の配送で、年30%の成長。配送1件あたり約1.6品目と8回のステータス変更。年400万〜500万枚の写真。1日約20万件のGPSの読み取り値。
米国に一つのSalesforce組織があり、すでにService Cloud、Field Service、パートナーポータルが動いている。MuleSoftはライセンス済み。Data 360はライセンス済みだが未実装。
3社の小売パートナー、3つの連携スタイル。9つの物流センター。

あなたの課題

第1部の設計を描いて弁護してください。第1〜6章で学んだことを使いましょう。

全体像（第4章）：Steve Truckingの現在のシステム全体像をスティーブのレイアウトで描く。すべての矢印に、何がどう動くかのラベルを付けること。
モデル（第2章）：配送の領域を、概念レベル、次に論理レベルでモデリングする。小売パートナー、物流センター、積荷目録、配送、品目、ルート、トラック、クルー、設置チェックリスト、写真、署名、例外、受取人。（課題D1）
物理設計（第3章）：そのうちどれが標準オブジェクト（Field Serviceには作業指示、サービス予定、サービスリソース、サービステリトリーがある）で、どれがカスタムか？　パートナーのユーザーと受取人にはどのライセンスが必要か？　それぞれの種類のデータはどこに置くか：組織の中、コアの外、ウェアハウス？
キー（この章）：小売パートナーの注文明細をあなたの配送に照合するのはどのキーか、そしてルートを組んだ後に積荷目録が修正されたら何が起きるか？　（課題D3）
受取人（この章）：取引先責任者か、個人取引先か、どちらでもないか？　関係、ボリューム、パートナーの分離、データのライフサイクルから論じること。
統合するかしないか（この章）：受取人は複数のパートナーの積荷目録に、ときには年に2回以上現れる。統合するか、それとも意図的にしないか？　S2を踏まえると、リスクは何か？　（課題DC1、後からの変更は除く）
権威： 5つの主要な項目（パートナーの注文番号、配送ステータス、受取人の電話番号、配送の時間帯、パートナーの正式名称）について、誰が作成し、誰が所有し、どのシステムが権威を持ち、誰が変えてよいかを言う。

それぞれの判断を、2つの選択肢とあなたの選択として書きましょう。「私の専門家としての意見では…」

議論

私の解説はチェックポイント1：Steve Trucking、私ならこう設計するです。箱だけでなく、考えた筋道を比べてください。違う選択をしたところでは、何を得て何を手放すことになるかを言えますか？

設計のレビュー

今は設計を手元に置いておきましょう。第2部でそれを、ボリューム、クエリ、連携、移行、トランザクション、セキュリティに照らして試し、第18章のレビューカードで3年目の時点でチェックします。

練習する試験目標

DM-1、DM-2（データモデルの設計、共有を尊重するモデル）
MDM-1、MDM-2、MDM-3、MDM-4（マスター管理、権威、照合、たどれること）
SDM-1（ライセンス）、SDM-3（単一ビュー、そしてそれを作らないべきとき）