면접카타 24.03.29.(금)
3. RDBMS의 정규화에 대해 설명해주세요.
관계형 데이터베이스에서 중복을 최소화하게 데이터를 구조화하는 프로세스를 정규화(Normalization)라고 한다. 데이터베이스 정규화의 목표는 이상이 있는 관계를 재구성하여 작고 잘 조직된 관계를 생성하는 것에 있다. 일반적으로 정규화란 크고, 제대로 조직되지 않은 테이블과 관계들을 작고 잘 조직된 테이블과 관계들로 나누는 것을 포함한다. 정규화의 목적은 하나의 테이블에서의 데이터 삽입, 삭제, 변경이 정의된 관계로 인하여 데이터베이스의 나머지 부분들로 전파되게 하는 것이다.
RDBMS 정규화 심층 분석
1. 개요
RDBMS 정규화는 데이터베이스 설계의 핵심적인 과정으로, 데이터 중복을 최소화하고 데이터 무결성과 효율성을 극대화하기 위한 체계적인 방법입니다. 이를 통해 데이터베이스 구조의 불필요한 복잡성을 제거하고, 이상 현상 발생 가능성을 낮추며, 데이터 접근 및 관리 작업을 간소화할 수 있습니다.
2. 정규화 단계 및 주요 개념
2.1 1차 정규화 (1NF)
* 정의: 모든 속성이 원자값으로 구성되어야 합니다. 즉, 분할 불가능한 최소 단위의 데이터만 허용됩니다.
* 중요 개념:
* 원자값: 분할 불가능한 최소 단위의 데이터 (예: 이름, 나이, 전화번호)
* 복합 속성: 여러 원자값을 포함하는 속성 (예: 주소, 취미 목록)
* 분해: 복합 속성을 여러 원자값 속성으로 분리하는 과정
* 예시:
* 비정규화: 고객(고객ID, 이름, 주소(도시, 구, 번지))
* 1NF 적용: 고객(고객ID, 이름), 주소(고객ID, 도시, 구, 번지)
2.2 2차 정규화 (2NF)
* 정의: 모든 비주요 속성이 전체 키에 완전히 종속되어야 합니다. 즉, 비주요 속성은 전체 키만으로 결정되어야 합니다.
* 중요 개념:
* 전체 키: 테이블 내 모든 레코드를 고유하게 식별하는 속성 또는 속성 집합
* 주요 속성: 전체 키의 일부를 구성하는 속성
* 비주요 속성: 주요 속성이 아닌 속성
* 부분 종속: 비주요 속성이 전체 키의 일부에만 종속되는 현상
* 예시:
* 비정규화: 주문(주문ID, 고객ID, 상품ID, 수량, 주문일시)
* 2NF 적용: 주문(주문ID, 고객ID, 상품ID, 수량, 주문일시), 고객(고객ID, 이름, 연락처)
2.3 3차 정규화 (3NF)
* 정의: 모든 비주요 속성이 이행적 함수 종속되지 않아야 합니다. 즉, 비주요 속성은 다른 비주요 속성에 의해 결정되어서는 안 됩니다.
* 중요 개념:
* 이행적 함수 종속: 비주요 속성이 다른 비주요 속성에 의해 결정되는 현상
* 전이적 종속: 한 속성이 다른 속성을 통해 간접적으로 종속되는 현상
* 예시:
* 비정규화: 직원(직원ID, 부서ID, 직급, 급여, 성별)
* 3NF 적용: 직원(직원ID, 부서ID, 직급, 급여), 부서(부서ID, 부서명, 위치), 급여표(직급, 급여)
2.4 보다 고차원의 정규화
* BCNF 정규화: 모든 속성이 초기 키에 함수적으로 종속되어야 합니다.
* 4차 정규화: 다중 값 종속성을 제거합니다.
* 5차 정규화: 투영 분해를 통해 이상 현상을 제거합니다.
3. 정규화의 장점
* 데이터 무결성 향상: 데이터 중복 감소로 오류 가능성 감소
* 데이터 일관성 유지: 데이터 중복으로 인한 불일치 방지
* 저장 공간 절약: 데이터 중복 감소로 저장 공간 효율적 활용
* 데이터 접근 및 관리 효율성 향상: 정규화된 구조로 데이터 검색 및 업데이트 속도 향상
4. Primary Key, Foreign Key에 대해 설명해주세요.
Primary Key와 Foreign Key 상세 설명: 핵심 개념, 특징, 비교, 예시, 활용, 제약 조건, 실무 적용, 심층 분석 및 추가 정보
1. 개요
Primary Key와 Foreign Key는 관계형 데이터베이스에서 테이블 간의 관계를 정의하고 데이터 무결성을 유지하는 데 중요한 역할을 하는 핵심 개념입니다.
2. Primary Key
2.1 정의
Primary Key는 테이블 내에서 각 레코드를 고유하게 식별하는 열 또는 열들의 집합입니다. 즉, Primary Key 값은 테이블 내에서 절대 중복되지 않습니다.
2.2 특징
* Null 허용 불가: Primary Key 값은 반드시 존재해야 하며 NULL 값을 허용하지 않습니다.
* 유일성: Primary Key 값은 테이블 내에서 모든 레코드에서 고유해야 합니다.
* 변경 불가: Primary Key 값은 레코드를 식별하는 데 사용되므로 임의로 변경할 수 없습니다.
2.3 예시
* 사용자 테이블: user_id
* 제품 테이블: product_id
* 주문 테이블: order_id
2.4 활용
* 데이터 검색: Primary Key를 사용하여 테이블에서 특정 레코드를 빠르고 정확하게 검색할 수 있습니다.
* 데이터 무결성 유지: Primary Key는 중복된 데이터를 허용하지 않아 데이터 무결성을 유지하는 데 도움이 됩니다.
* 테이블 간 관계 정의: Primary Key는 다른 테이블의 Foreign Key와 연결되어 테이블 간의 관계를 정의하는 데 사용됩니다.
3. Foreign Key
3.1 정의
Foreign Key는 한 테이블의 열이 다른 테이블의 Primary Key를 참조하는 것을 의미합니다. Foreign Key는 테이블 간의 관계를 정의하고 데이터 무결성을 유지하는 데 사용됩니다.
3.2 특징
* Null 허용: Foreign Key 값은 NULL 값을 허용할 수 있지만, 참조하는 Primary Key 값이 존재하지 않는 경우 NULL 값을 허용하지 않습니다.
* 참조 무결성: Foreign Key 값은 참조하는 Primary Key 값이 존재해야 합니다.
3.3 예시
* 주문 테이블: user_id (사용자 테이블의 user_id 참조)
* 주문 상세 테이블: order_id (주문 테이블의 order_id 참조)
3.4 활용
* 데이터 검색: Foreign Key를 사용하여 테이블 간의 관계를 기반으로 데이터를 검색할 수 있습니다.
* 데이터 무결성 유지: Foreign Key는 참조 무결성을 보장하여 데이터베이스의 일관성을 유지하는 데 도움이 됩니다.
4. Primary Key와 Foreign Key 비교
항목 Primary Key Foreign Key
정의 각 레코드를 고유하게 식별하는 열 또는 열들의 집합 한 테이블의 열이 다른 테이블의 Primary Key를 참조
Null 허용 허용하지 않음 허용 가능 (참조하는 Primary Key 값 존재 시)
유일성 모든 레코드에서 고유해야 함 참조하는 Primary Key 값과 일치해야 함
변경 가능 불가능 참조하는 Primary Key 값 변경 시 변경 가능
역할 데이터 검색, 데이터 무결성 유지, 테이블 간 관계 정의 데이터 무결성 유지, 테이블 간 관계 정의
5. 제약 조건
Primary Key와 Foreign Key는 데이터 무결성을 유지하기 위해 다음과 같은 제약 조건을 적용합니다.
* Primary Key 제약 조건:
* NULL 값 허용 불가
* 모든 레코드에서 값 고유해야 함
* Foreign Key 제약 조건:
* NULL 값 허용 가능 (참조하는 Primary Key 값 존재 시)
* 참조하는 Primary Key 값과 일치해야 함
Request Header
정의
- HTTP 요청에 포함되는 메타데이터의 집합
- 클라이언트는 서버에 요청을 보낼 때, 요청의 목적, 클라이언트 정보, 서버에게 요청하는 정보 등을 담아 전송한다. 서버는 Request Header를 통해 요청을 해석하고 처리한다.
주요 Request Header 필드
- [필수] Host
- [선택] Connection
- [선택] User-Agent
- [선택] Accept
- [선택] Accept-Language
- [선택] Content-Type
- [필수] Content-Length
- [선택] Authorization
- [선택] Cookie
Response Header
개요
- HTTP 응답 메시지의 일부
- 웹 서버에서 클라이언트에 전달하는 추가 정보 포함
- 다양한 설정 및 메타데이터 제공
- 웹 브라우저, 캐싱 서버, 프록시 서버 등에 의해 처리
Response Header
- [필수] Content-Type
- [필수] Content-Length
- [필수] Connection
- [선택] Cache-Control
- [선택] Pragma
- [선택] Expires
- [선택] Set-Cookie
- [선택] Location
- [선택] Content-Encoding
- [선택] Transfer-Encoding
- [선택] Accept-Ranges
- [선택] Vary
미션
- id / 미션 아이디
- title / 미션명
- description / 설명
- startDate / 시작일자
- endDate / 종료일자
- numberPeople / 인원수
- thumbnail / 썸네일
- type 선언/챌린지
Soft Delete vs Hard Delete
Clone vs Fork
Git Fork와 Git Clone의 차이점
Git을 사용하면서 가장 기본적이면서도 중요한 두 가지 작업 방식에는 Fork와 Clone이 있습니다. 이 둘은 비슷해 보일 수 있지만, 사용 목적과 방식에서 중요한 차이점을 가지고 있습니다. 🤓
Fork란?
- 개념: Fork는 다른 사람의 GitHub 저장소를 자신의 GitHub 계정으로 복사하는 것을 의미합니다. 이렇게 복사된 저장소는 완전히 독립적이며, 원본 저장소에 영향을 주지 않고 자유롭게 변경할 수 있습니다. 1
- 사용 목적: Fork는 주로 오픈 소스 프로젝트에 기여하고자 할 때 사용됩니다. 원본 저장소에 직접적인 변경 권한이 없는 경우, Fork를 통해 복사본을 만들고, 이 복사본에서 변경 작업을 한 뒤, Pull Request를 통해 원본 저장소에 변경 사항을 제안할 수 있습니다.
Clone이란?
- 개념: Clone은 특정 저장소를 자신의 로컬 컴퓨터로 복사하는 것을 의미합니다. 이렇게 복사된 저장소는 원본 저장소와 연결되어 있으며, 원본 저장소의 변경 사항을 로컬로 가져오거나 로컬에서의 변경 사항을 원본 저장소에 반영할 수 있습니다. 2
- 사용 목적: Clone은 주로 개발 작업을 로컬 환경에서 진행하고자 할 때 사용됩니다. 원본 저장소의 코드를 로컬에서 실행해보거나, 개발 및 테스트를 위해 필요한 모든 파일을 로컬 환경으로 가져올 수 있습니다.
Fork와 Clone은 Git을 사용하는 데 있어서 기본적이면서도 중요한 두 가지 방법입니다. 각각의 목적과 사용 방법을 이해하고 적절히 활용한다면, 보다 효율적인 협업과 개발이 가능해집니다. 🚀
이 내용이 도움이 되었다면, 더 궁금한 점이 있으시면 언제든지 물어보세요! 😊
Soft Delete vs Hard Delete: 당신의 데이터를 위한 사투
소프트 삭제와 하드 삭제는 데이터 삭제 방식의 두 가지 주요 유형입니다. 각 방식은 데이터 관리에 있어서 중요한 역할을 하며, 장단점 또한 다릅니다.
1. 소프트 삭제: 데이터의 부활
1.1. 정의 및 작동 방식
- 소프트 삭제는 데이터를 실제로 삭제하지 않고 '삭제된 것으로 표시'하는 방식입니다. 마치 휴지통에 버린 파일과 같습니다.
- 일반적으로 데이터베이스 레코드에 '삭제 플래그'를 추가하거나 '삭제 날짜'를 설정하여 구현됩니다.
- 삭제된 데이터는 특정 기간 동안 유지되고, 필요에 따라 복구될 수 있습니다.
1.2. 장점
- 실수로 삭제된 데이터 복구: 실수로 중요한 데이터를 삭제했을 경우, 소프트 삭제를 통해 쉽게 복구할 수 있습니다.
- 데이터 추적 및 감사: 삭제된 데이터도 일정 기간 동안 보관되므로, 데이터 변경 내역을 추적하고 감사하는 데 유용합니다.
- 저장 공간 확보: 실제로 삭제하지 않기 때문에 저장 공간을 확보하는 데 도움이 될 수 있습니다. 하지만, 삭제된 데이터는 여전히 공간을 차지합니다.
1.3. 단점
- 복잡성 증가: 데이터베이스 구조 및 관리가 더 복잡해질 수 있습니다.
- 공간 낭비: 삭제된 데이터는 여전히 공간을 차지하기 때문에, 장기간 보관 시 공간 낭비가 발생할 수 있습니다.
- 보안 취약점: 삭제된 데이터가 악의적으로 복구될 경우 보안 취약점이 발생할 수 있습니다.
2. 하드 삭제: 완전한 종말
2.1. 정의 및 작동 방식
- 하드 삭제는 데이터를 영구적으로 삭제하는 방식입니다. 마치 불태워 버린 문서와 같습니다.
- 데이터 저장 장치에서 데이터를 직접 삭제하거나 덮어쓰기하여 구현됩니다.
- 삭제된 데이터는 복구할 수 없습니다.
2.2. 장점
- 단순성: 구현 및 관리가 간단합니다.
- 공간 확보: 삭제된 데이터가 공간을 차지하지 않습니다.
- 보안 강화: 데이터가 완전히 삭제되므로 보안 취약점을 줄일 수 있습니다.
2.3. 단점
- 복구 불가능: 실수로 삭제된 데이터는 복구할 수 없습니다.
- 데이터 추적 어려움: 삭제된 데이터를 추적하거나 감사하는 것이 어렵습니다.
3. 격렬한 대결: 어떤 방식을 선택해야 할까?
- 데이터 유형: 중요하고 복구 가능성이 높은 데이터는 소프트 삭제, 중요하지 않거나 복구 가능성이 낮은 데이터는 하드 삭제를 사용합니다.
- 규정 준수: 특정 규정을 준수해야 하는 경우, 해당 규정에 맞는 삭제 방식을 선택해야 합니다.
- 보안 요구 사항: 보안이 중요한 경우, 하드 삭제를 사용하는 것이 좋습니다.
- 편의성: 데이터 관리 및 복구 편의성을 고려해야 합니다.
4. 결론: 상황에 맞는 선택
소프트 삭제와 하드 삭제는 각각 장단점을 가지고 있으며, 상황에 따라 적절한 방식을 선택해야 합니다. 데이터의 중요성, 복구 가능성, 규정 준수, 보안 요구 사항, 편의성 등을 고려하여 최적의 선택을 하십시오.
