Week1 DBMS, RDBMS basics

데이터베이스 & 관계형 데이터베이스 기본 개념

파일 시스템과 데이터베이스의 차이점에 대해서 설명해주세요.

파일 시스템:

• 데이터를 파일로 관리

• 계층 구조

• 데이터 중복 발생

• 데이터 무결성 보장하지 않음 (정확성, 일관성, 신뢰성을 유지하기 위한 제약 조건)

데이터 베이스:

• 데이터를 DBMS를 통해 체계적으로 관리

• 트랜잭션, 동시성 제어, 무결성(ACID 언급) 제약 조건을 통한 데이터 일관성 보장

• 여러 사용자가 동시 접근 가능

• 보안성과 백업 및 복구

트랜잭션 처리

**트랜잭션(Transaction)**이란 데이터베이스에서 하나의 논리적인 작업 단위를 의미하며, 여러 개의 작업(쿼리)이 하나의 트랜잭션 안에서 실행됩니다. 트랜잭션은 ACID 속성을 충족시켜야 합니다.

• Atomicity (원자성): 트랜잭션 내의 작업은 모두 성공하거나 모두 실패해야 합니다. 만약 트랜잭션 도중 오류가 발생하면, 데이터베이스는 이전 상태로 **롤백(rollback)**됩니다. 즉, 중간 상태가 남지 않게 합니다.

• Consistency (일관성): 트랜잭션이 시작되기 전과 완료된 후에 데이터는 항상 일관성 있는 상태를 유지해야 합니다. 즉, 데이터베이스의 모든 무결성 제약 조건을 만족해야 합니다.

• Isolation (고립성): 각 트랜잭션은 서로 독립적으로 실행되어야 하며, 동시에 여러 트랜잭션이 실행되더라도 각 트랜잭션의 중간 작업은 다른 트랜잭션에 영향을 미치지 않아야 합니다.

• Durability (지속성): 트랜잭션이 성공적으로 완료되면 그 결과는 영구적으로 저장되어 시스템 장애나 충돌이 발생하더라도 결과가 손실되지 않습니다.

동시성 제어

동시성 제어는 여러 트랜잭션이 동시에 실행될 때 데이터 일관성을 유지하기 위한 메커니즘입니다. 만약 여러 트랜잭션이 같은 데이터를 동시에 읽거나 수정하려고 하면 데이터 충돌이나 불일치가 발생할 수 있습니다. 이를 방지하기 위해 동시성 제어를 사용하여 트랜잭션들이 서로 간섭하지 않도록 조정합니다.

주요 문제들:

• Dirty Read: 한 트랜잭션이 아직 **커밋(commit)**되지 않은 다른 트랜잭션의 데이터를 읽는 경우. 나중에 트랜잭션이 롤백되면 잘못된 데이터를 참조하게 됩니다.

• Non-repeatable Read: 한 트랜잭션이 동일한 데이터를 두 번 읽는 동안, 다른 트랜잭션이 해당 데이터를 수정하는 경우. 처음 읽었을 때와 나중에 읽었을 때 데이터가 달라집니다.

• Phantom Read: 한 트랜잭션이 같은 조건으로 반복해서 조회했을 때, 다른 트랜잭션에 의해 새로운 데이터가 추가되거나 삭제되어 결과가 달라지는 경우입니다.

동시성 제어 방법:

• 잠금(Locking): 데이터에 **읽기 잠금(Shared Lock)**과 **쓰기 잠금(Exclusive Lock)**을 걸어 트랜잭션 간의 충돌을 방지합니다. 읽기 잠금은 여러 트랜잭션이 동시에 데이터를 읽을 수 있지만, 쓰기 잠금은 다른 트랜잭션이 접근할 수 없습니다.

• 낙관적 동시성 제어(Optimistic Concurrency Control): 트랜잭션이 완료되기 전까지는 데이터를 자유롭게 수정하게 하고, 완료 시점에 데이터 변경이 있는지 검증하여 충돌이 있으면 롤백하는 방식입니다.

• 비관적 동시성 제어(Pessimistic Concurrency Control): 트랜잭션이 실행되는 동안 다른 트랜잭션이 해당 데이터를 수정하지 못하도록 잠금을 거는 방식입니다. 주로 충돌 가능성이 높은 환경에서 사용됩니다.

데이터 무결성

