[10주차] 심규창 학습 PR 제출합니다.

week10/심규창.md

@@ -0,0 +1,106 @@
+# 10주차 학습 PR
+
+이번 주는 살짝 쉬어가는 느낌으로 실습 PR은 별도로 없고, 
+H2 Database를 설치해오시면 좋을 것 같습니다!
+
+## Indexing이란?
+(clustering index, secondary index)
+> Index: DB에서 수많은 데이터에 대해 검색 속도를 향상시켜 주기 위한 목차의 개념  
+> Data Block: DB에서 데이터를 저장하는 가장 작은 단위의 개념
+
+> - Index가 없는 상태에서 많은 데이터에 대한 조회가 필요하다면 하나하나 비교해서 데이터를 찾아야 하기 때문에 속도가 굉장히 느리다.
+> 이를 보완하기 위해 각 데이터에 Index를 매겨 데이터 검색 등의 작업 속도를 빠르게 할 수 있다. Index는 데이터와 별개로 저장되기 때문에
+> Index를 통해 더 많은 데이터를 조회할 수 있다.  
+> - Index를 사용하면 속도는 빨라지지만 Index의 순서가 섞인다면 데이터 추가 등의 작업에서 문제가 발생할 수 있다. 이러한 Indexing 방법은
+> 크게 Clustering Index, Secondary Index로 구분된다.
+>> 1. Clustering Index: DB 안에서 PK를 지정하는 경우 Clustering Index  
+>> (1) 테이블에서 1개만 존재한다.  
+>> (2) 데이터가 정렬된 상태로 저장된다.
+>> (3) index는 Data Block의 첫 번째 record의 주소를 갖는다.
+>>    1. index를 통해 Data Block에 접근 가능하기 때문에 Secondary Index 보다 빠르다.
+>> 2. Secondary Index: PK 이외에 정렬 기준이 있는 경우 Secondary Index  
+>> (1) 테이블에서 여러개 존재할 수 있다.  
+>> (2) 데이터가 정렬되지 않은 상태로 저장된다.  
+>> (3) index가 모든 데이터 record의 주소를 알아야 한다.
+------------------------
+## DB의 Relationship(1:1, 1:m, n:m)
+> Relationship: DB 안에서 Data(Table, Entity 등)들이 서로 연관된 상태  
+> 1. 정의에 따른 관계: 각각의 Data를 정의하는 데 연관성이 필요한 경우
+> 2. 동작에 따른 관계: 하나의 Data가 다른 Data(동작)를 행하는 경우  
+>
+> 관계 차수: Relationship에 참여하는 Data의 개수(1:1 / 1:N / N:M)
+
+> DB에서의 관계는 1:1, 1:n, 1:m으로 나타낼 수 있다. 각각 DB Table이 연결을 갖는 개수를 나타내는 데 모든 Table은
+> 여러 Table을 참조할 수 있고 참조 당할 수 있다. 또한 Table 안에서의 PK가 다른 Table을 참조하기 위한 FK가 될 수 있다.
+-------------------------
+## JPA 엔티티의 생명 주기
+![jpa entity lifecycle](https://github.com/COW-edu/COW-Spring-2/assets/132640569/7ae38480-fd21-4c13-9124-288ba8adfdf3)  
+> 영속 상태와 비영속 상태: 영속성 Context에서 관리되는 지에 대한 여부
+> 준영속 상태: 영속성 Context에 저장되어 있다가 분리된 상태(영속 상태에서의 변경 감지 등 불가)
+
+> JPA Entity는 비영속, 준영속, 영속 상태를 갖는다. 처음 객체가 생성되었을 때는 영속성 Context에 저장되지 않기 때문에
+> 비영속 상태를 갖는다. 이후 EntityManager를 통해 Entity를 영속 Context에 저장하게 되면 영속 상태로 변한다. detach를 통해
+> 영속 상태의 Entity를 준영속 상태로 바꿀 수 있는데 이때 영속 상태일 때의 1차 캐시나 쓰기 지연 저장소에 저장된 Query 등이 삭제된다. 
+> 준영속 상태의 Entity는 병합(merge)을 통해 다시 영속 상태로 변환할 수 있다.
+
+## @Id, @GeneratedValue
+> @Id: Entity의 속성이 PK임을 지정하는 어노테이션  
+> @GeneratedValue: Entity의 PK를 자동으로 생성해주는 어노테이션   
+> (1) Auto: DB에 따라 아래 3개의 방법 중 하나를 선택하는 방법  
+> (2) Identity: DB에 PK 지정을 위임하는 방법(DB에 의존적인 성격 - H2, MySQL, SQL Server 등에 사용)  
+> (3) Sequence: DB Sequence를 사용해 PK를 지정하는 방법(DB에 의존적인 성격 - H2, DB2, Oracle 등에 사용)  
+> (4) Table: DB Table을 사용해 PK를 지정하는 방법(모든 DB에서 적용 가능)
+-----
+# 9주차 세션 정리(추가 과제)
+
+## DB 트랜잭션이란?
+> DB Transaction은 DB의 상태를 변화시키는 최소한의 작업 단위이다. DB에서 상태가 변하는 것은
+> Query를 통해 데이터를 저장, 조회, 수정, 삭제하는 등의 작업을 의미한다. Transaction은 개발자가 정하는
+> 단위로 하나의 로직을 처리하기 위해 여러 Query를 작성할 때, 작성된 모든 Query가 성공적으로 완료되면 하나의 Transaction으로 정의한다.
+
+> 또한 DB Transaction은 다음과 같은 특징을 가진다.  
+>> 1. 원자성: Transaction은 모두 반영되거나 반영되지 않는 경우만 존재한다.
+>> 2. 일관성: Transaction의 처리 결과는 일관적이어야 한다.
+>> 3. 독립성: 각각의 Transaction은 서로에게 영향을 줄 수 없다.
+>> 4. 지속성: Transaction이 성공적으로 끝나면 처리에 대한 결과는 영구적으로 저장된다.  
+
+> 하나의 Transaction은 Commit or Rollback의 결과를 갖는다.
+> Transaction에 대한 처리가 성공적으로 완료되고 일관성을 가질 때는 Commit, 처리 도중 비정상적으로
+> 완료되어 원자성이 깨진 경우 Rollback 결과를 갖는다. Rollback의 경우 Transaction의 시작 지점으로 돌아간다.
+-------------------------
+## JPA의 1차 캐시, 2차 캐시
+> 캐시는 반복해서 사용되는 데이터에 대해 빠르게 사용할 수 있는 방법이다. 일반적으로 데이터는 DB에서 받아오지만 DB 접근 시간이
+> 오래 걸리거나 반복적으로 동일한 결과를 반환하는 경우에는 캐시를 사용하는 것이 더 효율적이다. 이렇게 캐시 영역에서 데이터를 받아오는 과정을
+> 캐싱이라 한다. Spring에서의 캐시는 영속성 Context를 통해 사용 가능하다.  
+>>Spring에서 같은 데이터를 대상으로 같은 동작을 반복적으로 요청할 경우 실제 쿼리는 하나의 쿼리만이 실행된다. 그 이유는 Spring에서는
+> 첫 쿼리에 대한 결과를 1차 캐시에 저장하고 같은 요청이 들어올 때 재사용하기 때문이다. 하지만 1차 캐시는 Transaction 내에서만 동작하며 영속성
+> Context가 종료되면 저장된 데이터도 소멸한다.
+> 
+>> Spring의 2차 캐시는 Application 범위에서 동작한다. 1차 캐시와 다르게 Application이 종료될때까지 유지되고 저장한 데이터를 복사해
+> 복사본 데이터를 반환한다. 하지만 Application 전체 대상이기 때문에 여러 스레드가 동시에 값을 사용할 때 동시성에 대한 문제가 발생할 수 있다.
+
+![caching](https://github.com/COW-edu/COW-Spring-2/assets/132640569/99ab34b9-62d7-4daa-82ad-b62753652fe8)
+> - 캐싱 동작 방식
+>1. 최초 쿼리 동작 시 데이터 반환 
+>2. 쿼리 동작에 대해 1차 캐시가 존재한다면 1차 캐시의 결과 반환 
+>3. 1차 캐시에 데이터가 없지만 2차 캐시에 존재하는 경우 2차 캐시에서 반환
+----------------
+## JPA의 변경 감지
+> 영속성 Entity: 영속성 Context에 속한 Entity  
+> 스냅샷: DB의 데이터가 영속성 Context에 저장될 때의 정보(Entity 영속화의 최초 정보)  
+> Flush: 영속성 Context의 변경 내용을 DB에 반영하는 과정(영속성 Context와 DB의 상태를 맞추는 것)
+
+> 변경 감지는 Transaction Commit시 영속성 Entity에 대해 update해주는 기능이다. 
+> Transaction Commit이 일어날 때 스냅샷과 바뀐 Entity를 비교해 update한다. Spring에서는 @Transactional 어노테이션을 통해
+> 메서드를 묶고 해당 메서드가 종료될 때 Transaction Commit이 발생한다.(이때 Flush도 자동으로 작동)  
+> - 변경 감지의 대상은 영속성 Entity이지만 준영속 Entity도 변경 감지가 가능하다. Entity의 모든 속성에 대한 변경 감지는 병합(merge), Entity의 속성에 대한
+> 부분 수정은 Dirty Checking 방식이 있다.
+>> 1. Dirty Checking: Service 계층에서 update 메서드를 추가해 데이터를 수정하는 방식(필요한 속성만 수정)
+>> 2. 병합(Merge): em.merge(Entity) 메서드를 통해 영속 Entity의 값을 파라미터로 전달받은 준영속 Entity의 값으로 수정하고 영속성 Entity를 반환해 저장하는 방식(Entity의 모든 속성 필요)
+----------------
+## JPA의 쓰기 지연
+> Transaction에서 생기는 모든 쿼리는 쓰기 지연 저장소에 쿼리가 저장된다. 저장된 쿼리는 Transaction Commit 시점에
+> DB로 전달되는 데 이를 통해 하나의 Transaction이 DB에 접근하는 시간이 감소하는 이점을 얻는다. 일반적으로 쿼리를 생성하면
+> 바로 DB에 전달되지만 이 과정은 DB와의 연결 ~ 해제 과정이 반복되기 때문에 쓰기 지연 저장소를 통해 보다 효율적으로 DB에 접근할 수 있다.
+
+>