[데이터 분석 부트캠프] 데이터 분석가 필수 Tool SQL (6)

1.  foreign key (제약조건)

• foreign key는 일종의 제약조건에 해당하기 때문에 데이터를 추가하거나 삭제할 때 ‘데이터 무결성’에 어긋나면 에러를 일으킴
• 데이터 무결성 = 데이터가 문제없이 잘 들어가 있다는 의미. 즉, 데이터도 순서대로 넣어야 하고, 순서대로 삭제해야 함(그래서 제약조건이라고 하는 것)
  • foreign key를 생성할 때 어떤 테이블을 참조하는지도 명시하는데, 참조대상이 되는 테이블(A)에 없는 key값을 참조하는 쪽의 테이블(B)에서 추가한다거나, 반대로 참조하는 쪽 테이블(B)에는 key값이 남아있는데 참조대상이 되는 테이블(A)에서 해당 key값을 삭제하려고 하면, 결국 동일한 상황이 되고, 같은 이유로 에러를 발생함

 

2. JOIN

• JOIN하면, 두 테이블이 오른쪽으로 붙는다(이것만 기억!)

⌘ INNER JOIN

• INNER JOIN이라면 A, B 순서 상관없음
• JOIN한 이후 where절 등을 쓸 때 컬럼명이 양쪽 테이블에 있는게 아니라, 한쪽에만 있다면 굳이 테이블명을 컬럼명 앞에 붙여줄 필요가 없음
• INNER JOIN은 양쪽에 다 있는 경우에만 join의 row로 들어가므로 한쪽에만 있는 건 다 조건에서 빠지게 됨

⌘ LEFT OUTER JOIN, RIGHT OUTER JOIN

• OUTER JOIN은 INNER JOIN과 달리 왼쪽, 오른쪽을 바꾸면 결과가 달라질 수 있음

3. 서브쿼리

⌘ 서브쿼리

• 대부분의 서브쿼리는 JOIN으로 해결이 가능하고, 더 깔끔하다고 함. 그래서 서브쿼리 실습문제들은 JOIN을 쓴 버전과 서브쿼리를 쓴 버전을 모두 쿼리문 작성했음.
• 아래 코드처럼 서브쿼리에서 메인 FROM절에는 위의 SELECT 내의 컬럼이 들어있는 테이블을 쓴다는게 힌트

# join ver.
SELECT main_category, COUNT(*)
FROM items
JOIN ranking
ON items.item_code = ranking.item_code
WHERE dis_price >= 100000
GROUP BY main_category;

# sub query ver.
SELECT main_category, COUNT(*)
FROM ranking -- 위의 SELECT에 들어가는 컬럼이 들어있는 테이블을 써야 한다는게 힌트
WHERE item_code in (SELECT item_code FROM items 
	WHERE dis_price >= 100000)
GROUP BY main_category;

#

# join ver.
SELECT sub_category, COUNT(*)
FROM ranking
JOIN items
ON items.item_code = ranking.item_code
WHERE items.dis_price >= 200000
GROUP BY sub_category;

# join 필요없음
SELECT sub_category, COUNT(*)
FROM items
WHERE items.dis_price >= 200000
GROUP BY sub_category;

# sub query ver.
SELECT sub_category, COUNT(*)
FROM ranking
WHERE item_code in (SELECT item_code FROM items 
	WHERE dis_price >= 200000) -- item_code로 제약을 건다고 표현하심
GROUP BY sub_category;

 

 

정리

확실히 비슷한 문제를 반복적으로 푸니 확실히 알고 넘어간다.

그래서 여러가지 방식으로 문제를 풀어보고 서로 결과가 같은지도 확인하는 과정에서 값이 다르면 원인을 찾으면서도 많은 부분을 확실하게 알고 넘어가게 되는 듯하다.

예를 들어 위의 마지막 실습 문제 중 join version은 사실 JOIN이 필요없는 문제였는데 그렇다곤 해도 join을 안했을 때랑 값이 차이가 나는건 이상했다. 결국 알게 된 사실은 ranking 테이블 쪽의 item_code는 unique하지 않다는 사실이었고, 하나의 상품이 여러 카테고리에 중복적으로 포함되어 있기 때문이었다. 그 때문에 JOIN을 쓰는 순간 양쪽에 존재하는 item_code를 중심으로 테이블이 합쳐지면서 중복된 만큼의 row 수도 늘어났다.(최대는 5번까지 중복된 item_code가 있었다)

이렇게 원인을 찾기 위해 무엇을 어떻게 볼지 보는 과정 자체가 버퍼링 없이 착착 진행된다고 느껴졌고, 데이터는 막연히 내 감이나 경험으로 믿고 쓰는게 아니란 사실도 인지할 수 있었다.