다니엘 발렌테 , PhD, JMP 선임 제품 관리자, SAS
존 와이즈 , JMP SAS 영업 및 마케팅 부사장
추상적인
JMP 13에는 분석가가 일반적인 데이터 문제를 쉽게 처리할 수 있는 두 가지 새로운 도구가 도입되었습니다. 종종 두 개 이상의 데이터 테이블이 공통 키로 관련되지만 팩트 샘플링 빈도 또는 차원(예: 길이 대 너비) 면에서 매우 다릅니다. 이 두 개 이상의 테이블을 실제로 조인하면 메모리가 매우 커지는 결과 테이블이 생성될 수 있습니다. 팩트 및 차원 테이블이 상대적으로 작을 때 이는 성가신 일이지만 너무 커서 메모리에 맞지 않는 조인된 테이블을 빠르게 생성할 수 있습니다. 해결책은 조인된 테이블을 실제로 생성하지 않고 조인된 관계를 보존하는 가상 조인을 사용하는 것입니다. 즉, 팩트 테이블에 부담을 주지 않고 효과적으로 보강할 수 있습니다. 분석가는 데이터베이스에서 복잡한 테이블 조인 또는 요약을 만들고 SQL을 작성해야 하는 경우가 많으며, 이로 인해 특히 천천히 변하는 차원과 같은 복잡한 관계가 있는 경우 자체적인 어려움이 발생합니다. JMP Query Builder는 손쉬운 SQL 생성 및 작성 도구 역할을 하며 이 도구의 코드는 데이터베이스에서 실행될 수 있습니다. 정확하고 바람직한 쿼리를 끌어서 놓으면 쿼리 빌더가 자동으로 SQL 코드를 작성하므로 지루하고 오류가 발생하기 쉬운 수동 작업이 필요하지 않습니다.
관계형 테이블 구조 개요
분석가는 열에 변수가 있고 행에 관찰이 있는 형식의 데이터가 필요합니다. 데이터에는 관측값을 명확하게 하위 그룹화하는 범주형 열(예: 소득 수준, 국가, 기계 등)이 필요할 수도 있습니다. 또한 데이터에는 관찰 내용을 추가로 설명하는 속성(예: 주소, 일련 번호, 고객 ID 등)이 있을 수 있습니다.
종종 그러한 분석을 위한 소스 데이터는 데이터베이스에 저장된 관계형 데이터 구조입니다. 데이터 과학의 많은 최신 학습 과정은 관계형 데이터 구조, 데이터베이스 및 SQL과 관련된 주제를 다룹니다. 그러나 대부분의 엔지니어, 과학자 및 통계학자는 학문적 환경에서 이러한 주제에 노출되지 않으므로 지속적인 비공식 교육의 일부로 이에 대해 배워야 합니다. JMP Query Builder는 분석가에게 관계형 데이터 구조와 분석 준비가 된 데이터 사이의 가교 역할을 합니다. 몇 가지 용어와 개념을 학습함으로써 분석가는 Query Builder를 사용하여 분석 준비가 된 데이터를 생성할 수 있습니다.
이 백서에서 관계형 데이터 구조에 대한 간략한 논의는 주제에 대한 철저한 연구를 대체하기 위한 것이 아닙니다. 대신 JMP에서 Query Builder와 가상 조인 기능으로 작업할 때 사용되는 용어와 정의를 소개합니다.
중요한 데이터를 저장할 테이블이 두 개 이상인 이유는 무엇입니까?
고객의 회사 제품 구매에 대한 데이터를 저장하는 방법을 고안해야 한다고 상상해 보십시오. 먼저 다음과 같이 수집해야 할 수 있는 모든 변수를 나열하는 것으로 시작할 수 있습니다.
- 구입 날짜
- 구매 금액
- 구매 방법(PO 또는 CC)
- 제품 SKU
- 제품 설명
- 고객 이름
- 고객 주소
- 고객 전화번호
이것은 확실히 포괄적인 목록은 아니지만 좋은 시작입니다. 이제 이러한 데이터를 유지하는 방법에 대해 생각해 보십시오. 이 테이블에는 각 구매에 대해 8개의 열과 1개의 행이 있습니다. 일부 필드에는 구매 금액 또는 구매 날짜와 같은 많은 고유 값이 있을 수 있습니다. 제품 SKU 및 설명과 같은 다른 필드에는 고유 값이 훨씬 적고 반복되는 값이 많습니다.
테이블 크기를 줄이는 일반적인 방법은 테이블을 세 개의 논리적 그룹으로 나누는 것입니다. 첫 번째는 트랜잭션을 포함하는 테이블입니다. 사리 , 예: 구매 날짜 및 구매 금액. 두 번째 테이블에는 고객 정보가 있고 세 번째 테이블에는 제품 정보가 있습니다. 데이터 열 간의 링크를 유지하려면 링크 정보가 있는 열을 추가하여 세 테이블을 연결해야 합니다. 이러한 열은 열쇠 . 이 레이아웃을 표시하는 일반적인 방법은 엔터티 관계 다이어그램(ER) . 각 엔터티에는 테이블 이름, 각 행을 고유하게 식별하는 키 또는 키 집합, 각 행에 대한 정보를 제공하는 속성 또는 변수 집합이 있습니다. 고객 구매 날짜에 대한 ER 다이어그램은 그림 1에 나와 있습니다.
그림 1. 고객 구매 데이터에 대한 엔터티 관계 다이어그램
고객 차원 테이블에서 고객 ID 옆에 있는 키 기호는 고객 ID를 알고 있는 경우 테이블 및 모든 관련 정보에서 해당 고객을 고유하게 찾을 수 있음을 의미합니다. 고객 ID는 Purchases Fact 테이블에도 있습니다. 고객 ID는 여러 번 나타날 수 있고 그것이 나타나는 행에 대해 외래 테이블의 행을 고유하게 정의하기 때문에 구매 팩트 테이블에 있을 때 외래 키라고 합니다.
그림 1의 레이아웃을 사용하면 제품 설명을 업데이트하는 방법을 매우 쉽게 확인할 수 있습니다. 이렇게 하려면 제품 차원 테이블을 편집하기만 하면 변경 사항이 모든 구매에 적용됩니다. 유지 보수성 . 제품 설명이 여러 번 반복되는 하나의 테이블인 경우 많은 행을 편집해야 하므로 필연적으로 실수 및 데이터 품질 문제가 발생합니다.
사례 1: 현재 인구 조사
이제 Query Builder를 사용한 예를 살펴보겠습니다. 미국 정부는 CPS(Current Population Survey)[USGCPS]를 통해 흥미로운 데이터를 많이 수집합니다. CPS는 다음과 같습니다.
“ 현재 인구 조사(CPS)는 미국에서 가장 오래되고 규모가 크며 가장 잘 알려진 조사 중 하나입니다. 개인과 사회로서 우리를 정의하는 많은 것들, 즉 우리의 일, 수입, 교육에 대한 정보를 제공하는 것은 대단히 중요합니다. CPS는 월별 노동력 통계의 주요 출처일 뿐만 아니라 국민의 경제적, 사회적 복지에 대한 정보를 국가에 제공하는 다양한 기타 연구를 위한 데이터를 수집하는 데 사용됩니다. 월별 기본 CPS 질문에 일련의 보충 질문을 추가하면 됩니다. 추가 문의는 매월 다르며 자녀 양육, 자원 봉사, 건강 보험 보장, 학교 등록과 같은 다양한 주제를 다룹니다. 보충은 일반적으로 매년 또는 반년마다 수행되지만 보충의 빈도와 반복은 전적으로 보충 후원자의 요구를 가장 잘 충족시키는 것에 달려 있습니다.”
이러한 데이터는 36개의 텍스트 파일로 다운로드할 수 있으며 파일이 탭으로 구분된 텍스트 파일이므로 JMP에서 쉽게 열 수 있습니다. JMP 테이블을 보면 Query Builder에서 작업을 알리기 위해 ER 다이어그램(그림 2)이 생성되었습니다.
그림 2. CPS 노동력 통계 데이터 테이블의 ER 다이어그램
Query Builder를 사용하려면 기본 테이블(팩트) 및 보조 테이블(차원)을 정의해야 합니다. ).
CPS 데이터에 대한 팩트 테이블은 다음과 같습니다. AllData.jmp . 테이블에는 5백만 개가 넘는 행이 있지만 열은 5개뿐입니다. 열에는 "series_id", 날짜 및 "값" 열이 있습니다. 데이터를 이해하려면 데이터가 무엇인지 알아야 합니다. series_id.jmp 수단. 그림 2의 ER 다이어그램은 "series_id"가 시리즈.jmp 테이블. 그런 다음 JMP에서 두 테이블을 모두 열고 Query Builder를 사용하여 조인을 정의합니다.
JMP에서 선택 AllData.jmp 기본(팩트) 테이블 및 시리즈.jmp 보조(차원) 테이블로 사용합니다(그림 3). JMP는 조인에 맞는 키를 자동으로 찾고 설정하지만 시리즈 테이블 오른쪽에 있는 벤 다이어그램을 클릭하여 이를 확인해야 합니다. Query Builder는 두 테이블 모두에서 "footnote_codes"를 찾았지만 키 관계가 제거되도록 "series_id"만 키로 조인하는 것을 원하지 않습니다.
그림 3. 조인을 위한 쿼리 빌더 AllData.jmp 그리고 시리즈.jmp
이제 조인된 테이블에서 열을 정의해야 합니다(그림 4). 그렇게 하려면 다음을 선택하십시오. AllData.jmp 왼쪽 상단에서 해당 테이블에서 필요한 열을 선택합니다. 결과 테이블( 시리즈 및 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개 열에 대한 요약을 쉽게 얻을 수 있습니다. 전체 조인.jmp. 여전히 570만 개의 행이 있으며 이는 다음과 같습니다. AllData.jmp , 그러나 이제 데이터를 설명하는 텍스트 필드가 있습니다. 테이블인데도 전체 조인.jmp 여전히 테이블보다 6배 더 큽니다. AllData.jmp, 이제 분석에 유용한 테이블이 생겼습니다.
그래프 빌더를 사용하여 다음에서 제조 실업률 추세를 플로팅합니다. 전체 조인.jmp . 그림 6에서 경기 침체 기간 동안 이 부문의 중단은 빨간색 추세선으로 표시됩니다. 2016년 실업률은 2006~2007년 수준으로 돌아갔다. 녹색 추세선은 자동차 제조 부문의 고용 수준을 나타냅니다. 2010년부터 2015년까지 300,000개 이상의 자동차 제조 일자리가 추가되었습니다.
그림 6. CPS 노동력 통계 데이터를 보여주는 그래프 빌더
사례 2: 식당 검사 데이터
이 사례에서는 DOHMH New York City Restaurant Inspection Results를 분석하기 위해 가상 조인 및 JMP Query Builder를 사용하는 방법을 살펴봅니다. [DOHMH] . 새로운 검사관이 되어 과거 데이터를 탐색하여 데이터가 무엇을 나타내는지 확인한다고 상상해 보십시오. 웹사이트에서 https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59 , JMP에서 쉽게 열 수 있는 이러한 데이터의 .csv 버전을 다운로드할 수 있습니다. 2016년 7월 17일 전체 다운로드는 448,149개의 레코드가 포함된 163.3MB 파일을 생성합니다.
이러한 데이터에는 검사 이벤트의 M/D/Y인 INSPECTION DATE 열이 있습니다. 이 데이터에 포함된 연도를 확인하려면 마우스 오른쪽 버튼을 클릭하고 새 수식 열 > 날짜 시간 > 연도를 사용합니다. 이를 연속에서 공칭으로 변환한 다음 분석 > 분포를 그림 7에 표시합니다. 레벨 1900은 누락된 데이터에 대한 코드일 가능성이 높으며 주소가 필요합니다. 이러한 데이터를 파괴적으로 편집하는 것은 문제가 되지 않습니다(여기서는 JMP가 샌드박스로 사용되고 실제 데이터는 항상 서버에 저장되기 때문입니다). 다음으로 Recode 유틸리티를 사용하여 이러한 수준을 누락으로 변경합니다.
그림 7. 전체 데이터 세트에 대한 검사 날짜
레코딩 창에는 1900년 1월 1일인 1,151개의 레코드가 있습니다. 문자열을 삭제한 다음 Done -> In Place를 클릭하여 이 이전 값을 •로 변경합니다. RECORD DATE는 데이터를 가져온 날짜이며 이 분석에 중요하지 않으므로 열을 삭제합니다.
이 문서는 가상 조인 및 Query Builder에 관한 것이므로 비정규화된 테이블을 보는 이유가 궁금할 수 있습니다. 이러한 데이터를 정규화할 기회가 있는 것 같습니다. 이러한 원시 데이터에는 나중에 JMP 추가 기능으로 수행할 수 있는 작업인 개별 레스토랑의 지오코딩된 위치가 없습니다. 이 프로세스는 계산 비용이 많이 들기 때문에 이러한 데이터에서 여러 검사가 있을 수 있는 고유한 위치만 지오코딩하는 것이 좋습니다. 또한 고유 검사보다 훨씬 적은 추가 위반 표를 가질 수 있는 기회가 있는 것 같습니다.
데이터를 분할하기 전에 탐색 연습을 위해 숫자를 더 관리하기 쉽도록 이러한 데이터의 샘플을 가져옵니다.
샘플링은 Query Builder로 쉽게 수행할 수 있는 것입니다. Tables > JMP Query Builder는 시작 대화 상자를 표시합니다. 이 경우 조인을 수행하지 않으므로 다음을 사용하십시오. DOHMH_New_York_City_Restaurant_Inspection_Results.jmp 이 시점에서 보조 테이블이 없는 기본 테이블로. Query Builder에는 Sample이라는 탭이 있습니다. "Sample this results set" 확인란을 선택하면 First를 선택할 수 있습니다. N 행 또는 무작위 N 행. 이 데이터에서 임의의 10% 샘플을 추출하여 Random에 44,815를 넣습니다. N 행. Include Columns 섹션에 모든 열을 추가한 다음 SQL을 검사합니다. Query Builder는 이 쿼리를 수행하기 위해 SQL을 자동으로 생성했습니다.
t1.CAMIS, t1.DBA, t1.BORO, t1.빌딩 선택,
t1.STREET, t1.ZIPCODE, t1.PHONE, t1."요리 설명",
t1."검사 날짜", t1."조치", t1."위반 코드", t1."위반 설명",
t1."위험 플래그", t1.점수, t1.등급, t1."등급 날짜",
t1."검사 유형", t1."연도[검사 날짜]"
FROM DOHMH_New_York_City_Restaurant_Inspection_Results t1
ORDER BY RANDOM() 제한 44815;
사용 후 무작위로 주문 () 샘플링을 위한 기능을 사용하면 이 쿼리는 데이터의 적절한 하위 집합을 생성합니다. 이것을 하위 집합으로 저장한 다음 레스토랑 인구 통계 및 위반 코드를 분리합니다. Query Builder도 여기에서 사용할 수 있습니다. 위반 코드부터 시작하십시오. 다시 말하지만 기본 테이블만 있으면 됩니다. VIOLATION CODE 및 VIOLATION DESCRIPTION을 변수 목록으로 드래그 앤 드롭한 다음 VIOLATION CODE를 다시 드래그하면 개수별로 집계하고 원하는 속성이 있는 테이블을 생성할 수 있습니다. 집계 열의 JMP 이름을 VIOLATION COUNT로 변경합니다. 열 또는 파생 열에 대한 별칭을 생성하는 이 기능은 Query Builder의 강력한 기능입니다. 그림 8과 같이 VIOLATION COUNT를 Order By 역할로 드래그하여 새로 생성된 집계 열을 기준으로 자동 정렬하도록 선택할 수도 있습니다.
그림 8. 정렬 기준 속성이 있는 위반 수로 이름이 변경된 집계 열
88개의 고유한 위반 코드만 있으면 이 결과 쿼리가 훨씬 더 간결해집니다. 이 테이블의 이름을 지정한 후 D-ViolationCodes.jmp , 티 그는 Graph Builder를 사용하여 어떤 코드가 가장 많은 기록을 가지고 있는지 탐색하기에 좋은 시기입니다. VIOLATION DESCRIPTION을 X축으로 드래그하고 VIOLATION COUNT를 Y축으로 드래그합니다. 그런 다음 VIOLATION DESCRIPTION 및 Order By VIOLATION COUNT(내림차순)를 마우스 오른쪽 버튼으로 클릭합니다. 상위 범주에만 초점을 맞추려면 2,500개 이상의 고유 레코드가 있는 위반 범주가 있는 VIOLATION COUNT에서 로컬 데이터 필터를 사용할 수 있습니다(그림 9).
그림 9. 상위 위반 수(샘플링 테이블의 고유 레코드 >2500개)
지금은 위반 표에서 벗어나 고유한 레스토랑 인구 통계에 집중할 수 있습니다. 이 시점에서 위반 설명을 삭제할 수도 있습니다. 이렇게 하면 기본 팩트 테이블에 여러 중복 행이 저장됩니다. 이러한 데이터를 구성하는 훨씬 더 간결한 방법인 VIOLATION CODE를 사용하십시오(세 글자 문자열 대 문장 길이 문자열).
다시 Query Builder를 사용하여 고유한 레스토랑 인구 통계를 제거하십시오. NYC에 같은 이름의 피자 가게가 두 개 이상 있을 가능성이 높지만 Query Builder가 이러한 상황을 처리할 수 있습니다. CAMIS 열은 고유한 레스토랑을 식별하는 데 사용할 수 있는 ID 역할을 합니다. Query Builder에서 CAMIS를 두 번 드래그합니다. 그 중 하나는 Aggregated by count로 이름이 INSPECTION COUNT로 변경되어야 합니다. 나머지 인구 통계 데이터는 DBA, BORO, BUILDING, STREET, ZIPCODE, PHONE 및 CUISINE DESCRIPTION입니다. 마지막으로 쿼리 후 스크립트로 수행될 지오코더용 ADDRESS라는 열을 계산합니다. 쿼리를 실행한 후 다음 수식이 있는 수식 열을 활용합니다.
:빌딩 || " " || :거리 || " " || :보로 || "뉴욕," || 숯 ( :우편 번호 )
이 수식은 올바른 주소를 조합합니다. 타자 :주소 << 스크립트 받기 ; 스크립트 편집기에서 쿼리 후 스크립트에 대한 열을 생성하는 데 필요한 JSL을 생성합니다. 해당 코드를 복사하여 Query Builder의 적절한 탭에 붙여넣은 다음 지오코드와의 더 나은 인터페이스를 위해 데이터를 20개 그룹으로 분할하는 열을 생성합니다. Group and Initialize Data: Sequence Data, From 1 to 20, Step 1, Repeat 1이라는 새 열을 생성한 후 스크립트를 가져와 쿼리 후 스크립트에 붙여넣을 수 있습니다. 이제 두 열이 모두 스크립트이므로 쿼리 테이블을 삭제하고 쿼리를 다시 실행할 수 있습니다. 이 데이터 테이블을 다른 이름으로 저장 D-레스토랑.jmp . 마지막 단계로 DBA, BORO, BUILDING, STREET, ZIPCODE, PHONE 및 CUISINE DESCRIPTION을 포함하여 now 팩트 테이블에서 추가 열을 삭제합니다.
이 테이블을 다른 이름으로 저장 F-검사.jmp . 이제 OpenStreetMaps.org를 사용하여 위치를 지오코딩하는 JMP File Exchange[GREGG]에서 사용할 수 있는 Xan Gregg가 만든 추가 기능으로 레스토랑 그룹을 지오코딩할 준비가 되었습니다. 이 서비스는 계산 비용이 많이 들고 실패하기 쉬우므로 분할하는 것이 가장 좋습니다. D-레스토랑 Tables > Subset을 사용하여 그룹별로. 그림 10에 표시된 이 플랫폼의 Subset By 기능은 여기에서 유용합니다.
그림 10. 레스토랑 그룹별 분할을 위한 하위 집합 테이블 플랫폼
새로 생성된 20개의 테이블은 추가 기능을 사용하여 개별적으로 지오코딩할 수 있습니다. 주소 필드는 정확한 위도와 경도를 결정하는 데 도움이 됩니다. 마지막으로 결과를 동일한 데이터 테이블에 저장합니다.
데이터 테이블을 위치가 있는 단일 차원 테이블로 되돌리려면 테이블 > 연결 기능을 사용하여 20개 그룹을 결합합니다. 이름이 붙여졌다 D-RestaurantswLocation.jmp.
이제 쿼리 빌더를 사용하여 이 테이블을 분류했으므로 가상 조인을 사용하여 다시 빌드할 수 있습니다.
먼저 두 개의 차원 테이블로 시작합니다. 레스토랑-wLocation.jmp 그리고 ViolationCodes.jmp . 위반 코드를 마우스 오른쪽 버튼으로 클릭하고 링크 ID를 선택하면 가상 조인이 시작됩니다. 열 목록에 작은 열쇠 아이콘이 나타납니다. 레스토랑 테이블로 이동하고 CAMIS에 대해 동일한 작업을 수행합니다. 가상 조인을 완료하려면 모든 검사가 있는 팩트 테이블로 이동한 다음 CAMIS 및 VIOLATION CODE 모두에 대해 링크 참조를 선택합니다.
메모리의 테이블을 물리적으로 조인하지 않고도 팩트 테이블에 모든 열이 표시됩니다. 가상 조인은 열 속성을 통해 스크립팅할 수도 있습니다.
링크 참조:
Set Property("링크 참조", 참조 테이블("D(f)-Restaurants-wLocation.jmp"));
링크 ID:
속성 설정("링크 ID", 1);
그림 11. 가상 조인
그림 11은 팩트 테이블에 부담을 주지 않고 두 차원 테이블의 열에 액세스할 수 있음을 보여줍니다.
마지막으로 가상으로 조인된 열을 활용하여 이러한 데이터를 시각화하고 탐색하는 대시보드를 구축합니다.
그림 12는 Dashboard Builder가 5개의 그래프 모음을 표시하는 방법을 보여줍니다. 그래프 중 두 개를 선택 필터로 사용하려면 Critical FLAG 및 BORO를 필터 및 계층 필터로 사용하여 Dashboard Builder의 계층 필터 템플릿으로 시작합니다. 다음으로 등급 개수 그래프, 맵의 분위별 평균 점수, 마지막으로 검사 유형별 날짜 개수 히트 맵을 사용합니다.
그림 12. 최종 NYC 검사 대시보드가 포함된 애플리케이션 빌더의 대시보드 빌더 모드
이는 가상 조인에서 제공하는 연결된 테이블을 활용하여 이러한 데이터로 만들 수 있는 시각화 유형의 예일 뿐입니다. 지오코딩된 데이터를 사용하면 예를 들어 요리별로 레스토랑 위치를 파헤칠 수도 있습니다(그림 13).
그림 13. 거리 수준 지도에 표시되는 등급별로 색상이 지정된 위치정보 지정 레스토랑
SQL 생성 및 배포
Query Builder 사용의 또 다른 주요 이점은 SQL(Structured Query Language) 생성입니다. SAS는 Proc SQL 내에서 SQL을 사용할 수 있으며 대부분의 데이터베이스는 SQL을 프로그래밍 언어로 사용하여 테이블을 조인하고 관리합니다. Query Builder의 포인트 앤 클릭 인터페이스에서 정의한 쿼리에서 SQL을 생성할 수 있습니다.
다음은 모든 차원 테이블을 조인된 테이블에 조인하기 위해 쿼리 빌더에서 만든 SQL입니다 시리즈.jmp 그리고 AllData.jmp (사례 1에서) 및 조인의 SQL 전체 조인.jmp 그리고 모든 _code.jmp 테이블. 그만큼 libname 명령문, 테이블에 대한 연관된 libname 참조 및 절차 SQL 진술이 추가되었습니다. 나머지 코드는 Query Builder에서 생성되었습니다.
대부분의 코드는 SELECT 문 내의 열 목록입니다. Query Builder를 사용하여 이러한 코드를 생성하는 것은 사용자가 SQL을 알고 있더라도 큰 도움이 됩니다. 그럴 필요가 없다면 왜 그렇게 많은 테이블과 열 이름을 입력해야 할까요?
libname 원천 '파일 위치' ;
절차 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 에서 source.AllData t1
왼쪽 OUTER JOIN 소스.시리즈 t2
에 ( t1.series_id = t2.series_id ) ;
선택하다 t1.연도, t1.기간, t1.값, t1.series_title,
t1.seasonal, 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.활동_텍스트, t2.absn_text 에서 source.dataNseries t1
왼쪽 OUTER JOIN 소스.각주 t13
에 ( t1.footnote_codes = t13.footnote_code )
왼쪽 외부 조인 소스.wkst t34
에 ( t34.wkst_code = t1.wkst_code )
왼쪽 OUTER JOIN source.vets t33
에 ( t33.vets_code = t1.vets_code )
왼쪽 외부 조인 소스.tdat t32
에 ( t32.tdat_code = t1.tdat_code )
왼쪽 외부 가입 source.sexs t31
에 ( t31.sexs_code = t1.sexs_code )
왼쪽 OUTER JOIN source.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 )
왼쪽 OUTER JOIN source.race t26
에 ( t26.race_code = t1.race_code )
왼쪽 OUTER JOIN 소스. 주기성 t25
에 ( t25.주기성_코드 = t1.주기성_코드 )
왼쪽 외부 가입 소스.pcts t24
에 ( t24.pcts_code = t1.pcts_code )
왼쪽 외부 조인 source.orig t23
에 ( t23.orig_code = t1.orig_code )
왼쪽 OUTER JOIN 소스.직업 t22
에 ( t22.occupation_code = t1.occupation_code )
왼쪽 외부 가입 source.mjhs t21
에 ( t21.mjhs_코드 = t1.mjhs_코드 )
왼쪽 OUTER JOIN source.mari t20
에 ( t20.mari_code = t1.mari_code )
왼쪽 OUTER JOIN source.look t19
에 ( t19.look_code = t1.look_code )
왼쪽 외부 조인 소스.lfst t18
에 ( t18.lfst_code = t1.lfst_code )
왼쪽 외부 조인 소스.jdes t17
에 ( t17.jdes_code = t1.jdes_code )
왼쪽 외부 조인 source.indy t16
에 ( t16.indy_code = t1.indy_code )
왼쪽 OUTER JOIN 소스 시간 t15
에 ( t15.hour_code = t1.hour_code )
왼쪽 OUTER JOIN source.hheader t14
에 ( t14.hheader_code = t1.hheader_code )
왼쪽 외부 조인 source.expr t12
에 ( t12.expr_code = t1.expr_code )
왼쪽 외부 조인 source.entr t11
에 ( t11.entr_code = t1.entr_code )
왼쪽 OUTER JOIN 소스.교육 t10
에 ( t10.education_code = t1.education_code )
왼쪽 OUTER JOIN source.duration t9
에 ( t9.duration_code = t1.duration_code )
왼쪽 외부 조인 source.disa t8
에 ( t8.disa_code = t1.disa_code )
왼쪽 외부 조인 소스.클래스 t7
에 ( t7.class_code = t1.class_code )
왼쪽 외부 조인 소스.chld t6
에 ( t6.chld_code = t1.chld_code )
왼쪽 외부 조인 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.활동_코드 = t1.활동_코드 )
왼쪽 외부 조인 소스.absn t2
에 ( t1.absn_code = t2.absn_code );
그만두다 ;
요약
분석가는 시각화 및 분석을 가능하게 하는 방식으로 구성된 하나의 테이블에 데이터가 필요합니다. 하지만, 데이터는 종종 많은 테이블(정규화됨)에서 로드, 유지 관리 및 저장하도록 구성되므로 분석가는 많은 테이블을 분석 준비가 된 하나의 테이블로 결합하고 요약해야 합니다.
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 .
[그레그] Gregg, X. (2014년 5월 28일). 지오코딩 장소 이름. 2016년 8월 18일에 검색함 https://community.jmp.com/docs/DOC-6175 .
