ダニエル・ヴァレンテ、博士号、JMP シニア プロダクト マネージャー、SAS
ジョン・ワイズ、JMP セールスおよびマーケティング担当バイス プレジデント、SAS
概要
JMP 13 では、アナリストが一般的なデータの問題に簡単に対処できるようにする 2 つの新しいツールが導入されています。 多くの場合、2 つ以上のデータ テーブルが共通のキーによって関連付けられていますが、ファクト サンプリングの頻度や次元 (たとえば、長いものと広いもの) の点で大きく異なります。 これら 2 つ (またはそれ以上) のテーブルを実際に結合すると、メモリ内で非常に大きなテーブルが作成される場合があります。 これは、ファクト テーブルとディメンション テーブルが比較的コンパクトな場合は厄介ですが、大きすぎてメモリに収まらない結合テーブルがすぐに生成される可能性があります。 解決策は仮想結合を使用することです。これにより、結合されたテーブルを実際に作成せずに結合された関係が維持され、ファクト テーブルに負担をかけずに効果的に強化されます。 アナリストは、データベースで複雑なテーブル結合または要約を作成し、SQL を記述する必要があることに気付くことがよくあります。これは、特にゆっくりと変化するディメンションなどの複雑な関係がある場合に、独自の一連の苦労を生み出します。 JMP Query Builder は、簡単な SQL 生成および記述ツールとして機能し、そのコードをデータベースで実行できます。 適切で適切なクエリをドラッグ アンド ドロップすると、クエリ ビルダが自動的に SQL コードを作成するため、面倒な手作業やエラーが発生しやすい作業が不要になります。
リレーショナル テーブル構造の概要
アナリストは、列に変数、行に観測値を含む形式のデータを必要とします。 データには、観察結果を明確にサブグループ化するカテゴリ列も必要になる場合があります (例: 収入レベル、国、機械など)。 データには、観察結果をさらに明らかにする属性 (住所、シリアル番号、顧客 ID など) も含まれる場合があります。
多くの場合、このような分析のソース データは、データベースに格納されたリレーショナル データ構造です。 データ サイエンスの最新の学習コースの多くは、リレーショナル データ構造、データベース、SQL に関連するトピックを扱っています。 しかし、ほとんどのエンジニア、科学者、統計学者は、学術的な環境でこれらのトピックに触れていないため、継続的な非公式の教育の一環としてそれらについて学ぶ必要があります. JMP Query Builder は、アナリストにリレーショナル データ構造と分析可能なデータとの間の架け橋を提供します。 アナリストは、いくつかの用語と概念を学習することで、Query Builder を使用して分析の準備が整ったデータを生成できます。
このホワイト ペーパーでのリレーショナル データ構造の簡単な説明は、このトピックの徹底的な研究に取って代わるものではありません。むしろ、JMP でクエリ ビルダとその仮想結合機能を使用する際に使用される用語と定義を紹介します。
重要なデータを格納するテーブルが複数あるのはなぜですか?
会社の製品の顧客の購入に関するデータを保存する方法を考案する必要があると想像してください。 最初に、次のような、収集する必要がある可能性のあるすべての変数をリストすることから始めます。
- 購入日
- 購入金額
- 購入方法（PO or CC）
- 商品SKU
- 製品説明
- 顧客名
- 顧客住所
- お客様の電話番号
これは確かに包括的なリストではありませんが、良い出発点です。 次に、これらのデータの維持について考えてみましょう。 このテーブルには、購入ごとに 8 つの列と 1 つの行があります。 一部のフィールドには、購入金額や購入日など、多くの個別の値が含まれる場合があります。 製品の SKU や説明など、その他のフィールドには、個別の値がはるかに少なく、繰り返される値が多数あります。
テーブルのサイズを縮小する一般的な方法は、テーブルを 3 つの論理グループに分割することです。 最初は、トランザクションを含むテーブルまたは事実、購入日、購入金額など。 2 番目のテーブルには顧客情報が含まれ、3 番目のテーブルには製品情報が含まれます。 データ列間のリンクを維持するには、リンク情報を含む列を追加して 3 つのテーブルを関連付ける必要があります。 これらの列はキー. このレイアウトを表示する一般的な方法は、エンティティ関係図 (ER) . 各エンティティには、テーブル名、各行を一意に識別するキーまたはキーのセット、および各行に関する情報を提供する属性または変数のセットがあります。 顧客の購入日の ER ダイアグラムを図 1 に示します。
図1。 顧客購入データのエンティティ関係図
顧客ディメンション テーブルの顧客 ID の横にあるキー シンボルは、顧客 ID がわかっている場合、その顧客をテーブルとすべての関連情報で一意に見つけることができることを意味します。 顧客 ID は Purchases Fact テーブルにもあります。 顧客 ID は Purchases Fact テーブルにある場合、外部キーと呼ばれます。これは、何度も表示される可能性があり、表示される行に対して外部テーブルの行を一意に定義するためです。
図 1 のレイアウトを使用すると、製品説明を更新する方法が非常に簡単にわかります。 これを行うには、Product Dimension テーブルを編集するだけで、1 つの変更がこれまでに行われたすべての購入に適用されます。保守性. これが製品説明が何度も繰り返される 1 つのテーブルである場合、多くの行を編集する必要があり、間違いやデータ品質の問題が必然的に発生します。
ケース１：現況人口調査
次に、Query Builder を使用した例を見てみましょう。 米国政府は、Current Population Survey (CPS) [USGCPS] で多くの興味深いデータを収集しています。 CPS は次のとおりです。
「 Current Population Survey (CPS) は、米国で最も古く、最大かつ最もよく知られている調査の 1 つです。 仕事、収入、教育など、私たちを個人として、また社会として定義する多くの事柄に関する情報を提供することは、非常に重要です。 CPS は、毎月の労働力統計の主要な情報源であることに加えて、国民の経済的および社会的幸福について国に情報を提供し続けるさまざまな他の調査のデータを収集するために使用されます。 これは、毎月の基本 CPS 質問に一連の補足質問を追加することによって行われます。 補足的な問い合わせは月ごとに異なり、子供の支援、ボランティア活動、健康保険の加入、就学など、さまざまなトピックが含まれます。 サプリメントは通常、毎年または半年ごとに実施されますが、サプリメントの頻度と再発は、サプリメントのスポンサーのニーズを最もよく満たすものに完全に依存します.
これらのデータは 36 個のテキスト ファイルとしてダウンロードできます。ファイルはタブ区切りのテキスト ファイルであるため、JMP で簡単に開くことができます。 JMP テーブルを見ると、ER ダイアグラム (図 2) が作成され、Query Builder での作業が通知されます。
図 2. CPS労働力統計データ表のER図
クエリ ビルダーを使用するには、プライマリ テーブル (ファクト) とセカンダリ テーブル (ディメンション) を定義する必要があります。 ）。
CPS データのファクト テーブルが呼び出されます。 AllData.jmp . テーブルには 500 万行を超える行がありますが、列は 5 つしかありません。 列には、「series_id」、日付、および「値」列があります。 データの意味を理解するには、 series_id.jmp意味。 図 2 の ER ダイアグラムは、「series_id」が関連していることを示しています。シリーズ.jmpテーブル。 次に、両方のテーブルを JMP で開き、クエリ ビルダーを使用して結合を定義します。
JMPで、 AllData.jmpプライマリ (ファクト) テーブルとしてシリーズ.jmpセカンダリ (ディメンション) テーブルとして (図 3)。 JMP は結合に適合するキーを自動的に探して設定しますが、シリーズ テーブルの右側にあるベン図をクリックして確認する必要があります。 クエリ ビルダーは両方のテーブルで「footnote_codes」を見つけましたが、これらをキーとして結合するのではなく、「series_id」だけを結合したいので、キーの関係を削除する必要があります。
図 3. の結合のためのクエリビルダーAllData.jmpとシリーズ.jmp
ここで、結合されたテーブルの列を定義する必要があります (図 4)。 そのためには、 AllData.jmpをクリックして、そのテーブルから必要な列を選択します。 結果のテーブルでそのキーは必要ないため、ここで「series_id」を削除します (シリーズとdata.jmp ）。
図 4。 参加するクエリビルダーシリーズとdata.jmpすべてに」 _code.jmp 」 テーブル
注意してくださいシリーズとdata.jmpの約5倍の大きさです。 AllData.jmpテーブル。 この膨張は、すべての「_code」フィールドの値が繰り返されるためです。 明らかに、36 個のテーブルにデータを格納すると、保管所要件を大幅に満たします。 次に、選択しますシリーズとdata.jmpプライマリ テーブルとすべての「_code.jmp 」 テーブルをセカンダリ テーブルとして使用します (図 5)。
図 5. すべての「 _code.jmp 」
キー変数はもう必要ないため、「_code」テーブルの「_text」フィールドのみを使用してクエリを作成します。 JMP の [Cols] > [Columns Viewer] を使用すると、テーブル内の現在 42 列の概要を簡単に取得できます完全な join.jmp。 それでも 570 万行ありますが、これは次の例と同じです。 AllData.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 がサンドボックスとして使用され、実際のデータは常にサーバーに保存されるため)。次に、Recode ユーティリティを使用して、これらのレベルを欠落に変更します。
図 7. 完全なデータ セットの検査日
再コード化ウィンドウには、1900 年 1 月 1 日である 1,151 のレコードがあります。 この古い値を • に変更するには、文字列を削除してから [完了] -> [インプレース] をクリックします。 RECORD DATE はデータが抽出された日付であり、この分析には関係ないため、列を削除します。
このホワイト ペーパーは、仮想結合とクエリ ビルダーに関するものなので、なぜ非正規化されたテーブルを見ているのか疑問に思われるかもしれません。 これらのデータを正規化する機会があるようです。 これらの生データには、後で JMP アドインを使用して実行できるタスクである、個々のレストランの地理コード化された場所が含まれていません。 このプロセスは計算コストが高いため、これらのデータに複数の検査がある可能性がある一意の場所のみをジオコーディングすることは理にかなっています。 さらに、違反のテーブルを追加する機会があるようです。これは、一意の検査よりもはるかに少ないものです。
データを分割する前に、これらのデータのサンプルを取得して、調査の演習で数値を管理しやすくします。
サンプリングは、Query Builder で簡単に実行できるものです。 [テーブル] > [JMP クエリ ビルダー] を選択すると、起動ダイアログが表示されます。 この場合、結合を実行していないため、次を使用します。 DOHMH_New_York_City_Restaurant_Inspection_Results.jmpこの時点でセカンダリ テーブルのないプライマリ テーブルとして。 Query Builder には、Sample という名前のタブがあります。 [Sample this results set] のチェック ボックスをオンにすると、[First] を選択できます。 N行またはランダムN行。 これらのデータのランダムな 10% のサンプルを取るので、ランダムに 44,815 を入れます。 N行。 すべての列を [列を含める] セクションに追加し、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."年[検査日]"
FROM DOHMH_New_York_City_Restaurant_Inspection_Results t1
ORDER BY RANDOM() LIMIT 44815;
使用後ランダム順 ()関数を使用すると、このクエリはデータの適切なサブセットを生成します。 これをサブセットとして保存し、レストランの人口統計と違反コードに分割します。 ここでもクエリ ビルダを使用できます。 違反コードから始めます。 繰り返しますが、必要なのはプライマリ テーブルだけです。 VIOLATION CODE と VIOLATION DESCRIPTION を変数リストにドラッグ アンド ドロップしてから、もう一度 VIOLATION CODE をドラッグします。これにより、カウントで集計し、目的のプロパティを持つテーブルを生成できます。 集計列の JMP 名を VIOLATION COUNT に変更します。 列または派生列へのエイリアスを生成するこの機能は、クエリ ビルダーの強力な機能です。 また、図 8 に示すように、VIOLATION COUNT を Order By ロールにドラッグして、新しく作成された集計列で自動的に並べ替えるように選択することもできます。
図 8. 集計列の名前が Violation Count に変更され、Order By プロパティが追加されました
一意の違反コードが 88 しかないため、この結果のクエリははるかにコンパクトになります。 このテーブルに名前を付けた後D-ViolationCodes.jmp 、tこれは、グラフ ビルダーを使用して、どのコードが最も多くのレコードを持っているかを調べる良い機会です。 VIOLATION DESCRIPTION を X 軸にドラッグし、VIOLATION COUNT を Y 軸にドラッグします。 次に、VIOLATION DESCRIPTION を右クリックし、VIOLATION COUNT (降順) で並べ替えます。 上位のカテゴリだけに注目するには、2,500 を超える一意のレコードを持つ違反カテゴリで VIOLATION COUNT にローカル データ フィルターを使用できます (図 9)。
図 9. 上位の違反数 (サンプリングされたテーブル内の 2500 を超える一意のレコード)
ここでは、違反テーブルから離れて、ユニークなレストランの人口統計に焦点を当てることができます. この時点で、違反の説明を削除することもできます。これにより、メインのファクト テーブルに多数の重複行が保存されます。 VIOLATION CODE を使用すると、これらのデータをよりコンパクトに整理できます (3 文字の文字列と 1 文の文字列の比較)。
ここでも、クエリ ビルダーを使用して、レストラン固有の人口統計をはがします。 NYC には同じ名前のピザ屋が複数ある可能性が非常に高いですが、クエリ ビルダはその状況を処理できます。 列 CAMIS は、一意のレストランを識別するために使用できる ID として機能します。 Query Builder で CAMIS を 2 回ドラッグします。そのうちの 1 つは Aggregated by count で、名前を INSPECTION COUNT に変更します。 残りの人口統計データは、DBA、BORO、BUILDING、STREET、ZIPCODE、PHONE、および CUISINE DESCRIPTION です。 最後に、クエリ後のスクリプトとして実行される、ジオコーダーの ADDRESS という列を計算します。 クエリを実行し、次の数式で数式列を利用します。
:建物 || " " || :ストリート || " " || :ボロ || 「ニューヨーク」 ||シャア（ ：郵便番号 ）
この式は、正しい住所をまとめたものです。 タイピング:住所 <<スクリプトを取得;をスクリプト エディタで実行すると、クエリ後のスクリプトの列を生成するために必要な JSL が生成されます。 そのコードをコピーしてクエリ ビルダーの適切なタブに貼り付け、ジオコードとのインターフェイスを改善するためにデータを 20 のグループに分割する列を生成します。 Group and Initialize Data: Sequence Data, From 1 to 20, Step 1, Repeat 1 という名前の新しい列を生成した後、スクリプトを取得してクエリ後のスクリプトに貼り付けることができます。 両方の列がスクリプトになったので、クエリ テーブルを削除して、クエリを再実行できます。 このデータ テーブルを名前を付けて保存します。 D-Restaurants.jmp . 最後のステップとして、DBA、BORO、BUILDING、STREET、ZIPCODE、PHONE、CUISINE DESCRIPTION などの余分な列を現在のファクト テーブルから削除します。
このテーブルを名前を付けて保存F-Inspections.jmp . これで、OpenStreetMaps.org を使用して場所をジオコーディングする Xan Gregg によって作成された、JMP File Exchange [GREGG] で入手可能なアドインを使用して、レストランのグループをジオコーディングする準備が整いました。 このサービスは計算コストが高く、失敗しやすいため、分割することをお勧めしますDレストランテーブル > サブセットを使用してグループごと。 ここでは、図 10 に示すこのプラットフォームの Subset By 機能が役立ちます。
図 10. レストラン グループごとに分割するためのサブセット テーブル プラットフォーム
新しく作成された 20 個のテーブルは、アドインを使用して個別にジオコーディングできます。 住所フィールドは、正確な緯度と経度を決定するのに役立ちます。 最後に、結果を同じデータ テーブルに保存します。
データ テーブルを場所を含む単一のディメンション テーブルに戻すには、[テーブル] > [連結] 機能を使用して、20 個のグループを結合します。それは名前が付けられていますD-RestaurantswLocation.jmp.
Query Builder を使用してこのテーブルを分解したので、仮想結合を使用して元に戻すことができます。
まず、2 つのディメンション テーブルから始めます。レストラン-wLocation.jmpとViolationCodes.jmp . VIOLATION CODE を右クリックして [Link ID] を選択すると、仮想結合の開始が設定されます。 列リストに小さな鍵のアイコンが表示されることに注意してください。 レストランのテーブルに移動し、CAMIS で同じことを行います。 仮想結合を完了するには、すべてのインスペクションを含むファクト テーブルに移動し、CAMIS と VIOLATION CODE の両方のリンク参照を選択します。
メモリ内のテーブルを物理的に結合しなくても、すべての列がファクト テーブルに表示されます。 仮想結合は、列プロパティを使用してスクリプト化することもできます。
リンク参照の場合:
Set Property("Link Reference", Reference Table("D(f)-Restaurants-wLocation.jmp"));
リンク ID の場合:
Set Property("リンク ID", 1);
図 11. 仮想参加
図 11 は、ファクト テーブルに負荷をかけることなく、両方のディメンション テーブルの列にアクセスできることを示しています。
最後に、ダッシュボードを構築して、仮想的に結合された列を活用してこれらのデータを視覚化および調査します。
図 12 は、Dashboard Builder が 5 つのグラフのコレクションをどのように表示するかを示しています。 2 つのグラフを選択フィルターとして使用するには、Dashboard Builder の階層フィルター テンプレートから開始し、フィルターおよび階層フィルターとして CRITICAL FLAG および BORO を使用します。 次に、グレード カウントのグラフ、マップ上の分位点ごとの平均スコア、最後に、検査の種類ごとの日付カウントのヒート マップを使用します。
図 12. Final NYC Inspection Dashboard を使用した Application Builder の Dashboard Builder モード
これは、仮想結合によって提供されるリンクされたテーブルを活用して、これらのデータで作成できる視覚化のタイプのほんの一例です。 ジオコーディングされたデータを使用すると、たとえば、レストランの場所を料理別に掘り下げることもできます (図 13)。
図 13. ストリート レベルの地図に表示されるグレード別に色分けされたジオコーディングされたレストラン
SQL の生成と展開
Query Builder を使用するもう 1 つの主な利点は、構造化照会言語 (SQL) の生成です。 SAS は Proc SQL 内で SQL を使用でき、ほとんどのデータベースはプログラミング言語として SQL を使用してテーブルを結合および管理します。 SQL は、クエリ ビルダーのポイント アンド クリック インターフェイスで定義したクエリから生成できます。
以下は、すべてのディメンション テーブルを次の結合テーブルに結合するためにクエリ ビルダによって作成された SQL です。シリーズ.jmpとAllData.jmp (ケース 1 から) および結合からの SQL完全な join.jmpそしてすべて_code.jmpテーブル。 のライブラリ名ステートメント、テーブル上の関連する libname 参照、およびプロセスSQL声明が追加されました。 残りのコードは、Query Builder によって生成されました。
コードの大部分は、SELECT ステートメント内の列のリストであることに注意してください。 ユーザーが SQL を知っている場合でも、クエリ ビルダを使用してこのようなコードを生成すると、非常に役立ちます。 必要がないのに、なぜそんなに多くのテーブル名と列名を入力するのでしょうか?
ライブラリ名ソース「ファイルの場所」 ;
プロセスSQL ;
作成テーブルsource.dataNseriesとして
選択するt1.year、t1.period、t1.value、t1.footnote_codes、
t2.lfst_code、t2.periodicity_code、t2.series_title、t2.absn_code、
t2.activity_code、t2.ages_code、t2.class_code、t2.duration_code、
t2.education_code、t2.entr_code、t2.expr_code、t2.hheader_code、
t2.hour_code、t2.indy_code、t2.jdes_code、t2.look_code、
t2.mari_code、t2.mjhs_code、t2.occupation_code、t2.orig_code、
t2.pcts_code、t2.race_code、t2.rjnw_code、t2.rnlf_code、
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.begin_period、t2.end_year、t2.end_periodからソース.AllData t1
左OUTER JOIN source.series t2
の上( t1.series_id = t2.series_id ) ;
選択するt1.year、t1.period、t1.value、t1.series_title、
t1.季節、t1.begin_year、t1.begin_period、t1.end_year、
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.class_text、t6.chld_text、t5.born_text、t4.ages_text、
t3.activity_text、t2.absn_textからsource.dataNseries t1
左OUTER JOIN source.footnote t13
の上( t1.footnote_codes = t13.footnote_code )
左外部結合 source.wkst t34
の上( t34.wkst_code = t1.wkst_code )
左OUTER JOIN source.vets t33
の上( t33.vets_code = t1.vets_code )
左OUTER JOIN source.tdat t32
の上( t32.tdat_code = t1.tdat_code )
左OUTER JOIN source.sexs t31
の上( t31.sexs_code = t1.sexs_code )
左OUTER JOIN source.seek t30
の上( t30.seek_code = t1.seek_code )
左OUTER JOIN source.rwns t29
の上( t29.rwns_code = t1.rwns_code )
左OUTER JOIN source.rnlf t28
の上( t28.rnlf_code = t1.rnlf_code )
左OUTER JOIN source.rjnw t27
の上( t27.RJNW_CODE = t1.rjnw_code )
左OUTER JOIN source.race t26
の上( t26.race_code = t1.race_code )
左OUTER JOIN source.periodicity t25
の上( t25.周期_コード = t1.周期_コード )
左OUTER JOIN source.pcts t24
の上( t24.pcts_code = t1.pcts_code )
左OUTER JOIN source.orig t23
の上( t23.orig_code = t1.orig_code )
左OUTER JOIN source.occupation t22
の上( t22.職業コード = t1.職業コード )
左OUTER JOIN source.mjhs t21
の上( t21.mjhs_code = t1.mjhs_code )
左OUTER JOIN source.mari t20
の上( t20.mari_code = t1.mari_code )
左OUTER JOIN source.look t19
の上( t19.look_code = t1.look_code )
左OUTER JOIN source.lfst t18
の上( t18.lfst_code = t1.lfst_code )
左OUTER JOIN source.jdes t17
の上( t17.jdes_code = t1.jdes_code )
左外部結合 source.indy t16
の上( t16.indy_code = t1.indy_code )
左OUTER JOIN source.hour t15
の上( t15.hour_code = t1.hour_code )
左OUTER JOIN source.hheader t14
の上( t14.hheader_code = t1.hheader_code )
左OUTER JOIN source.expr t12
の上( t12.expr_code = t1.expr_code )
左OUTER JOIN source.entr t11
の上( t11.entr_code = t1.entr_code )
左OUTER JOIN source.education t10
の上( t10.教育コード = t1.教育コード )
左OUTER JOIN source.duration t9
の上( t9.duration_code = t1.duration_code )
左OUTER JOIN source.disa t8
の上( t8.disa_code = t1.disa_code )
左OUTER JOIN source.class t7
の上( t7.class_code = t1.class_code )
左OUTER JOIN source.chld t6
の上( t6.chld_code = t1.chld_code )
左OUTER JOIN source.born t5
の上( t5.born_code = t1.born_code )
左OUTER JOIN source.ages t4
の上( t4.ages_code = t1.ages_code )
左OUTER JOIN source.activity t3
の上( t3.activity_code = t1.activity_code )
左OUTER JOIN source.absn t2
の上( t1.absn_code = t2.absn_code );
やめる;
まとめ
アナリストは、視覚化と分析を可能にする方法で整理された 1 つのテーブルにデータが必要です。 しかし、多くの場合、データは多くのテーブル (正規化) にロード、維持、保存するために編成されるため、アナリストは多くのテーブルを結合して 1 つの分析可能なテーブルに要約する必要があります。
JMP Query Builder は、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 .