데이터 무결성은 데이터베이스에 저장된 데이터가 정확하고 일관성 있게 유지되도록 보장하는 규칙입니다. 주로 무결성 제약 조건을 통해 데이터를 보호합니다.

무결성의 주요 제약 조건은 다음과 같습니다:

• 도메인 무결성: 각 속성의 값은 지정된 범위나 데이터 형식 내에 있어야 합니다. (예: 나이는 양수만 가능)

• 개체 무결성: 기본 키는 고유하고, NULL 값을 가질 수 없습니다.

• 참조 무결성: 외래 키는 반드시 참조하는 테이블의 기본 키와 일치해야 하며, 데이터 일관성을 보장합니다.

데이터베이스의 특징에 대해 설명해주세요

• 데이터 무결성

• 트랜잭션 처리

• 동시성 제어

• 데이터 독립성: 데이터베이스는 논리적 데이터 구조와 물리적 데이터 저장 구조를 분리하여, 데이터베이스 구조가 변경되어도 애플리케이션에 미치는 영향을 최소화합니다. 이는 논리적 데이터 독립성과 물리적 데이터 독립성으로 나뉩니다.

• 보안성: 데이터베이스는 인증, 권한 관리를 통해 사용자 접근 제어와 데이터 보안을 보장

• 백업 및 복구

• 데이터 중복 최소화 및 공유성 (중앙 집중 방식)

논리적 데이터 독립성과 물리적 데이터 독립성

논리적 데이터 독립성

정의: 논리적 데이터 독립성은 개념 스키마(데이터베이스의 전체적인 구조)가 변경되더라도, 외부 스키마(사용자나 애플리케이션이 보는 데이터 뷰)에 영향을 주지 않는 것

만약 데이터베이스 관리자가 테이블에 새로운 열(속성)을 추가하더라도, 이 열을 사용하지 않는 애플리케이션은 그 변경을 알 필요가 없습니다. 즉, 애플리케이션이 계속해서 정상적으로 작동할 수 있습니다.

물리적 데이터 독립성

물리적 데이터 독립성은 내부 스키마(데이터의 물리적 저장 방식)가 변경되더라도, 개념 스키마와 그 위에 있는 외부 스키마에 영향을 미치지 않는 것

데이터베이스 관리자가 성능 향상을 위해 데이터를 저장하는 식(예: 새로운 인덱스 추가, 데이터 파일을 다른 디스크로 이동 등)을 변경한다고 하더라도, 개념적으로는 같은 데이터 구조를 유지하고 있기 때문에, 애플리케이션이나 사용자에게는 이러한 변경이 투명하게 처리됨

DBMS는 무엇이며 그 특징에 대해 설명해주세요

• 데이터베이스를 생성, 관리, 운영하는 시스템 소프트웨어

• 사용자/애플리케이션은 DBMS를 통해 CRUD작업

• 데이터 무결성 보장

• 트랜잭션 관리

• 동시성 제어

• 데이터 보안

• 백업 및 복구 기능

• 옵티마이저

옵티마이저

• 옵티마이저라는 모듈을 사용하여 쿼리 최적화를 수행합니다. 옵티마이저는 가장 효율적인 실행 계획을 선택하여 쿼리 성능을 높입니다.

• SQL의 실행 계획을 수립하고 SQL 을 실행하는 데이터베이스 엔진

• 동일한 결과가 나오는 SQL도 어떻게 실행하느냐에 따라서 성능이 달라지기에, SQL 성능에 옵티마이저는 핵심 역할

특징

• 옵티마이저는 여러 개의 실행 계획 중에서 최저 비용을 가지고 있는 계획을 선택해서 SQL 을 실행

• 옵티마이저는 데이터 딕셔너리(Data Dictionary)에 있는 오브젝트 통계, 시스템 통계 등의 정보를 사용해서 예상되는 비용을 산정 ex) 예시로 JOIN 을 줄 때 가장왼쪽이 큰 테이블, 오른쪽으로 갈 수록 작은 테이블 순으로 가야 속도가 빠르게 나오는데, 옵티마이저가 순서 정리가 되있지 않아도 알아서 최저 비용을 계획하여 실행한다

스키마란 무엇이며, 3단계 데이터베이스 구조에 대해 설명해주세요

스키마

• 데이터베이스에서 데이터가 저장되는 방식과 그 관계를 정의한 청사진

• 데이터베이스의 구조를 정의한 것

• 테이블, 속성, 관계, 제약 조건 등의 정보를 포함

