ダニエル・ヴァレンテ、PhD、JMP シニア プロダクト マネージャー、SAS
ジョン・ワイズ、SAS JMP セールス＆マーケティング担当副社長
抽象的な
JMP 13 では、アナリストが一般的なデータの問題に簡単に対処できるようにする 2 つの新しいツールが導入されています。多くの場合、2 つ以上のデータ テーブルは共通のキーによって関連付けられていますが、ファクト サンプリングの頻度やディメンション (長さと幅など) の点で大きく異なります。これらの 2 つ (またはそれ以上) のテーブルを実際に結合すると、結果として作成されるテーブルがメモリ内で非常に大きくなる可能性があります。ファクト テーブルとディメンション テーブルが比較的コンパクトな場合は厄介ですが、メモリに収まらないほど大きな結合テーブルがすぐに生成される可能性があります。解決策は、仮想結合を使用することです。仮想結合では、結合テーブルを実際に作成せずに結合関係が保持されるため、ファクト テーブルに負担をかけずに効果的に強化できます。アナリストは、データベース内で複雑なテーブル結合や要約を行ったり、SQL を記述したりする必要があることがよくあります。これは、特にディメンションが徐々に変化するなどの複雑な関係がある場合に、独自の苦労を伴います。JMP クエリ ビルダーは、SQL を簡単に生成および記述できるツールとして機能し、そのコードをデータベースで実行できます。正しい望ましいクエリをドラッグ アンド ドロップすると、クエリ ビルダーによって SQL コードが自動的に記述されるため、面倒でエラーが発生しやすい手作業が不要になります。
リレーショナル テーブル構造の概要
アナリストは、列に変数、行に観測値がある形式のデータを必要とします。データには、観測値を明確にサブグループ分けするカテゴリ列 (所得レベル、国、マシンなど) も必要になる場合があります。また、データには、観測値をさらに明確にする属性 (住所、シリアル番号、顧客 ID など) が含まれる場合もあります。
多くの場合、このような分析のソース データは、データベースに保存されているリレーショナル データ構造です。データ サイエンスの最近の多くの学習コースでは、リレーショナル データ構造、データベース、SQL に関連するトピックが取り上げられています。しかし、ほとんどのエンジニア、科学者、統計学者は、学術的な環境でこれらのトピックに触れることがないため、継続的な非公式教育の一環としてこれらについて学ぶ必要があります。JMP クエリー ビルダーは、アナリストにリレーショナル データ構造と分析可能なデータをつなぐ橋渡しを提供します。アナリストは、いくつかの用語と概念を学習することで、クエリー ビルダーを使用して分析可能なデータを生成できます。
このホワイト ペーパーでのリレーショナル データ構造に関する簡単な説明は、このトピックの徹底的な研究に代わるものではなく、JMP のクエリ ビルダーとその仮想結合機能を使用するときに使用する用語と定義を紹介することを目的としています。
重要なデータを格納するために複数のテーブルが必要なのはなぜですか?
自社の製品を顧客が購入した際のデータを保存する方法を考えてみましょう。まず、収集する必要がある可能性のあるすべての変数をリストアップすることから始めます。たとえば、次のような変数です。
- 購入日
- 購入金額
- 購入方法（POまたはCC）
- 製品SKU
- 製品説明
- 顧客名
- 顧客住所
- 顧客電話番号
これは確かに包括的なリストではありませんが、良いスタートになります。次に、これらのデータの維持について考えてみましょう。このテーブルには、購入ごとに 8 つの列と 1 つの行があります。購入金額や購入日など、一部のフィールドには多くの異なる値が含まれる場合があります。製品 SKU や説明など、他のフィールドには、はるかに少ない異なる値と多くの重複値が含まれます。
テーブルのサイズを縮小する一般的な方法は、テーブルを 3 つの論理グループに分割することです。最初のテーブルには、購入日や購入金額などのトランザクションまたはファクトが含まれます。2 番目のテーブルには顧客情報が含まれ、3 番目のテーブルには製品情報が含まれます。データ列間のリンクを維持するには、3 つのテーブルを関連付けるためのリンク情報を含む列を追加する必要があります。これらの列はキーと呼ばれます。このレイアウトを示す一般的な方法は、エンティティ リレーションシップ ダイアグラム (ER)を使用することです。各エンティティには、テーブル名、各行を一意に識別するキーまたはキー セット、および各行に関する情報を提供する属性または変数のセットがあります。顧客購入日の ER 図を図 1 に示します。
図1. 顧客購入データのエンティティ関係図
顧客ディメンション テーブルの顧客 ID の横にあるキー シンボルは、顧客 ID がわかっている場合、テーブル内でその顧客とそれに関連するすべての情報を一意に見つけることができることを意味します。顧客 ID は購入ファクト テーブルにもあります。顧客 ID は購入ファクト テーブルにあるときは外部キーと呼ばれます。これは、顧客 ID が何度も出現し、外部テーブルの行を出現する行と一意に定義するためです。
図 1 のレイアウトでは、製品の説明を更新する方法が非常に簡単にわかります。これを行うには、製品ディメンション テーブルを編集するだけで、その 1 つの変更がこれまでに行ったすべての購入に適用されます。これは、保守性と呼ばれる利点です。製品の説明が何度も繰り返される 1 つのテーブルの場合、多くの行を編集する必要があり、間違いやデータ品質の問題につながることは避けられません。
事例1：現在の人口調査
それでは、クエリ ビルダーの例を見てみましょう。米国政府は、Current Population Survey (CPS)[USGCPS] で多くの興味深いデータを収集しています。CPS は次のとおりです。
“人口動態調査 (CPS) は、米国で最も古く、規模が大きく、最もよく知られている調査の 1 つです。この調査は、個人として、また社会として私たちを定義づける多くの事柄、つまり仕事、収入、教育に関する情報を提供するため、非常に重要なものです。毎月の労働力統計の主な情報源であることに加えて、CPS は国民の経済的および社会的幸福について国民に情報を提供するさまざまな他の調査のデータ収集にも使用されます。これは、毎月の基本的な CPS 質問に補足質問を追加することによって行われます。補足質問は月ごとに異なり、養育費、ボランティア活動、健康保険の適用範囲、学校の入学など、さまざまなトピックをカバーします。補足調査は通常、年 1 回または 2 年に 1 回実施されますが、補足調査の頻度と繰り返しは、補足調査のスポンサーのニーズに最も合うものによって完全に異なります。」
これらのデータは 36 個のテキスト ファイルとしてダウンロードできます。ファイルはタブ区切りのテキスト ファイルなので、JMP で簡単に開くことができます。JMP テーブルを見ると、クエリ ビルダーでの作業に役立つ ER 図 (図 2) が作成されました。
図 2. CPS 労働力統計データ表の ER 図
クエリ ビルダーを使用するには、プライマリ テーブル (ファクト) とセカンダリ テーブル (ディメンション) を定義する必要があります。
CPSデータのファクトテーブルはすべてのデータ.jmpテーブルには500万行以上ありますが、列は5つしかありません。列には「series_id」、日付、および「value」列があります。データを理解するには、シリーズID.jmp 図2のER図は、「series_id」がシリーズ.jmpテーブル。次に、JMP で両方のテーブルを開き、クエリ ビルダーを使用して結合を定義します。
JMPで、すべてのデータ.jmpプライマリ（ファクト）テーブルとしてシリーズ.jmpセカンダリ (ディメンション) テーブルとして (図 3) に入力します。JMP は自動的に適合するキーを探して結合を設定しますが、シリーズ テーブルの右側にあるベン図をクリックして確認する必要があります。クエリ ビルダーは両方のテーブルで「footnote_codes」を見つけましたが、これらをキーとして結合するのではなく、「series_id」のみを結合したいので、そのキー関係を削除する必要があります。
図3. 結合のためのクエリビルダーすべてのデータ.jmpそしてシリーズ.jmp
次に、結合されたテーブルの列を定義する必要があります（図4）。これを行うには、すべてのデータ.jmp左上の「series_id」をクリックして、そのテーブルから必要な列を選択します。結果のテーブルではそのキーは必要ないので、ここで「series_id」を削除します（シリーズとデータ.jmp）。
図4. 結合するクエリビルダーシリーズとデータ.jmp皆様へ_コード.jmp” テーブル
注意してくださいシリーズとデータ.jmpの約5倍の大きさですすべてのデータ.jmpテーブル。この膨張は、すべての「_code」フィールドの値が重複しているためです。したがって、36のテーブルにデータを格納することで、ストレージ要件が大幅に削減されます。次に、シリーズとデータ.jmp プライマリテーブルとして、そしてすべての「_code.jmp” テーブルをセカンダリテーブルとして使用します (図 5)。
図5. すべての「_コード.jmp”
キー変数は不要になったため、「_code」テーブルの「_text」フィールドのみを使用してクエリを作成します。JMPの「列」>「列ビューア」を使用すると、テーブル内の現在42列の概要を簡単に取得できます。完全な join.jmp。それでも570万行は残ります。これはすべてのデータ.jmpですが、今ではデータを説明するテキストフィールドがあります。テーブルが完全な join.jmpテーブルの6倍の大きさですAllData.jmp、これで分析に役立つ表ができました。
グラフビルダーを使用して、製造業の失業傾向をプロットします。完全な join.jmp図 6 では、不況時のこの部門の混乱が赤いトレンド ラインで示されています。2016 年の失業率は 2006 ～ 2007 年の水準に戻っています。緑のトレンド ラインは、自動車製造部門の雇用レベルを示しています。2010 年から 2015 年にかけて、自動車製造部門の雇用が 30 万件以上増加しました。
図6. CPS労働力統計データを表示するグラフビルダー
事例2: レストラン検査データ
このケースでは、仮想結合とJMPクエリビルダーを使用して、DOHMHニューヨーク市レストラン検査結果を分析します。[ドーハム]自分が新人検査官として現場に赴き、過去のデータを調べて何が明らかになるかを見ているところを想像してみてください。ウェブサイトからhttps://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59、これらのデータの .csv バージョンをダウンロードして、JMP で簡単に開くことができます。2016 年 7 月 17 日の完全ダウンロードでは、448,149 件のレコードを含む 163.3 MB のファイルが生成されます。
これらのデータには、検査イベントの M/D/Y である INSPECTION DATE 列があります。これらのデータに何年分含まれているかを確認するには、右クリックして、新しい数式列 > 日時 > 年を使用します。これを連続から名目に変換し、分析 > 分布を実行すると、図 7 のように表示されます。レベル 1900 は、おそらく欠損データのコードであり、対処する必要があります。これらのデータを破壊的に編集しても問題ありません (ここでは JMP がサンドボックスとして使用されており、実際のデータは常にサーバー上に保存されているため)。次に、再コード化ユーティリティを使用して、これらのレベルを欠損に変更します。
図7. 完全なデータセットの検査日
再コード化ウィンドウには、01/01/1900 のレコードが 1,151 件あります。この古い値を • に変更するには、文字列を削除し、[完了] -> [インプレース] をクリックします。[レコード日付] はデータが取得された日付であり、この分析には関係がないため、列を削除します。
この論文は仮想結合とクエリ ビルダーに関するものなので、なぜ非正規化テーブルを見ているのか不思議に思われるかもしれません。これらのデータを正規化できる可能性があります。これらの生データには、個々のレストランのジオコードされた場所が特に欠けていますが、これは後で JMP アドインを使用して実行できます。このプロセスは計算コストが高いため、これらのデータで複数の検査が行われる可能性がある一意の場所のみをジオコードするのが理にかなっています。さらに、一意の検査よりもはるかに少ない違反の追加テーブルを作成することもできます。
データを分割する前に、これらのデータのサンプルを取得して、探索演習で数値を管理しやすくします。
サンプリングはクエリービルダーで簡単に実行できます。テーブル > JMPクエリービルダーを選択すると起動ダイアログが表示されます。この場合は結合を実行していないため、DOHMH_New_York_City_Restaurant_Inspection_Results.jmpこの時点では、セカンダリ テーブルのないプライマリ テーブルとして表示されます。クエリ ビルダーには、[サンプル] タブがあります。[この結果セットをサンプルする] チェック ボックスをオンにすると、[最初のN行] または [ランダムN行] を選択できます。これらのデータの 10 パーセントをランダムにサンプルするため、[ランダムN行] には 44,815 を入力します。すべての列を [含める列] セクションに追加し、SQL を調べます。クエリ ビルダーによって、このクエリを実行するための SQL が自動的に生成されます。
t1.CAMIS、t1.DBA、t1.BORO、t1.BUILDINGを選択します。
t1.STREET、t1.ZIPCODE、t1.PHONE、t1."料理の説明",
t1."検査日", t1."処置", t1."違反コード", t1."違反内容",
t1."CRITICAL FLAG"、t1.SCORE、t1.GRADE、t1."GRADE DATE"、
t1."検査種別", t1."年[検査日]"
DOHMH_New_York_City_Restaurant_Inspection_Results より t1
ORDER BY RANDOM() 制限 44815;
使用後ランダムに並べ替え () 関数をサンプリングに使用すると、このクエリは適切なデータのサブセットを生成します。これをサブセットとして保存し、レストランの人口統計と違反コードを分割します。ここでもクエリ ビルダーを使用できます。違反コードから始めます。ここでも、必要なのはプライマリ テーブルだけです。VIOLATION CODE と VIOLATION DESCRIPTION を変数リストにドラッグ アンド ドロップし、VIOLATION CODE をもう一度ドラッグすると、カウントで集計して、必要なプロパティを持つテーブルを生成できます。集計列の JMP 名を VIOLATION COUNT に変更します。列または派生列に別名を生成するこの機能は、クエリ ビルダーの強力な機能です。また、VIOLATION COUNT を Order By ロールにドラッグすると、新しく作成された集計列で自動的に並べ替えるように選択できます (図 8 を参照)。
図 8. 集計列の名前を「違反数」に変更し、「順序付け」プロパティを設定
88 個の一意の違反コードのみであるため、この結果のクエリははるかにコンパクトです。このテーブルにD-ViolationCodes.jmp という名前を付けたら、グラフ ビルダーを使用して、どのコードに最も多くのレコードがあるかを調べます。VIOLATION DESCRIPTION を X 軸にドラッグし、VIOLATION COUNT を Y 軸にドラッグします。次に、VIOLATION DESCRIPTION を右クリックし、VIOLATION COUNT (降順) で並べ替えます。上位のカテゴリのみに焦点を絞るには、2,500 を超える一意のレコードがある違反カテゴリで、VIOLATION COUNT のローカル データ フィルターを使用します (図 9)。
図 9. 違反件数上位 (サンプル テーブル内の一意のレコードが 2500 件を超える)
今は違反テーブルから離れて、レストラン固有の人口統計に焦点を当てることができます。この時点で、違反の説明を削除することもできます。これにより、メインのファクト テーブル内の重複行がいくつか節約されます。これらのデータを整理するためのはるかにコンパクトな方法である違反コードを使用します (3 文字の文字列対文の長さの文字列)。
再び、クエリ ビルダーを使用して、固有のレストランの人口統計を剥がします。ニューヨークには同じ名前のピザ ショップが複数ある可能性が非常に高いですが、クエリ ビルダーでその状況に対応できます。列 CAMIS は、固有のレストランを識別するために使用できる ID として機能します。クエリ ビルダーで、CAMIS を 2 回ドラッグします。そのうちの 1 つはカウントで集計し、名前を INSPECTION COUNT に変更します。残りの人口統計データは、DBA、BORO、BUILDING、STREET、ZIPCODE、PHONE、および CUISINE DESCRIPTION です。最後に、ジオコーダの ADDRESS という列を計算します。これは、クエリ後のスクリプトとして実行されます。クエリを実行し、次の数式を含む数式列を使用します。
:建物 ||「」|| :ストリート ||「」|| :ボロ ||「ニューヨーク」||チャー（ ：郵便番号 ）
この式は正しい住所をまとめます。:住所 <<スクリプトを取得; スクリプト エディタで、クエリ後スクリプトの列を生成するために必要な JSL が生成されます。そのコードをコピーしてクエリ ビルダーの適切なタブに貼り付け、データを 20 のグループに分割する列を生成します。これにより、ジオコードとのインターフェイスが向上します。グループ化とデータの初期化: データのシーケンス、1 から 20、ステップ 1、繰り返し 1 という新しい列を生成したら、スクリプトを取得してクエリ後スクリプトに貼り付けることができます。これで両方の列がスクリプトになったので、クエリ テーブルを削除してクエリを再実行できます。このデータ テーブルを次の名前で保存します。D-レストラン.jmp. 最後のステップとして、DBA、BORO、BUILDING、STREET、ZIPCODE、PHONE、CUISINE DESCRIPTION などの余分な列を現在のファクト テーブルから削除します。
この表を F-検査.jmp. これで、Xan Greggが作成したJMP File Exchange [GREGG]で入手できるアドインを使用して、レストランのグループをジオコーディングする準備が整いました。このアドインは、OpenStreetMaps.orgを使用して場所をジオコーディングします。このサービスは計算コストが高く、失敗しやすいため、分割することをお勧めします。D-レストラン テーブル > サブセットを使用してグループ別に表示します。図 10 に示すこのプラットフォームのサブセット機能はここで役立ちます。
図10. レストラングループ別に分割するためのサブセットテーブルプラットフォーム
新しく作成された 20 個のテーブルは、アドインを使用して個別にジオコーディングできます。住所フィールドは、正しい緯度と経度を決定するのに役立ちます。最後に、結果を同じデータ テーブルに保存します。
データテーブルを場所を含む単一のディメンションテーブルに戻すには、テーブル > 連結機能を使用して、20のグループを結合します。 D-レストランの場所.jmp。
クエリ ビルダーを使用してこのテーブルを分割したので、仮想結合を使用してテーブルを再構築できます。
まず、2 つのディメンション テーブルから始めます。 レストラン-wLocation.jmp そして違反コード.jmp. VIOLATION CODE を右クリックして Link ID を選択すると、仮想結合の開始が設定されます。列リストに小さな鍵アイコンが表示されます。Restaurants テーブルに移動し、CAMIS で同じ操作を行います。仮想結合を完了するには、すべての検査が含まれるファクト テーブルに移動し、CAMIS と VIOLATION CODE の両方に対して Link Reference を選択します。
すべての列は、メモリ内でテーブルを物理的に結合することなくファクト テーブルに表示されます。仮想結合は、列プロパティを使用してスクリプト化することもできます。
リンク参照:
プロパティを設定します("リンク参照", 参照テーブル("D(f)-Restaurants-wLocation.jmp"));
リンクIDの場合:
プロパティを設定します("リンクID", 1);
図11. 仮想結合
図 11 は、ファクト テーブルに負担をかけずに、両方のディメンション テーブルの列にアクセスできることを示しています。
最後に、仮想的に結合された列を活用してこれらのデータを視覚化および探索するためのダッシュボードを構築します。
図 12 は、Dashboard Builder が 5 つのグラフのコレクションを表示する方法を示しています。2 つのグラフを選択フィルターとして使用するには、Dashboard Builder の階層フィルター テンプレートから開始し、フィルターと階層フィルターとして CRITICAL FLAG と BORO を使用します。次に、グレード数のグラフ、マップ上の四分位数による平均スコア、最後に検査の種類別の日付数のヒート マップを使用します。
図 12. 最終 NYC 検査ダッシュボードを備えたアプリケーション ビルダーのダッシュボード ビルダー モード
これは、仮想結合によって可能になるリンク テーブルを活用して、これらのデータで作成できる視覚化の例にすぎません。ジオコーディングされたデータを使用すると、たとえば、料理別にレストランの場所を詳しく調べることもできます (図 13)。
図 13. ジオコーディングされたレストランをグレード別に色分けしてストリートレベルの地図上に表示
SQL 生成と展開
クエリ ビルダーを使用するもう 1 つの大きな利点は、構造化クエリ言語 (SQL) を生成できることです。SAS は Proc SQL 内で SQL を使用でき、ほとんどのデータベースはテーブルの結合と管理にプログラミング言語として SQL を使用します。SQL は、クエリ ビルダーのポイント アンド クリック インターフェイスで定義したクエリから生成できます。
以下は、クエリビルダーによって作成された、すべてのディメンションテーブルを結合テーブルに結合するSQLです。シリーズ.jmpそしてすべてのデータ.jmp（ケース1より）と結合したSQL完全な join.jmpそしてすべての_コード.jmpテーブル。ライブラリ名ステートメント、テーブル上の関連するlibname参照、およびプロセス SQL文 ステートメントが追加されました。残りのコードはクエリ ビルダーによって生成されました。
コードの大部分は SELECT ステートメント内の列のリストであることに注意してください。クエリ ビルダーを使用してこのようなコードを生成すると、ユーザーが SQL を知っていても非常に役立ちます。必要がないのに、なぜそんなに多くのテーブル名と列名を入力するのでしょうか。
ライブラリ名 ソース 「ファイルの場所」;
プロセス SQL文;
作成する テーブルソース.dataNseriesとして
選択t1.年、t1.期間、t1.値、t1.脚注コード、
t2.lfst_code、t2.periodicity_code、t2.series_title、t2.absn_code、
t2.アクティビティコード、t2.年齢コード、t2.クラスコード、t2.期間コード、
t2.education_code、t2.entr_code、t2.expr_code、t2.hheader_code、
t2.時間コード、t2.インディコード、t2.jdesコード、t2.lookコード、
t2.mari_code、t2.mjhs_code、t2.occupation_code、t2.orig_code、
t2.pcts_コード、t2.race_コード、t2.rjnw_コード、t2.rnlf_コード、
t2.rwns_code、t2.seek_code、t2.sexs_code、t2.tdat_code、
t2.vets_code、t2.wkst_code、t2.born_code、t2.chld_code、
t2.disa_code、t2.seasonal、t2.footnote_codes、t2.begin_year、
t2.開始期間、t2.終了年、t2.終了期間からソース.AllData t1
左外部結合ソース.series t2
の上 ( t1.シリーズID = t2.シリーズID ) ;
選択t1.年、t1.期間、t1.値、t1.シリーズタイトル、
t1.季節、t1.開始年、t1.開始期間、t1.終了年、
t1.end_period、t13.footnote_text、t34.wkst_text、t33.vets_text、
t32.tdat_text、t31.sexs_text、t30.seek_text、t29.rwns_text、
t28.rnlf_text、t27.RJNW_TEXT、t26.race_text、t25.periodicity_text、
t24.pcts_text、t23.orig_text、t22.occupation_text、t21.mjhs_text、
t20.mari_text、t19.look_text、t18.lfst_text、t17.jdes_text、
t16.indy_text、t15.hour_text、t14.hheader_text、t12.expr_text、
t11.entr_text、t10.education_text、t9.duration_text、t8.disa_text、
t7.クラステキスト、t6.幼児テキスト、t5.生まれテキスト、t4.年齢テキスト、
t3.アクティビティテキスト、t2.アブスンテキストからソース.dataNseries t1
左OUTER JOIN ソース.脚注 t13
の上 ( t1.footnote_codes = t13.footnote_code )
左外部結合ソース.wkst t34
の上 ( t34.wkst_code = t1.wkst_code )
左外部結合ソース.vets t33
の上 ( t33.vets_code = t1.vets_code )
左外部結合ソース.tdat t32
の上 ( t32.tdat_code = t1.tdat_code )
左外部結合ソース.sexs t31
の上 ( t31.性別コード = t1.性別コード )
左外部結合ソース.seek t30
の上 ( t30.seek_code = t1.seek_code )
左外部結合ソース.rwns t29
の上 ( t29.rwns_code = t1.rwns_code )
左外部結合ソース.rnlf t28
の上 ( t28.rnlf_code = t1.rnlf_code )
左外部結合ソース.rjnw t27
の上 ( t27.RJNW_CODE = t1.rjnw_CODE )
左外部結合ソース.レースt26
の上 ( t26.レースコード = t1.レースコード )
左外部結合ソース.周期性t25
の上 ( t25.周期コード = t1.周期コード )
左外部結合ソース.pcts t24
の上 ( t24.pcts_code = t1.pcts_code )
左外部結合ソース.orig t23
の上 ( t23.orig_code = t1.orig_code )
左外部結合ソース.職業t22
の上 ( t22.職業コード = t1.職業コード )
左外部結合ソース.mjhs t21
の上 ( t21.mjhs_code = t1.mjhs_code )
左外部結合ソース.mari t20
の上 ( t20.mari_code = t1.mari_code )
左外部結合ソース.look t19
の上 ( t19.look_code = t1.look_code )
左外部結合ソース.lfst t18
の上 ( t18.lfst_code = t1.lfst_code )
左外部結合ソース.jdes t17
の上 ( t17.jdes_code = t1.jdes_code )
左外部結合ソース.indy t16
の上 ( t16.indy_code = t1.indy_code )
左外部結合ソース.時間 t15
の上 ( t15.時間コード = t1.時間コード )
左外部結合ソース.hheader t14
の上 ( t14.hheader_code = t1.hheader_code )
左外部結合ソース.expr t12
の上 ( t12.expr_code = t1.expr_code )
左外部結合ソース.entr t11
の上 ( t11.entr_code = t1.entr_code )
左外部結合ソース.education t10
の上 ( t10.教育コード = t1.教育コード )
左OUTER JOIN ソース.期間 t9
の上 ( t9.duration_code = t1.duration_code )
左外部結合ソース.disa t8
の上 ( t8.disa_code = t1.disa_code )
左外部結合ソース.クラス t7
の上 ( t7.クラスコード = t1.クラスコード )
左外部結合ソース.chld t6
の上 ( t6.chld_code = t1.chld_code )
左外部結合ソース.born t5
の上 ( t5.born_code = t1.born_code )
左外部結合ソース.ages t4
の上 ( t4.年齢コード = t1.年齢コード )
左外部結合ソース.アクティビティt3
の上 ( t3.アクティビティコード = t1.アクティビティコード )
左外部結合ソース.absn t2
の上 ( t1.absn_code = t2.absn_code );
やめる;
まとめ
アナリストは、視覚化と分析を可能にする方法で整理された1つのテーブルにデータを必要とします。しかし、 多くの場合、データは多くのテーブルにロード、維持、保存するために整理され（正規化されている）、アナリストは多くのテーブルを結合して 1 つの分析可能なテーブルに要約することが求められます。
JMP クエリ ビルダーは、JMP 内から複数のテーブルを結合する強力な方法です。プレビュー機能を使用すると、時間のかかるテーブル結合操作を実行する前に、結合が適切に定義されているかどうかを確認できます。生成された SQL は SAS またはデータベースに展開できるため、このようなコードを手動で記述する時間を大幅に節約できます。
参考文献
[UGSCPS] 労働力統計 - 現在の人口調査 - CPS。2016年8月18日閲覧。http://www.bls.gov/cps/data.htm.
[DOHMH] DOHMHニューヨーク市レストラン検査結果。2016年8月17日閲覧。https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59.
[グレッグ]グレッグ、X. (2014年5月28日)。地名のジオコーディング。2016年8月18日閲覧。https://community.jmp.com/docs/DOC-6175.
