ケース スタディの例 - Teradata Database - Teradata Vantage NewSQL Engine

これから紹介する例は、Teradataのカスタマー サイトで実際に生じたケースです。この例では、ビジネス上の機密情報の開示を避けるためにわずかな変更が加えられていますが、基本的な構文や論点は元のまま残されています。

例のEXPLAINレポートには、分かりやすいように、サイト固有の別名を一般的なデータベース名に置き換えるというわずかな変更が加えられています。EXPLAINレポートが、現在のEXPLAINテキスト機能を表わしているわけではありません。これにより、教育ツールとしてのこのレポートの価値が下がるわけではありません。

ビジネス上の命題の定義

複雑な問合わせを作成するには、その前にビジネスで達成したい事柄について理解しておく必要があります。このケース スタディで求められているビジネス命題について、以下で簡単に説明します。

• 1,800万以上の行から成るcustomerテーブルにあるすべての顧客の顧客番号

  AND

  • 誰がdistrict Kに住んでいるか

    AND

  • service_typeがABCの顧客は誰か

    OR

  • service_typeがXYZの顧客は誰か

    AND

• 1997年7月のmonthly_revenueはいくらか(2億3,400万以上の行を含むrevenueテーブルを使用)

  AND

• 顧客のmonthly_revenueが分からない場合(つまり、収入に関する行が見つからない場合)は、null(疑問符(?)文字で表わされる)を指定した顧客番号をレポートして(customer.cust_numから)、monthly_revenueを表わします。

これは単純に聞こえるかもしれませんが、応答セットを注意深く分析すると、不正確であることが分かる場合があります。以下のトピックが示すとおり、結果は正しいですが、それを作成する外部結合の問合わせは適切に問合わせていません。このことは、その例の開発が進み、結果が分析されるにつれて、さらに明らかになります。

このスタディでは、このスタディの応答が適切かどうかを判別する2つの問合わせのサンプルと、正しい回答を得るまでに犯した3つの過ち、および最初に求めていた命題に対して正しい応答を返すために適切にコーディングした問合わせを示します。