9 - ユーザーの元データセットを確認する

📖 タスクの概要

フライトアラートと乗客の二つのオブジェクトタイプを作成し、リンクさせることを目指しています。最終的な目標は、アナリストがアクションを起こすためのアラートインボックスアプリケーションを作成し、可能であれば影響を受ける乗客に連絡を取ることです。そのために、ユーザーのデータパイプラインを見直し、ベストプラクティスに基づいて確認し、フライトアラートと乗客のデータセットをオントロジーオブジェクトタイプの元データセットとしてさらに準備するために何かできることがないかを決定しましょう。

🔨 タスクの説明

1. ユーザーの個人的な /Temporary Training Artifacts/${yourName} フォルダーに進む。
2. /Data Engineering Tutorials フォルダーを右クリックし、フライアウトメニューから データフローを探る を選択する。
3. 下部の Data Health ヘルパータブと、右側の Schedules パネルを開くことを検討する。下のクリック可能な画像に示されています。

このパイプラインでは、希望する結果を考えると、オントロジーオブジェクトを作成するための三つの候補データセットがあります：

• passengers_clean
• flight_alerts_clean
• flight_alerts_joined_passengers

以前のオントロジーデザインに関する議論で、データをプロパティまたはオブジェクトタイプとしてモデリングする基準を探索しました。フライトアラートには乗客データの集約（これが flight_alerts_joined_passengers を使用する場合）を含めるべきですか、それとも設定されたオントロジーリンクタイプを介してフライトアラートから乗客データにアクセスするべきですか？

データが集約ではなく単一の情報である場合、アラートと乗客情報を組み合わせることを考えるかもしれません。この場合、アラートと乗客の間には一対多の関係があるため、乗客データはアラートごとに集約されます。乗客データはフライトアラートについての主要なサポート情報でもありません。概念的には、乗客とフライトアラートは非常に異なるエンティティであり、検索の意味論と使用ケースが非常に異なります。

これらの理由から、元データセット間で共有されるキーによって可能になるリンクを介して、それらを別々のオブジェクトタイプとしてモデル化しましょう。