• 데이터 독립성을 보장하여 유지보수와 관리가 용이

데이터 베이스 구조

외부 스키마

• 사용자 또는 애플리케이션이 데이터를 보는 방식(사용자 뷰)을 정의

• 예시: 고객이 주문 정보를 조회하는 애플리케이션에서는 주문 테이블의 일부 열(주문 ID, 제품명, 가격)만 볼 수 있지만, 다른 테이블의 내부 정보(제품 제조 날짜, 원가 등)는 보지 못합니다.

개념 스키마

• 데이터베이스의 전체적인 논리적 구조를 정의

• 예시: 개념 스키마는 데이터베이스 전체를 정의하므로, 테이블의 열, 데이터 타입, 관계, 제약 조건 등이 모두 여기에 포함됩니다.

내부 스키마

• 데이터가 물리적으로 저장되는 방식을 정의

• 예시: 내부 스키마는 실제로 데이터가 파일 시스템에 어떻게 저장되는지, 데이터 접근을 빠르게 하기 위한 인덱스 등이 포함됩니다.

데이터 독립성이 뭔가요? (Data Independence)

데이터베이스의 구조가 변경되더라도, 상위 계층에 영향을 미치지 않도록 하는 개념

물리적 데이터 독립성

• 데이터의 물리적 저장 방식이 변경되더라도, 개념 스키마(데이터베이스의 논리적 구조)에 영향을 미치지 않는 것

• 내부 스키마에서 데이터가 어떻게 저장되는지(파일 시스템, 인덱스, 저장 위치 등)를 변경하더라도, 데이터의 논리적인 구조(개념 스키마)나 애플리케이션은 영향을 받지 않습니다. 즉, 물리적인 저장 방식이 바뀌더라도 논리적 데이터 구조는 그대로 유지됩니다.

• 예를 들어, 데이터베이스 관리자가 성능 향상을 위해 새로운 인덱스를 추가하거나, 데이터 저장소를 다른 장치로 옮기더라도, 이러한 물리적 변경은 사용자가 데이터를 사용하는 방식에 영향을 미치지 않습니다.

논리적 데이터 독립성

• 스키마(데이터의 논리적 구조)가 변경되더라도, 외부 스키마(사용자나 애플리케이션이 보는 데이터 뷰)에 영향을 미치지 않는 것

• 데이터베이스의 논리적 구조가 변경되더라도(예: 테이블의 열 추가, 속성 수정), 외부 스키마나 애플리케이션에 영향을 주지 않고 그대로 사용할 수 있게 됩니다. 논리적 데이터 독립성 덕분에 데이터베이스 구조를 변경해도 애플리케이션 코드를 수정할 필요가 줄어듭니다.

• 데이터베이스에서 새로운 속성(열)을 테이블에 추가하더라도, 그 속성을 사용하지 않는 기존 애플리케이션은 변경 사항을 몰라도 계속 정상적으로 동작할 수 있습니다.

RDBMS가 뭔가요?

• 릴레이션(관계)이라는 개념을 기반으로 테이블 형식으로 관리하는 데이터베이스 관리 시스템

• 각 릴레이션은 행과 열로 테이블

• 각 테이블 간에는 키를 통해 관계를 정의

• ACID 속성을 준수(일관성, 안정성을 보장하며 트랜잭션 중 오류가 발생해도 무결성 유지)

• 정규화를 통해 중복된 데이터를 최소화 가능

• 미리 정의된 스키마에 따라 엄격하게 저장되어 스키마 변경이 쉽지 않은 단점, 하지만 구조적 일관성을 보장

• 수직적 확장 용이, 수평적 확장은 상대적으로 어려움

• 핵심 기능중 하나인 Join연산을 통해 데이터를 효율적으로 연결하고 연관된 데이터를 하나의 결과로 결합

• SQL을 사용하여 데이터를질의, 조작 정의합니다.

릴레이션 스키마와 릴레이션 인스턴스에 대해 설명해주세요

릴레이션 스키마 (열 / attribute)

• 데이터베이스 테이블의 구조를 정의한 것(테이블이 어떻게 생겼는지에 대한 청사진)

• 테이블의 **속성(열)**들이 정의. 각 속성의 데이터 타입과 제약 조건이 포함

• 스키마는 테이블이 어떻게 구성되어 있는지, 어떤 속성들이 있는지에 대한 정보를 제공

릴레이션 인스턴스 (행 / record)

