SQL 19

공백이 들어있는 필드 이름을 사용하기 위해서 더블 쿼트 " " 로 감싸주어야 한다. 이런 방식으로 필드 이름을 지으면 사용할 때도 " "로 감싸야 해서 번거롭다. value값이 NULL이면 뒤에 있는 숫자를 반환한다. COALESCE( value, 0 ) 콜레스

Boolean 값에서 항상 True False 값만 있는 것이 아니라 Null값도 존재할 수 있다. Flag is True = Flag is not False 만약 Flag에 Null 값이 없고 오직 True, False로만 이루어져 있다면 이 식이 맞지만 Null값이 존재할 경우 not False가 반드시 True라고 할 수 없다. flag가 식에 해당되면 1을 더하는 문장을 실행한다. CASE WHEN flag = True THEN 1 END 여기에 COUNT() true_cnt1으로 출력한다. NULL의 비교와 연산은 항상 IS, IS NOT으로 수행한다. 만약에 =, !=, 로 수행하면 잘못된 결과가 나온다.

JOIN 두 개 이상의 테이블들을 공통 필드를 통해 merge 하는데 사용된다. 스타 스키마로 구성된 테이블들로 분산되어 있던 정보를 통합할 수 있다. Join의 문법 SELECT A.*, B.* FROM raw_data.table1 A ( ) JOIN raw_data.table2 B ON A.key1 = B.key1 and A.key2 = B.key2 WHERE A.ts >= '2019-01-01'; ( ) 괄호 안에는 JOIN의 종류에 따라 생략 될 수도 있고 INNER, LEFT, RIGHT, FULL, CROSS 가 들어갈 수 있다. JOIN 할 때 고려해야 하는 점 - 중복 레코드가 없어야 한다. - Primary Key의 유니크함이 보장되어야 한다. - JOIN 하는 테이블 간의 관계를 명확히..

adhoc 이라는 폴더는 DB 사용자가 실험을 하거나 새로운 테이블을 만들어 보거나 하는 폴더이다. temp 폴더와 쓰임새가 비슷하다. 이 adhoc이라는 폴더에 새로운 테이블을 만들어서 데이터 레코드를 카피해 보겠다. 만약 테이블이 이미 존재한다면 DROP 하는 명령어를 사용한다. 그리고 새롭게 테이블을 만든다. FROM은 이미 존재하는 테이블 뿐만 아니라 동적인 범위를 정할 수 있다. session_timestamp A, user_session_channel B를 조인한 테이블에서 B의 모든 내용과 A의 ts를 합쳐서 seoann_session_summary로 만들었다. adhoc.seoann_session_summary 에서 ts와 userid가 함께 존재하기 때문에 간단히 mau를 찾을 수 있다...

가장 많이 사용된 채널을 찾는다. raw_data 스키마에서 user_session_channel 테이블 안에 가장 많이 사용된 채널을 찾는다. 여기서 많이 사용되었다는 기준은 세션이 만들어진 수, 유저의 아이디 수 두가지로 찾을 수 있다. 모호한 기준이 주어지면 정확히 하기 위한 질문을 해야 한다. AS count라는 새로운 Column을 만들어낸다. 유저 아이디는 기본키가 아니기 때문에 여러개 있을 수 있다. 세션을 많이 만들었다면 수를 세었을 때 가장 많은 수의 Record가 있을 것이다. 월별 사용자 수를 위해 join을 사용하여 두개의 테이블을 inner join 한다. session_timestamp 는 A, user_session_channel은 B 세션 아이디를 기준으로 두 개의 테이블을 ..

SQL 연결은 다음과 같다. sql을 로드하고 주소로 연결한다. %sql postgresql://guest:사용자 아이디@주소:서버/db명 guest로 접속한다. SELECT의 *는 전체를 의미한다. FROM 스키마.테이블; 연속으로 명령을 하고 싶을 때 반드시 세미콜론을 붙인다. DISTINCT는 유일한 밸류를 선택한다.

관계형 DB 관계형 데이터 베이스는 2단계로 구성된다. 가장 밑단에는 테이블이 존재 테이블은 데이터베이스 (스키마)라는 폴더 밑으로 구성된다. 테이블의 구조 (테이블 스키마) 테이블은 레코드(행)들로 구성되었다. 레코드는 하나 이상의 필드(열)로 구성되었다. 필드는 이름과 타입과 속성으로 구성되었다. Star Schema 스타 스키마는 데이터 웨어하우스 스키마 중 가장 단순한 종류의 스키마 한 개의 사실 테이블과 주 키 및 각 차원과 추가적인 사실들로 이루어진 스키마이다. 스타 스키마라는 이름은 스키마 다이어그램이 별모양이라 해서 붙인 이름이다. Denormalized Schema 하나의 데이터 베이스에 하나의 테이블을 두고 모든 데이터를 몰아 넣는것 웹서비스 사용자/세션 정보 사용자 ID - 웹서비스에..

관계형 데이터 베이스 구조화된 데이터를 저장하고 질의할 수 있도록 해주는 스토리지 - 엑셀 스프레드 시트 테이블에는 Column 열, Record 행이 존재한다. Production Database OLTP Online Transaction Processing MySQL, PostgreSQL, Oracle 빠른 속도에 집중한다, 서비스에 필요한 정보를 저장한다 웹서비스나 앱에 바로 연결되어 사용된다. Data Warehouse OLAP Online Analytical Processing Redshift, Snowflake, BigQuery 처리 데이터 크기에 집중한다, 데이터 분석 혹은 모델 빌딩을 위해 데이터를 저장한다. 보통 프로덕션 데이터베이스를 복사하여 데이터 웨어하우스에 저장한다. 속도는 중요하..