1주차 - 엘라/변지현 워크북 과제 제출

.github/config/pr-validation.json

@@ -1,6 +1,8 @@
 {
   "owners": [],
   "userToBranch": {
-
+    "muxlpaq": "hagyeong",
+    "jihyun": "ella",
+    "minji-jeong516": "minji"
   }
-}
+}

week00/keyword/keyword.md

@@ -0,0 +1,146 @@
+- 외래키
+    - 외래 키(Foreign key): 한 테이블의 컬럼 중 다른 테이블의 행을 식별할 수 있는 키, 즉 두 테이블을 서로 연결해주는 연결 고리
+    - 주요 속성
+        - 중복 허용: 외래 키 값은 테이블 내에서 여러 번 나타날 수 있다.
+        - NULL 허용: 상황에 따라 외래 키 값은 비어있을 수 있다.
+        - 참조 무결성: 외래 키 값은 반드시 참조되는 테이블의 기본 키 값 중 하나이거나 NULL이어야 한다.
+    - 장점
+        - 데이터 무결성 유지: 잘못된 데이터가 들어오는 것을 원천 봉쇄한다.
+        - 데이터 일관성: 테이블 간의 관계가 명확해지므로, 데이터가 어떻게 연결되어 있는지 파악하기 쉽고 관리가 용이하다.
+        - 중복 최소화: 데이터를 여러 테이블로 쪼개어 저장(정규화)할 수 있게 해주어 저장 공간을 효율적으로 사용한다.
+    - 단점
+        - 성능 저하: 데이터를 입력, 수정, 삭제할 때마다 DB가 참조 무결성을 매번 확인해야 하므로 속도가 약간 느려질 수 있다.
+        - 설계의 복잡성: 테이블이 많아지고 관계가 얽히면 모델링이 복잡해진다.
+        - 삭제/수정의 번거로움: 부모 데이터를 지우고 싶어도 자식 데이터가 물려있으면 지우기 까다롭다. (이때 CASCADE 같은 옵션 설정이 중요)
+    - 외래 키 옵션(Constraint): 부모 테이블의 데이터가 변할 때 자식 테이블이 어떻게 반응할지 정할 수 있다.
+        - ON DELETE/UPDATE CASCADE: 부모가 지워지거나 바뀌면 자식도 자동으로 같이 지워지거나 바뀐다.
+        - ON DELETE SET NULL: 부모가 지워지면 자식의 외래 키 값을 NULL로 바꾼다.
+        - ON DELETE RESTRICT: 자식이 하나라도 남아있으면 부모를 절대 못 지우게 막는다.
+- 기본키
+    - 기본 키(Primary Key): 테이블의 각 행을 유일하게 식별할 수 있는 하나 이상의 컬럼 집합으로, 한 테이블에는 단 하나의 기본 키만 설정할 수 있다.
+    - 속성
+        - 유일성: 테이블 내에 같은 기본 키 값을 가진 행이 두 개 이상 존재할 수 없다.
+        - 최소성: 행을 식별하는 데 꼭 필요한 최소한의 컬럼으로만 구성되어야 한다.
+        - NULL값을 가질 수 없다
+    - 종류
+        - 자연 키: 비즈니스 모델에서 이미 존재하는 속성(예: 주민등록번호, 이메일, 학번 등)
+        - 대리 키: 비즈니스와 상관없이 DB 관리를 위해 인위적으로 부여한 번호(예: id, user_no 등)
+            - 실무에서는 개인정보보호나 유연성을 위해 id같은 대리 키를 PK로 쓰는 경우가 훨씬 많다.
+    - 장점
+        - 데이터 무결성 보장: 중복 데이터 입력을 원천 차단하여 데이터의 정확성을 지킨다.
+        - 검색 속도 향상: DB는 기본 키에 대해 자동으로 인덱스를 생성하므로, 특정 데이터를 찾을 때 매우 빠르다.
+        - 관계 설정의 기준: 외래 키가 참조하는 대상이 되어 테이블 간의 관계를 맺어준다.
+    - 단점
+        - 변경의 어려움: 한 번 PK로 설정된 값은 바꾸기가 매우 어렵다.(바꾸면 연결된 모든 FK 데이터가 꼬임)
+        - 인덱스 관리 비용: 데이터가 삽입/삭제될 때마다 인덱스를 재구성해야 하므로 미세한 오버헤드가 발생한다.
+        - 설계 부담: 처음에 PK를 잘못 잡으면 나중에 DB 구조 전체를 뜯어고쳐야 할 수도 있다.
+    - 기본 키 vs 고유 키
+        - 개수: 기본 키는 테이블 당 1개만 가능, 고유 키는 여러 개 설정 가능
+        - NULL 허용: 기본 키는 절대 불가, 고유 키는 가능
+        - 목적: 기본 키는 행의 식별자(대표), 고유 키는 중복 값 방지(보조)
+- ER 다이어그램
+    - ER 다이어그램(Entity-Relationship Diagram, ERD): 데이터베이스를 설계할 때 데이터들 간의 관계를 그림으로 나타낸 설계도
+    - ERD의 3대 핵심 요소
+        - 엔터티(Entity, 개체): 관리하고자 하는 ‘대상’으로 보통 TV, 학생, 상품 등 명사형이다.(DB의 테이블이 됨)
+        - 속성(Attribute): 엔터티가 가진 ‘상세 정보’이다. (DB의 컬럼이 됨)
+        - 관계(Relationship): 엔터티 간의 ‘연결 상태’이다. (보통 동사형으로 표현됨)
+    - 관계의 종류
+        - 1:1 관계: 한 명의 유저는 하나의 프로필만 가진다.
+        - 1:N 관계: 한 명의 유저는 여러 개의 게시글을 작성한다.
+        - N:M 관계: 학생은 여러 강의를 듣고, 강의도 여러 학생이 듣는다. (중간 테이블이 필요)
+    - ERD 작성의 장점
+        - 시각화: 복잡한 데이터 구조를 한눈에 파악할 수 있어 팀원과 소통하기 좋다.
+        - 설계 오류 방지: 실제로 코딩하기 전에 중복된 데이터나 잘못된 관계를 미리 찾아낼 수 있다.
+        - 문서화: 프로젝트가 커졌을 때 새로운 개발자가 합류하면 ERD만 보고도 전체 시스템을 이해할 수 있다.
+- 복합 키
+    - 복합 키: 하나의 컬럼만으로는 행을 유일하게 식별할 수 없을 때, 두 개 이상의 컬럼을 합쳐서 만든 기본키
+    - 특징
+        - 유일성 유지: 결합된 값의 조합은 테이블 내에서 유일해야 한다.
+        - 최소성 유지: 식별을 위해 꼭 필요한 컬럼만 묶어야 한다.
+        - 외래키 활용: 다른 테이블에서 이 테이블을 참조하려면, 복합키로 묶인 모든 컬럼을 외래키로 가져가야 한다.
+    - 장점
+        - 비즈니스 의미 반영: 데이터 간의 관계를 직관적으로 보여준다.(별도의 ID 생성 없이 데이터 자체로 식별 가능)
+        - 불필요한 컬럼 방지: 인위적인 id 컬럼을 만들지 않아도 된다.
+    - 단점
+        - 구현의 복잡성: JPA 같은 프레임워크를 쓸 때 복합키를 설정하려면 별도의 클래스를 만들어야 하는 등 코드가 복잡해진다.
+        - 인덱스 크기: 여러 컬럼을 묶어 인덱스를 생성하므로 단일 키보다 용량을 더 차지할 수 있다.
+        - 확장성 저하: 나중에 요구사항이 바뀌어 키 구조를 변경해야 할 때 수정 범위가 넓어진다.
+    - 실무에서는?
+        - 복합키 대신 id같은 대리키를 기본키로 잡는 것을 선호함
+- 연관관계
+    - 연관관계(Relationship): 엔터티 간의 논리적인 연결을 의미
+    - 연관관계의 다중성(Cardinality): 한 쪽 엔터티의 데이터가 상대 쪽 엔터티의 데이터와 몇 개씩 연결될 수 있는 지를 나타낸다.
+        - 1:1(일대일 관계): 어느 쪽에서 봐도 상대 데이터가 딱 하나만 연결되는 관계이다.
+            - 예: 사용자와 사용자 설정. 한 명의 유저는 하나의 설정값만 가집니다.
+            - 구현: 한 쪽 테이블에 상대의 PK를 외래키로 두고, 그 외래키에 UNIQUE 제약 조건을 겁니다.
+        - 1:N(일대다 관계): 한 쪽은 하나인데, 반대쪽은 여러 개와 연결될 수 있는 관계
+            - 예: 부서와 사원. 한 부서에는 여러 사원이 소속되지만 한 사원은 보통 한 부서에만 소속된다.
+            - 구현: 다(N)쪽 테이블에 외래키를 둔다. (사원 테이블에 부서 ID를 저장)
+        - N:M(다대다 관계): 양쪽 모두 상대 데이터와 여러 개씩 연결될 수 있는 관계
+            - 예: 학생과 강의. 학생은 여러 강의를 듣고, 강의도 여러 학생이 듣는다.
+            - 구현: DB에서는 직접 구현이 불가능해, 중간에 연결 테이블을 만들어 1:N, N:1 관계로 풀어낸다.
+    - 연관관계의 방향성
+        - 단방향: 한 쪽 엔터티만 상대방을 알고 있는 상태
+            - 예: 게시글은 작성자를 알지만, 작성자 객체는 자신이 쓴 게시글 목록을 들고 있지 않음
+        - 양방향: 양쪽 엔터티가 서로를 참조하고 있는 상태
+            - 실제 DB 테이블 관계는 항상 양방향에 가깝지만, 코드상에서는 관리가 필요
+    - 연관관계의 주인
+        - 보통 외래키가 있는 쪽(N)이 주인이 된다. 자식 테이블
+            - 누가 수정 권한을 가졌는가?: 주인이라는 말은 이관계를 수정하거나 끊을 수 있는 실질적인 힘이 누구에게 있는가?를 의미. 즉, 외래키를 직접 주무를 수 있는 쪽은 자식 테이블이기 때문에 그쪽이 연관관계의 주인이 된다.
+        - 주인이 아닌 쪽은 조회만 가능하고, 데이터를 직접 수정하거나 삭제해도 DB의 외래키 값에 영향을 주지 못하게 설계한다.
+- 정규화
+
+    [정보처리 실기_데이터베이스06강_정규화](https://youtu.be/RXQ1kZ_JHqg?si=f0OPsoOWnJXSbqca)
+
+    - 정규화: 데이터베이스 설계에서 중복을 최소화하고 데이터의 일관성을 유지하기 위해 테이블을 분해하는 과정
+    - 목적: 이상 현상 방지
+        - 삽입 이상: 새 데이터를 넣고 싶은데, 원치 않는 정보까지 같이 넣어야 하는 상황
+        - 삭제 이상: 특정 정보를 지웠는데, 꼭 필요한 다른 정보까지 같이 삭제되는 상황
+        - 갱신 이상: 중복된 데이터 중 일부만 수정되어 데이터가 서로 안 맞는 상황
+    - 정규화 단계
+        - 제1정규형(1NF): 원자값
+            - 규칙: 각 컬럼은 하나의 값만 가져야 한다.
+            - 예: ‘취미’ 컬럼에 축구, 농구처럼 두 개가 들어있으면 안된다. 따로 행을 나누거나 테이블을 분리해야 한다.
+        - 제2정규형(2NF): 부분 함수 종속 제거
+            - 규칙: 기본키가 복합키일 때, 기본키의 일부분에만 종속되는 컬럼이 있으면 안된다.
+            - 예: [학번, 과목코드]가 PK인데, ‘학생이름’은 ‘학번’에만 의존하는 경우 학생 테이블을 따로 빼야한다.
+        - 제3정규형(3NF): 이행 함수 종속 제거
+            - 기본키가 아닌 컬럼들끼리 서로 의존하면 안된다. (A→B→C 관계 제거)
+            - 예: 학번(PK) → 학과코드 → 학과이름. 여기서 학과이름은 학번이 아니라 학과코드에 의존하므로 학과 테이블을 따로 빼야한다.
+        - BCNF: 모든 결정자는 후보키여야 한다.
+            - 기본키가 아닌 일반 컬럼이 기본키의 일부를 결정하고 있는 상황 해결
+    - 정규화의 장단점
+        - 데이터 구조
+            - 장점: 중복이 제거되어 저장 공간이 절약됨
+            - 단점: 테이블이 많아져서 구조가 복잡해짐
+        - 무결성
+            - 장점: 데이터 수정 시 일관성이 잘 유지됨
+            - 데이터를 합쳐서 볼 때 JOIN을 많이 써야함
+        - 성능
+            - 삽입/수정/삭제 속도가 빨라짐
+            - 조회 시 JOIN 때문에 성능이 느려질 수 있음
+
+- 반 정규화
+    - 반정규화: 정규화된 엔터티, 속성, 관게를 시스템의 성능 향상과 개발 운영의 단순화를 위해 의도적으로 중복, 통합, 분리하는 데이터 모델링 기법
+        - 조회 속도를 높이기 위해 데이터의 무결성을 조금 포기하는 것
+    - 목적
+        - JOIN 오버헤드 해결: 테이블이 너무 쪼개져 있으면 데이터를 하나 가져올 때마다 수많은 JOIN이 발생해 쿼리 성능이 급격히 떨어진다.
+        - 계산 로직 중복 방지: 매번 같은 집계 함수를 실행하는 게 부담될 때, 결과값을 미리 컬럼에 저장해둔다.
+        - 쿼리 단순화: 쿼리가 너무 복잡해지면 개발자가 실수할 확률이 높고 유지보수가 힘들다.
+    - 반정규화 기법
+        - 테이블 통합
+        - 테이블 분할
+        - 중복 속성 추가
+    - 반정규화 절차
+        1. 정규화 수행
+        2. 성능 테스트
+        3. 대안 검토
+        4. 반정규화 적용
+    - 장단점
+        - 성능
+            - 장점: 조회 속도가 비약적으로 빨라짐
+            - 단점: 삽입/수정/삭제 시 데이터 처리 비용 증가
+        - 유지보수
+            - 장점: 쿼리가 단순해져 개발 생산성 향상
+            - 단점: 데이터 불일치 위험 발생
+        - 공간: 중복 데이터로 인해 저장 공간 낭비

week00/mission/mission.md

@@ -0,0 +1 @@
+![1주차 미션 ERD](./image.png)