• 릴레이션 스키마에 따라 저장된 실제 데이터를 의미(테이블 안에 저장된 실제 데이터)

• 시간이 지남에 따라 변화할 수 있습니다

• 데이터가 추가되거나 수정되면서 테이블의 내용(인스턴스)이 변경

릴레이션 차수(Degree)와 카디널리티(Cardinality)

릴레이션 차수

• 하나의 테이블(릴레이션)에 정의된 속성(열)의 수

릴레이션 카디널리티

• 테이블에 저장된 데이터 레코드(행)의 수

키에 대해 설명해주세요

슈퍼키: 한 릴레이션 내에서 튜플(행)을 고유하게 식별할 수 있는 속성 또는 속성의 집합 예시: Student 테이블에서 StudentID와 Name을 함께 사용하여 각 학생을 유일하게 식별할 수 있다면, StudentID + Name은 슈퍼키

후보키: 슈퍼키 중에서 최소한의 속성으로 유일성을 보장하는 키 (최소성을 만족하는 키)

기본키: 기본키는 후보키 중에서 하나를 선택하여 각 튜플을 고유하게 식별하는 역할을 하는 키

대체키: 후보키 중에서 기본키로 선택되지 않은 키

외래키: 다른 테이블의 기본키를 참조하여 테이블 간의 관계를 설정하는 데 사용되는 키

대리키:대리키(Surrogate Key) 또는 인조키는 테이블에 인위적으로 부여된 유일한 식별자로, 주로 일련번호와 같은 자동 생성되는 키. 실제 데이터와는 관련 없는 키(Auto Increment)

무결성 제약 조건에 대해 설명해주세요

도메인 무결성 제약 조건

• 각 속성(열)에 저장되는 값이 지정된 데이터 타입과 범위 내에 있어야 함을 보장

개체 무결성 제약 조건

• 각 튜블을 고유하게 식별하기 위해, 기본 키(Primary Key)에 대한 제약 조건으로, 기본 키는 반드시 유일해야 하고, NULL 값을 가질 수 없습니다.

참조 무결성 제약 조건

• 데이터 일관성을 유지하기 위해, 외래 키(Foreign Key)가 참조하는 다른 테이블의 기본 키와 항상 일치해야 함을 보장

고유 무결성 제약 조건

• 특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우, 릴레이션의 각 튜플이 가지는 속성 값들은 고유한 값을 가져야 합니다.

NULL 무결성 제약 조건

• 릴레이션의 특정 속성 값은 NULL 될 수 없습니다. 예를 들어, 주민등록번호가 반드시 입력되어야 한다면 NULL 값은 허용되지 않습니다.

키 무결성 제약 조건

• 각 릴레이션은 최소한 한 개 이상의 키를 가져야 하며, 키는 튜플을 식별할 수 있는 값이어야 합니다.

어떤 데이터베이스를 사용해보셨나요? 사용해본 데이터베이스에 대해 설명해주세요.

Redis

• 인메모리 데이터베이스로, 데이터를 메모리에 저장하여 매우 빠른 읽기 및 쓰기 속도를 제공

• 캐싱과 메시지 큐, Pub/Sub 시스템 등에서 사용

• Redis는 문자열(String), 리스트(List), 셋(Set), 해시(Hash), 정렬된 집합(Sorted Set), 비트맵(Bitmap), 하이퍼로그로그(HyperLogLog) 등 다양한 데이터 구조를 지원

저는 Redis를 세션 정보를 저장하기 위해, 그리고 JWT에서 만료된 토큰을 저장하기 위해 사용해봤었습니다. 토큰이 만료되거나 블랙리스트에 추가되었을때, 빠른 조회 속도와 짧은 TTL 설정을 통해 토큰 관리를 했었습니다.

또한, @Cachable(value = "결과값", key = "#id")를 통해 결과값을 Redis에 캐싱하여 데이터베이스에 자주 요청해야하는 데이터를 캐싱했습니다. @CacheEvict(value = "결과값", key = #id) 를 통해 데이터가 변경될 때 캐시 데이터를 제거하여 데이터의 일관성을 유지했습니다.

마지막으로 @EventListener와 Redis의 Pub/Sub 기능을 사용하여 비동기 이벤트 처리를 구현했습니다. 이벤트가 발생할때 구독자들에게 즉시 알림을 전달할 수 있었으며, 비동기 처리를 효율적으로 수행했습니다.