diff --git a/keyword/chapter01/image1.png b/keyword/chapter01/image1.png
new file mode 100644
index 0000000..14a8d29
Binary files /dev/null and b/keyword/chapter01/image1.png differ
diff --git a/keyword/chapter01/image2.png b/keyword/chapter01/image2.png
new file mode 100644
index 0000000..2b97d0a
Binary files /dev/null and b/keyword/chapter01/image2.png differ
diff --git a/keyword/chapter01/keyword.md b/keyword/chapter01/keyword.md
new file mode 100644
index 0000000..ed470dd
--- /dev/null
+++ b/keyword/chapter01/keyword.md
@@ -0,0 +1,88 @@
+- DB Join이란?
+
+  **Join** :  두 개 이상의 테이블을 엮어 하나의 결과 테이블로 만드는 것
+
+  하나의 테이블 만으로는 원하는 결과를 얻을 수 없는 경우, 두 개 이상의 테이블을 묶어서 원하는 결과를 얻기 위해 사용
+
+- Join 종류들
+
+  **INNER JOIN** : ****기준 테이블과 JOIN 테이블의 교집합
+  JOIN 조건에 맞는 행을 출력
+
+  ![image1.png](image1.png)
+
+  SELECT * FROM TableA A
+  INNER JOIN TableB B
+  ON A.key = B.key
+    
+  ---
+
+  **OUTER JOIN** : 기준 테이블의 행은 조건에 맞지 않아도 출력
+
+  LEFT, FULL, RIGHT OUTER JOIN이 있다.
+
+  ![image2.png](image2.png)
+
+  위 사진처럼 같은 OUTER JOIN이더라도 WHERE 절의 조건에 따라 집합의 형태가 달라진다.
+
+  FULL OUTER JOIN은 성능/요구⬇️ 등의 문제로 거의 사용X → MySQL 도 지원 X
+  RIGHT OUTER JOIN도 테이블 순서만 바꾸면 LEFT OUTER JOIN과 결과가 동일 → 사용⬇️
+    
+  ---
+
+  **CROSS JOIN** : 한 쪽 테이블의 모든 행과 다른 쪽 테이블의 모든 행을 조합
+  ⇒ Catesian Product, 경우의 수를 생성할 때 가장 많이 사용
+    
+  ---
+
+  **SELF JOIN** :  같은 테이블을 자기 자신과 JOIN
+
+  정해진 문법 없이, 같은 테이블을 조인하여 사용
+  같은 테이블 안에 있는 행과 행의 관계를 표현하기 위해 사용
+  (ex : 직원과 상사, 같은 점수의 학생, 더 비싼 상품 등)
+
+  참고자료
+
+  https://adjh54.tistory.com/155
+
+  https://innovation123.tistory.com/211
+
+  https://hongong.hanbit.co.kr/sql-%EA%B8%B0%EB%B3%B8-%EB%AC%B8%EB%B2%95-joininner-outer-cross-self-join/
+
+  https://yuna-story.tistory.com/164
+
+- 트랜잭션이란?
+
+  **트랜잭션** : DB의 상태를 변화시키는 하나의 논리적 작업 단위
+  하나의 외부 거래를 기록하기 위해 시스템 내부에서 완료되어야 하는 일련의 처리 동작
+
+  **ACID 원칙**
+
+  **A**tomicity(원자성)
+  트랜잭션 내의 작업은 모두 반영되거나, 모두 취소되어야 함(롤백)
+
+  **C**onsistency(일관성, 정합성)
+  트랜잭션 완료 후 DB는 일관된 상태를 유지해야 함
+
+  **I**solation(고립성, 격리성, 독립성)
+  각 트랜잭션은 서로 간섭 없이 독립적으로 수행되어야 함
+
+  **D**urability(지속성, 내구성)
+  성공한 트랜잭션은 영구적으로 반영되어야 함
+
+  *A계좌 출금과 B계좌 입금이 대표적인 예시
+
+  참고자료
+  https://learn.microsoft.com/ko-kr/windows/win32/ktm/what-is-a-transaction
+
+  https://terms.tta.or.kr/dictionary/dictionaryView.do?word_seq=058427-1
+
+- Join on 과 where의 차이점
+
+  ON : JOIN 시 두 테이블의 행을 결합하는 기준 → 행을 **붙일지 말지** 결정
+  특히 OUTER JOIN에서는 매칭 여부만 판단, 매칭X 인 기준 테이블의 행은 NULL과 함께 유지
+
+  WHERE : JOIN이 수행된 이후 결과를 필터링하는 조건 → 붙은 결과를 **남길지 말지** 결정
+  OUTER JOIN에 사용시 NULL이 포함된 행이 제거되어 결과가 INNER JOIN 처럼 변할 수 있음
+
+  INNER JOIN에서는 ON과 WHERE 모두 결과를 제한하는 역할이므로 대부분 동일한 결과가 나옴
\ No newline at end of file
diff --git a/mission/chapter01/mission.md b/mission/chapter01/mission.md
new file mode 100644
index 0000000..3aac3ec
--- /dev/null
+++ b/mission/chapter01/mission.md
@@ -0,0 +1,125 @@
+### 워크북 캡쳐
+
+![week1_green.png](week1_green.png)
+
+### 워크북 리뷰
+
+<aside>
+🌟
+
+다른 챌린저들도 나도 위와 같은 기타 조인들에 대해서는 자세히 조사하지 않은 것 같다.  그린의 워크북 덕분에 조인의 개념에서 조건의 성격에 따라 어떻게 조인이 달라지는지 명확하게 짚고 넘어갈 수 있었다.
+
+</aside>
+
+======= 미션 ======= 
+
+리뷰 작성하는 쿼리,
+* 사진의 경우는 일단 배제
+
+쿼리문
+
+<aside>
+
+사용자/가게의 ID를 1이라고 가정, 리뷰 id를 자동으로 1씩 증가하며 생성한다고 가정하면
+review 테이블의 리뷰 내용, 평점, 사용자ID, 가게ID 속성을  지정한 값을 추가하는 쿼리가 필요하다.
+
+INSERT INTO review (review_content, rating, user_id, store_id)
+VALUES (”음 너무 맛있어요~~”, 5.0, 1, 1);
+
+</aside>
+
+
+마이 페이지 화면 쿼리
+
+쿼리문
+
+<aside>
+
+사용자 테이블의 닉네임, 이메일, 휴대폰 번호, 현재 포인트 속성을 조회하는 쿼리가 필요하다.
+
+SELECT nickname, user_email, user_number, current_point  
+FROM user
+WHERE user_id = 1;
+
+</aside>
+
+
+홈 화면 쿼리
+(현재 선택 된 지역에서 도전이 가능한 미션 목록, 페이징 포함)
+
+쿼리문
+
+<aside>
+
+달성한 미션의 수를 계산해서 표시
+
+SELECT COUNT(*)
+FROM user_mission
+WHERE user_id = 1;
+
+---
+
+현재 선택된 지역에서 도전이 가능한 미션 목록, 페이징
+
+현재 선택된 지역 ‘안암동’의 지역 ID를 1이라고 가정
+지역 ID가 1인 가게 ID를 찾고, 그 ID로 미션을 찾는다. 미션들을 현재 날짜를 기준으로 시작시점과 종료시점 사이에 있는 미션/활성화 되어있는 미션을 필터링하고, 그 결과에서 가게 이름, 미션 내용, 보상 포인트, 남은 기한을 보여준다.
+
+SELECT s.store_name, m.mission_description, m.reward_point, m.end_at
+FROM store s
+JOIN mission m ON m.store_id = s.store_id
+WHERE s.location_id = 1
+AND CURRENT_DATE BETWEEN m.start_at AND m.end_at
+AND m.is_active = 1;
+
+위 SQL로 홈 화면에 필요한 정보를 찾을 수 있으나, 아직 페이징이 포함되어있지 않다.
+가게 이름, 미션 내용, 보상 포인트, 종료 기한 만으론 미션을 유일하게 식별하기 어려울 수가 있다고 판단했고, 추가로 미션 ID를 조회해서 커서로 활용하도록 한다.
+
+SELECT m.mission_id, s.store_name, m.mission_description, m.reward_point, m.end_at
+FROM store s
+JOIN mission m ON m.store_id = s.store_id
+WHERE s.location_id = 1
+AND CURRENT_DATE BETWEEN m.start_at AND m.end_at
+AND m.is_active = 1
+AND m.mission_id > ? #cursor
+ORDER BY m.mission_id ASC
+LIMIT 10;
+
+</aside>
+
+내가 진행중, 진행 완료한 미션 모아서 보는 쿼리(페이징 포함)
+
+쿼리문
+
+<aside>
+
+내가 진행중, 진행 완료한 미션을 모아서 보상 포인트, 가게 이름, 미션 내용, 성공 여부를 조회해야 한다.
+
+나의 사용자 ID를 1이라고 가정
+사용자 ID가 1이면서 상태가 완료 혹은 미완료인 사용자 미션을 찾는다. 찾은 미션의 내용, 보상포인트를 조회하고, ID로 해당 미션에 맞는 가게를 찾는다.
+
+SELECT m.reward_point, m.mission_description, um.status, s.store_name
+FROM user_mission um
+JOIN mission m ON m.mission_id = um.mission_id
+JOIN store s ON m.store_id = s.store_id
+WHERE um.user_id = 1
+AND um.status IN (’COMPLETED’, ‘NOT_COMPLETED’);
+
+마찬가지로 페이징을 위해 미션 ID를 추가로 조회하여 커서로 활용한다. 또, 완료 상태별로 묶어서 보이도록 ORDER BY stauts를 추가한다.
+
+SELECT m.mission_id, m.reward_point, m.mission_description, um.status, s.store_name
+FROM user_mission um
+JOIN mission m ON m.mission_id = um.mission_id
+JOIN store s ON m.store_id = s.store_id
+WHERE um.user_id = 1
+AND um.status IN (’COMPLETED’, ‘NOT_COMPLETED’)
+AND (
+um.status > ?
+OR (um.status = ? AND m.mission_id > ?)
+) #복합 커서
+ORDER BY um.status ASC, m.mission_id ASC
+LIMIT 10;
+
+#복합 커서 → 현재 커서의 status보다 뒤에 오는 status이거나, status가 같다면 mission_id가 더 큰 것
+status와 mission_id를 함께 커서로 사용해서 완료 상태별로 묶어서 페이징하도록 했다.
+
+</aside>
\ No newline at end of file
diff --git a/mission/chapter01/week1_green.png b/mission/chapter01/week1_green.png
new file mode 100644
index 0000000..94b8cbd
Binary files /dev/null and b/mission/chapter01/week1_green.png differ