Database

아투·2026년 3월 30일

Database

목록 보기
2/6
post-thumbnail

데이터베이스 개념

데이터베이스 (Database)

  • 정의
    데이터베이스는 여러 사람이나 애플리케이션이 공유하기 위해 체계적으로 정리하여 통합 관리하는 데이터의 집합이다. 단순히 데이터를 모아둔 것에 그치지 않고, 데이터베이스 관리 시스템(DBMS)을 통해 효율적으로 관리, 검색, 갱신할 수 있도록 구조화된 데이터의 저장소를 의미한다.

  • 사용하는 이유

    • 영속성 있는 데이터 저장: 프로그램이 종료되더라도 데이터가 사라지지 않고 비휘발성 저장 장치에 안전하게 보관된다.
    • 데이터 공유: 여러 사용자나 시스템이 동시에 동일한 데이터에 접근하여 활용할 수 있는 협업 환경을 제공한다.
    • 데이터 중복 최소화: 동일한 데이터를 여러 곳에 중복 저장하지 않고 통합 관리함으로써 저장 공간을 절약하고 데이터 불일치 문제를 해결한다.
    • 데이터 무결성 유지: 데이터의 정확성과 일관성을 유지하기 위한 제약 조건을 설정하여 잘못된 데이터가 입력되는 것을 방지한다.
  • 핵심 역할 및 특징

    • 실시간 접근성: 사용자의 질의에 대해 실시간으로 처리하여 응답한다.
    • 지속적인 변화: 데이터의 삽입, 삭제, 수정을 통해 항상 최신의 데이터를 동적으로 유지한다.
    • 동시 공유: 여러 사용자가 서로 다른 목적으로 동시에 데이터를 이용할 수 있도록 제어한다.
    • 내용에 의한 참조: 데이터의 저장 위치나 주소가 아닌, 데이터가 가진 값을 기준으로 데이터를 찾는다.
  • 동작 원리

    1. 질의 처리: 사용자가 SQL 등의 언어로 요청을 보내면, DBMS는 이를 분석하고 실행 가능한 형태로 변환한다.
    2. 최적화: 옵티마이저가 인덱스 유무, 데이터 양 등을 고려하여 데이터를 가장 빠르게 찾을 수 있는 실행 계획을 수립한다.
    3. 트랜잭션 관리: 데이터의 상태를 변화시키는 작업 단위인 트랜잭션을 관리하며, 장애 발생 시 원복하거나 성공 시 반영한다.
    4. 동시성 제어: 여러 사용자가 동시에 같은 데이터를 수정하려 할 때, 잠금 등의 메커니즘을 통해 데이터 충돌을 방지한다.
    5. 저장 및 회복: 실제 디스크에 데이터를 기록하며, 로그를 남겨 시스템 장애 시 데이터를 복구할 수 있는 기반을 마련한다.
  • 트레이드 오프

    • 정규화 vs 성능: 데이터 중복을 줄이기 위한 정규화는 데이터 무결성을 높이지만, 복잡한 조인 연산으로 인해 조회 성능이 저하될 수 있다.
    • 일관성 vs 가용성: 분산 데이터베이스 환경에서 데이터의 완벽한 일관성을 보장하려면 시스템 응답 속도가 느려질 수 있고, 높은 가용성을 우선하면 일시적인 데이터 불일치가 발생할 수 있다.
    • 쓰기 성능 vs 읽기 성능: 인덱스를 많이 생성하면 읽기 속도는 빨라지지만, 데이터 삽입 및 수정 시 인덱스를 매번 갱신해야 하므로 쓰기 성능은 떨어진다.
  • 주의 사항

    • 보안 및 권한 관리: 민감한 정보가 포함될 수 있으므로 사용자별로 접근 권한을 세분화하고 암호화 설정을 철저히 해야 한다.
    • 백업 및 복구 전략: 하드웨어 장애나 운영 실수에 대비하여 정기적인 백업 스케줄을 운영하고, 실제 복구 시나리오를 테스트해 두어야 한다.
    • 성능 모니터링: 데이터가 누적됨에 따라 쿼리 성능이 저하될 수 있으므로 느린 쿼리를 주기적으로 분석하고 인덱스 최적화나 파티셔닝을 검토해야 한다.
    • 확장성 고려: 서비스 성장에 대비하여 서버 사양을 높이는 수직 확장과 서버 대수를 늘리는 수평 확장 중 어떤 방식이 유리할지 설계 단계부터 고려해야 한다.

관계형 데이터베이스 (RDBMS)

  • 정의
    관계형 데이터베이스 관리 시스템은 데이터를 열과 행으로 이루어진 테이블 형태로 구성하고, 테이블 간의 관계를 정의하여 관리하는 데이터베이스 시스템이다. 1970년대 E.F. 커드가 제안한 관계형 모델에 기초하며, 구조화된 질의 언어인 SQL을 사용하여 데이터를 제어하고 관리한다.

  • 사용하는 이유

    • 데이터 무결성 확보: 엄격한 스키마와 제약 조건을 통해 데이터의 정확성과 일관성을 유지하기 위함이다.
    • 복잡한 관계 표현: 외래 키를 통해 서로 다른 데이터 집합 간의 연결 고리를 논리적으로 명확하게 정의할 수 있다.
    • 표준화된 접근: SQL이라는 표준화된 언어를 사용하여 데이터 가공 및 분석이 용이하며, 다양한 애플리케이션과의 호환성이 뛰어나다.
  • 핵심 역할 및 특징

    • ACID 트랜잭션 지원: 원자성, 일관성, 고립성, 지속성을 보장하여 금융 업무 등 신뢰성이 중요한 작업에 적합하다.
    • 정형 데이터 관리: 미리 정의된 스키마에 따라 데이터를 저장하므로 데이터 구조가 명확하고 예측 가능하다.
    • 데이터 무결성 제약: 기본 키, 외래 키, 고유 키 등의 제약을 통해 데이터 중복을 방지하고 비즈니스 규칙을 강제한다.
    • 고도의 질의 성능: 인덱싱과 질의 최적화를 통해 대용량 데이터에서도 특정 조건의 데이터를 효율적으로 검색한다.
  • 동작 원리

    1. 질의 최적화: 사용자가 전달한 SQL을 파싱하여 실행 계획을 세운다. 옵티마이저는 인덱스 유무와 데이터 분포를 고려해 가장 비용이 적은 경로를 선택한다.
    2. B-Tree 기반 인덱싱: 데이터 검색 속도를 높이기 위해 대개 B-Tree 또는 B+Tree 구조의 인덱스를 관리한다. 이를 통해 전체 데이터를 스캔하지 않고도 로그 시간 복잡도로 원하는 행을 찾는다.
    3. 쓰기 앞섬 로깅: 데이터 변경 시 실제 데이터 파일에 기록하기 전, 변경 로그를 먼저 기록한다. 이는 시스템 장애 발생 시 로그를 통해 데이터를 복구하기 위한 핵심 메커니즘이다.
    4. 잠금 및 동시성 제어: 여러 사용자가 동시에 같은 데이터를 수정할 때 데이터의 일관성을 해치지 않도록 행 단위 혹은 테이블 단위로 잠금을 걸어 트랜잭션의 격리 수준을 유지한다.
  • 트레이드 오프

    • 확장성의 한계: 수직 확장은 용이하나, 데이터 분산 저장 시 조인 연산의 복잡도가 급격히 증가하여 수평 확장이 NoSQL에 비해 까다롭다.
    • 유연성 부족: 고정된 스키마를 가지므로 데이터 구조가 자주 변경되는 서비스에서는 스키마 변경에 따른 다운타임이나 운영 부담이 크다.
    • 성능 오버헤드: 강력한 일관성을 보장하기 위한 잠금 메커니즘과 ACID 지원 과정에서 발생하는 오버헤드가 읽기 및 쓰기 성능에 영향을 줄 수 있다.
  • 주의 사항

    • 정규화와 반정규화의 균형: 데이터 중복을 줄이기 위한 과도한 정규화는 많은 조인을 유발해 성능을 저하시킬 수 있다. 조회 성능 향상을 위해 적절한 수준의 반정규화를 고려해야 한다.
    • 인덱스 오남용 주의: 인덱스는 조회 속도를 높여주지만, 삽입, 수정, 삭제 시 인덱스 갱신 비용이 발생하며 추가 저장 공간을 소모하므로 꼭 필요한 열에만 생성해야 한다.
    • 데드락 관리: 복잡한 트랜잭션이 얽힐 경우 서로의 자원을 점유하려고 대기하는 교착 상태가 발생할 수 있다. 트랜잭션 범위를 최소화하고 자원 접근 순서를 일치시켜야 한다.
    • 커넥션 관리: 데이터베이스 연결 생성은 비용이 크다. 애플리케이션 레벨에서 커넥션 풀을 적절히 설정하여 효율적으로 자원을 공유해야 한다.

SQL (Structured Query Language)

  • 정의
    SQL은 관계형 데이터베이스 관리 시스템에서 데이터를 정의, 조작, 제어하기 위해 사용하는 표준화된 프로그래밍 언어이다. 사용자가 어떻게 데이터를 가져올지 명시하는 절차적 언어와 달리, 무엇을 원하는지를 기술하는 선언적 언어의 특성을 갖는다.

  • 사용하는 이유

    • 방대한 양의 데이터를 체계적으로 저장하고, 필요한 정보를 빠르고 정확하게 추출하여 의사결정에 활용하기 위함이다.
    • 데이터 간의 관계를 정의하고 무결성을 유지하며, 다수의 사용자가 동시에 데이터에 안전하게 접근할 수 있는 표준화된 인터페이스를 제공하기 위해 사용한다.
  • 핵심 역할 및 특징

    • 데이터 정의(DDL): 테이블, 인덱스, 뷰 등 데이터베이스 객체를 생성, 수정, 삭제한다.
    • 데이터 조작(DML): 데이터를 조회, 삽입, 수정, 삭제하는 핵심 기능을 수행한다.
    • 데이터 제어 및 트랜잭션(DCL/TCL): 사용자별 권한을 부여하거나 회수하고, 작업의 원자성을 보장하기 위해 승인이나 취소를 관리한다.
    • 집합 지향적 처리: 데이터를 한 건씩 처리하는 것이 아니라, 특정 조건을 만족하는 데이터의 집합 단위로 연산을 수행한다.
  • 동작 원리

    1. 구문 분석: 데이터베이스 엔진은 전달받은 SQL 문법의 오류를 점검하고, 데이터베이스 객체의 존재 여부와 권한을 확인하여 실행 계획을 준비한다.
    2. 최적화: 옵티마이저가 통계 정보를 바탕으로 데이터를 찾는 여러 경로 중 가장 비용이 적고 효율적인 실행 경로를 결정한다.
    3. 실행: 결정된 실행 계획에 따라 스토리지 엔진에 데이터 읽기 및 쓰기를 요청하고 결과를 메모리에 로드한다.
    4. 결과 반환: 처리된 데이터를 클라이언트가 이해할 수 있는 결과셋 형태로 가공하여 반환한다.
  • 트레이드 오프

    • 엄격한 스키마 vs 유연성: 미리 정의된 스키마를 통해 데이터의 일관성과 정확성을 높일 수 있지만, 데이터 구조가 빈번하게 변경되는 환경에서는 변경 비용이 높고 유연성이 떨어진다.
    • 복잡한 관계 vs 성능: 여러 테이블을 조합해 복잡한 질의를 수행할 수 있는 강력한 기능을 제공하지만, 테이블 규모가 커질수록 조인 연산에 의한 CPU 및 메모리 부하가 급증한다.
    • 수직 확장 중심: 전통적인 RDBMS는 단일 서버의 성능을 높이는 방식에 최적화되어 있어, 여러 대의 서버로 데이터를 분산하는 수평 확장 구현 시 비용과 난이도가 크게 상승한다.
  • 주의 사항

    • SQL Injection 보안: 사용자 입력을 쿼리에 직접 결합할 경우 악의적인 쿼리가 실행될 수 있으므로, 반드시 Prepared Statement나 파라미터화된 쿼리를 사용하여 방어해야 한다.
    • 인덱스 오남용: 인덱스는 조회 속도를 높여주지만, 과도한 생성은 삽입, 수정, 삭제 성능을 저하시키고 저장 공간을 낭비하므로 실행 계획을 분석하여 적절히 설계해야 한다.
    • 트랜잭션 격리 수준 및 잠금: 동시성 제어를 위해 사용하는 트랜잭션 격리 수준에 따라 데이터 정합성 문제가 발생하거나, 과도한 잠금으로 인해 데드락이 발생할 수 있으므로 주의가 필요하다.
    • N+1 문제: ORM 등을 사용할 때 연관된 데이터를 조회하며 불필요하게 많은 쿼리가 발생하는 문제를 방지하기 위해 조인이나 Fetch Join 등을 적절히 활용해야 한다.

스키마 (Schema)

  • 정의
    스키마는 데이터베이스의 구조와 제약 조건에 관해 전반적인 명세를 기술한 메타데이터의 집합이다. 데이터베이스를 구성하는 데이터 개체, 속성, 관계 및 데이터 조작 시 준수해야 할 규칙들을 정의한 논리적 청사진 역할을 한다.

  • 사용하는 이유

    • 데이터의 구조를 표준화하여 데이터 일관성과 무결성을 유지하고, 데이터베이스 관리 시스템이 데이터를 효율적으로 저장 및 관리할 수 있도록 하기 위함이다.
    • 사용자나 애플리케이션에 데이터의 논리적 구조를 제공함으로써 물리적인 저장 방식과 분리된 데이터 독립성을 확보하고, 데이터 오염을 방지하기 위해 사용한다.
  • 핵심 역할 및 특징

    • 데이터 구조 정의: 테이블, 뷰, 인덱스 등 데이터베이스 객체의 구조와 타입을 정의한다.
    • 무결성 제약 조건 설정: 기본키, 외래키, 데이터 타입 제한 등을 통해 데이터의 정확성과 유효성을 강제한다.
    • 데이터 독립성 제공: 3단계 스키마 구조를 통해 논리적 혹은 물리적 구조가 변경되어도 사용자 인터페이스에 영향을 주지 않도록 한다.
    • 보안 및 권한 관리: 스키마 단위로 접근 권한을 설정하여 특정 데이터에 대한 보안을 강화할 수 있다.
  • 동작 원리

    1. 정의 단계(DDL): 데이터베이스 관리자가 데이터 정의 언어를 사용하여 스키마를 생성하고 데이터 사전에 저장한다.
    2. 컴파일 및 유효성 검사: DBMS는 입력되는 쿼리나 데이터가 정의된 스키마의 규칙에 부합하는지 검사한다.
    3. 매핑 수행: 사용자의 논리적 요청을 전체적인 논리 구조로 변환하고, 이를 다시 실제 물리적 저장 장치의 주소로 연결한다.
    4. 변경 관리: 스키마 변경 시 기존 데이터와의 호환성을 검토하며 구조를 재정의하고 관련 인덱스나 제약 조건을 갱신한다.
  • 트레이드 오프

    • 엄격한 정합성 vs 유연성 부족: 고정된 스키마는 데이터 정합성을 보장하지만, 비정형 데이터나 구조가 자주 바뀌는 요구사항에는 대응하기 어렵다.
    • 설계의 완성도 vs 개발 속도: 초기에 정밀한 스키마 설계가 이루어지면 유지보수가 쉽지만, 초기 설계 단계에 많은 시간과 비용이 소요된다.
    • 성능 vs 정규화: 데이터 중복을 제거하기 위한 스키마 정규화는 데이터 무결성을 높이지만, 복잡한 조인 연산으로 인해 조회 성능이 저하될 수 있다.
  • 주의 사항

    • 스키마 변경의 위험성: 운영 중인 서비스에서 스키마를 변경할 경우 대량의 데이터 갱신이나 테이블 락으로 인해 서비스 중단이 발생할 수 있으므로 주의해야 한다.
    • 과도한 정규화 지양: 지나치게 세분화된 스키마 설계는 쿼리 복잡도를 높이고 성능을 떨어뜨릴 수 있으므로, 비즈니스 요건에 따라 적절한 반정규화를 고려해야 한다.
    • 데이터 타입 선택의 신중함: 한 번 정의된 속성의 데이터 타입이나 길이를 변경하는 것은 비용이 크기 때문에 향후 데이터 확장성을 고려하여 타입을 선정해야 한다.
    • 강한 결합도: 애플리케이션 코드가 특정 스키마 구조에 강하게 결합될 경우, 스키마 변경 시 코드 수정 범위가 넓어지는 문제가 발생할 수 있다.

테이블, 행, 열 (Table, Row, Column)

  • 정의

    • 테이블: 관계형 데이터베이스에서 데이터를 저장하는 가장 기본적인 논리적 단위로, 행과 열로 구성된 2차원 구조의 데이터 집합이다.
    • 행: 테이블에서 가로 방향으로 나열된 하나의 데이터 단위이다. 특정 개체에 대한 모든 정보를 담고 있는 고유한 집합체이다.
    • 열: 테이블에서 세로 방향으로 나열된 데이터의 속성이다. 해당 속성에 담길 데이터의 타입과 형식을 규정한다.
  • 사용하는 이유

    • 데이터 구조화: 비정형 데이터를 체계적인 표 형태로 관리함으로써 대량의 정보를 직관적으로 파악하고 효율적으로 관리하기 위함이다.
    • 데이터 무결성 확보: 열마다 타입을 지정하고 제약 조건을 부여함으로써 잘못된 데이터가 입력되는 것을 방지하고 신뢰성을 유지하기 위해 사용한다.
    • 효율적인 검색: 인덱스를 활용해 특정 행을 빠르게 찾거나, 특정 열의 데이터만 추출하는 등 복잡한 데이터 연산을 고속으로 수행하기 위함이다.
  • 핵심 역할 및 특징

    • 테이블: 고유한 이름을 가지며, 서로 연관된 데이터들의 물리적 혹은 논리적 저장 공간 역할을 한다.
    • 행: 기본키를 통해 각 행은 서로 구별되며, 하나의 행은 하나의 완전한 비즈니스 데이터를 의미한다.
    • 열: 데이터의 도메인을 결정하며, 모든 행은 동일한 열 구성을 공유하여 데이터의 일관성을 유지한다.
  • 동작 원리

    1. 스키마 정의: 데이터를 입력하기 전, 테이블의 이름과 열의 이름, 데이터 타입, 제약 조건을 미리 정의한다.
    2. 데이터 삽입 및 저장: 새로운 데이터가 행 단위로 추가되면, 시스템은 정의된 열의 규칙에 맞는지 검증한 후 물리적 저장 장치에 기록한다.
    3. 인덱싱 및 조회: 특정 열에 인덱스를 설정하면 전체 행을 스캔하지 않고도 B-Tree 등의 알고리즘을 통해 원하는 행의 위치를 빠르게 찾아낸다.
    4. 관계 형성: 외래키를 통해 서로 다른 테이블의 행끼리 연결되어 데이터 간의 관계를 형성한다.
  • 트레이드 오프

    • 유연성 vs 구조화: 고정된 스키마를 가지므로 데이터가 안정적이지만, 요구사항 변경으로 열을 추가하거나 삭제할 때 운영 중인 시스템에 부하를 줄 수 있다.
    • 정규화 vs 성능: 중복을 제거하기 위해 테이블을 쪼개면 저장 공간은 절약되지만, 조회 시 여러 테이블을 합치는 조인 연산 비용이 발생한다.
    • 행 기반 vs 열 기반 저장: 일반적인 RDBMS는 행 단위로 저장하여 데이터 추가 및 수정이 빠르지만, 대량의 통계 분석 시에는 필요한 열만 읽는 열 기반 방식보다 느릴 수 있다.
  • 주의 사항

    • 기본키 설정 필수: 모든 테이블은 각 행을 유일하게 식별할 수 있는 기본키를 가져야 데이터 중복과 혼란을 막을 수 있다.
    • 데이터 타입 최적화: 열의 데이터 타입을 필요 이상으로 크게 설정하면 스토리지 낭비 및 성능 저하의 원인이 된다.
    • NULL 값 관리: NULL이 과도하게 허용된 열은 비즈니스 로직에서 예외 처리를 복잡하게 만들며 인덱스 효율을 떨어뜨릴 수 있으므로 가급적 NOT NULL 제약과 기본값을 활용한다.
    • 인덱스 과다 생성 금지: 조회 속도를 높이기 위해 너무 많은 인덱스를 열에 설정하면, 데이터 삽입이나 수정 시 성능이 급격히 저하된다.

기본키 (Primary Key)

  • 정의
    기본키는 관계형 데이터베이스에서 테이블 내의 각 레코드를 고유하게 식별할 수 있는 하나 이상의 컬럼 집합이다. 데이터베이스 설계의 기초적인 요소로, 테이블당 오직 하나의 기본키만 존재할 수 있으며 개체 무결성을 보장하는 핵심 장치이다.

  • 사용하는 이유

    • 특정 레코드를 정확하고 신속하게 찾아내기 위한 식별자로 사용하며, 데이터의 중복 저장을 방지하여 데이터의 신뢰성을 높이기 위함이다.
    • 레코드 간의 구분자를 명확히 함으로써 데이터 수정 및 삭제 시 잘못된 데이터가 조작되는 사고를 방지하고 인덱싱을 통한 조회 성능 향상을 도모한다.
  • 핵심 역할 및 특징

    • 유일성: 테이블 내의 모든 행에 대해 기본키 값은 유일해야 하며, 중복된 값을 가질 수 없다.
    • 최소성: 키를 구성하는 컬럼 중 하나라도 제외하면 유일성을 확보할 수 없는 꼭 필요한 컬럼으로만 구성되어야 한다.
    • Not Null: 기본키는 빈 값을 허용하지 않는다. 식별 불가능한 데이터는 존재할 수 없기 때문이다.
    • 불변성: 한 번 설정된 기본키 값은 가급적 변경되지 않아야 한다. 변경 시 참조하고 있는 다른 테이블에 영향을 주기 때문이다.
  • 동작 원리

    1. 인덱스 자동 생성: 기본키를 설정하면 데이터베이스 엔진은 해당 컬럼에 대해 자동으로 클러스터형 인덱스를 생성한다.
    2. 중복 검사 및 정렬: 데이터 삽입 시 B-Tree 구조의 인덱스를 탐색하여 중복 여부를 즉시 확인하며, 물리적으로 데이터를 정렬된 상태로 유지하여 검색 속도를 극대화한다.
    3. 제약 조건 강제: DBMS 레벨에서 모든 트랜잭션마다 유일성과 Not Null 조건을 검증하여 무결성을 위반하는 작업은 철회한다.
  • 트레이드 오프

    • 조회 성능 vs 쓰기 성능: 인덱스를 통해 조회 속도는 비약적으로 빨라지지만, 삽입, 수정, 삭제 시 인덱스를 갱신하고 정렬을 유지해야 하므로 오버헤드가 발생한다.
    • 저장 공간: 인덱스 정보를 별도로 관리해야 하므로 추가적인 디스크 및 메모리 공간이 소모된다.
  • 주의 사항

    • 비즈니스 데이터 활용 지양: 주민등록번호나 이메일 주소처럼 비즈니스 의미가 있는 데이터보다는 시스템적으로 생성된 일련번호를 사용하는 것이 변경 대응에 유리하다.
    • 복합키 구성의 단순화: 여러 컬럼을 묶어 기본키로 만들 수 있으나, 너무 많은 컬럼을 포함하면 인덱스 크기가 커지고 조인 시 쿼리가 복잡해져 성능이 저하될 수 있다.
    • 과도하게 긴 문자열 지양: 기본키의 길이가 길어지면 이를 참조하는 외래키의 크기도 함께 커지므로, 가능한 작은 데이터 타입을 선택해야 한다.

외래키 (Foreign Key)

  • 정의
    외래키는 한 테이블의 컬럼이 다른 테이블의 기본키를 참조하도록 설정된 제약 조건이다. 테이블 간의 관계를 정의하며, 참조 무결성을 유지하기 위한 논리적 연결 고리 역할을 한다.

  • 사용하는 이유

    • 데이터의 일관성을 유지하고 테이블 간의 관계를 명확히 하여 부모-자식 관계의 데이터를 체계적으로 관리하기 위함이다.
    • 존재하지 않는 데이터를 참조하는 오류를 방지하고, 데이터 삭제나 수정 시 연관된 데이터를 함께 처리하거나 제한하는 로직을 자동화하기 위해 사용한다.
  • 핵심 역할 및 특징

    • 참조 무결성 보장: 자식 테이블에 저장되는 값이 반드시 부모 테이블에 존재하도록 강제한다.
    • 관계의 구현: 일대다, 일대일 등 데이터 모델링에서 정의한 관계를 물리적 데이터베이스 수준에서 구현한다.
    • 중복 최소화: 중복 데이터를 저장하는 대신 키 값만 참조하게 함으로써 데이터 정규화를 실현한다.
  • 동작 원리

    1. 참조 확인: 자식 테이블에 데이터 삽입 혹은 수정 시, 입력되는 값이 부모 테이블의 참조 컬럼에 존재하는지 확인한다.
    2. 연쇄 동작: 부모 테이블의 데이터가 변경되거나 삭제될 때 미리 정의된 옵션에 따라 자식 데이터를 자동으로 처리한다.
    3. 인덱스 활용: 조인 연산 시 외래키 인덱스를 활용하여 연관된 데이터를 빠르게 매칭한다.
  • 트레이드 오프

    • 데이터 정합성 vs 성능: 완벽한 무결성을 보장하지만, 모든 데이터 조작 시 부모와 자식 테이블을 교차 확인하므로 대량 데이터 처리 시 성능 저하가 발생할 수 있다.
    • 유연성 부족: 테스트 데이터 삽입이나 데이터 마이그레이션 시 제약 조건 때문에 작업이 번거로워질 수 있다.
  • 주의 사항

    • 외래키 인덱스 설정: 외래키 컬럼에는 수동으로라도 인덱스를 생성하는 것이 권장된다. 조인 성능 및 부모 테이블 삭제 시의 탐색 속도에 큰 영향을 미치기 때문이다.
    • 순환 참조 방지: 테이블 A가 B를 참조하고, B가 다시 A를 참조하는 형태는 설계 복잡도를 높이고 데이터 삭제를 불가능하게 만들 수 있으므로 피해야 한다.
    • NULL 허용 여부 결정: 외래키는 기본키와 달리 NULL을 허용할 수 있다. 업무 로직에 따라 필수 참조인지 선택 참조인지 명확히 설계해야 한다.
    • 삭제 옵션 신중 선택: 부모 삭제 시 자식도 삭제되는 옵션을 무분별하게 사용하면 의도치 않은 대규모 데이터 손실이 발생할 수 있으므로 주의해야 한다.

데이터 무결성 (Data Integrity)

  • 정의
    데이터 무결성이란 데이터베이스 내의 데이터가 생명주기 전반에 걸쳐 정확성, 일관성, 유효성 및 신뢰성을 유지하는 것을 의미한다. 데이터에 결함이 없음을 보장하며, 비인가된 사용자에 의한 데이터 변경이나 예기치 못한 시스템 오류로부터 데이터를 보호하는 요소이다.

  • 사용하는 이유

    • 잘못된 데이터로 인해 발생할 수 있는 비즈니스 의사결정 오류를 방지하고 시스템의 신뢰도를 높이기 위해 사용한다.
    • 데이터 간의 관계를 명확히 하여 모순된 정보가 저장되는 것을 막고, 중복을 최소화하여 데이터 관리의 효율성을 극대화하기 위함이다.
  • 핵심 역할 및 특징

    • 개체 무결성: 모든 테이블은 기본키를 가져야 하며, 기본키는 중복되거나 NULL 값을 가질 수 없다.
    • 참조 무결성: 외래키 값은 참조하는 테이블의 기본키와 일치하거나 NULL이어야 하며, 데이터 간의 관계를 일관되게 유지한다.
    • 도메인 무결성: 특정 열에 저장되는 값은 정의된 데이터 타입, 범위, 형식을 만족해야 한다.
    • 사용자 정의 무결성: 비즈니스 규칙에 따라 사용자가 직접 정의한 특정 제약 조건을 만족해야 한다.
  • 동작 원리

    1. 제약 조건 설정: 테이블 생성 시 NOT NULL, UNIQUE, PRIMARY KEY 등의 제약 조건을 설정하여 데이터 입력 단계부터 검증한다.
    2. 트랜잭션 관리: ACID 원칙을 준수하여 데이터 변경 작업이 완전히 성공하거나, 실패 시 초기 상태로 되돌림으로써 일관성을 유지한다.
    3. 트리거 및 프로시저: 데이터 변경 이벤트 발생 시 사전에 정의된 로직을 자동으로 실행하여 복잡한 무결성 규칙을 강제한다.
  • 트레이드 오프

    • 데이터 정확성 vs 시스템 성능: 무결성 제약 조건이 많아질수록 데이터 삽입, 수정, 삭제 시 검증 단계가 늘어나 시스템의 전반적인 처리 속도가 저하될 수 있다.
    • 유연성 vs 엄격함: 너무 엄격한 무결성 규칙은 초기 개발 속도를 늦추고 변화하는 비즈니스 요구사항에 유연하게 대응하기 어렵게 만들 수 있다.
  • 주의 사항

    • 애플리케이션 vs DB 계층 선택: 무결성 로직을 애플리케이션 코드에서만 관리할 경우 다른 경로를 통제할 수 없으므로 가급적 DB 계층에서 제약 조건을 설정하는 것이 안전하다.
    • 대량 데이터 마이그레이션: 대량의 데이터를 한꺼번에 이관할 때 무결성 체크로 인해 시간이 너무 오래 걸릴 수 있으므로, 일시적으로 제약 조건을 비활성화한 후 사후 검증하는 전략이 필요할 수 있다.
    • 성능 튜닝: 참조 무결성 설정 시 인덱스가 적절히 생성되지 않으면 조인 성능이나 데이터 변경 성능이 급격히 떨어질 수 있으므로 인덱스 전략과 병행해야 한다.

ERD (Entity-Relationship Diagram)

  • 정의
    ERD는 데이터베이스를 구축하기 전, 데이터들 간의 관계를 논리적으로 구조화하여 시각적으로 표현한 설계 도면이다. 개체, 속성, 관계를 핵심 요소로 사용하여 현실 세계의 데이터를 추상화하는 기법이다.

  • 사용하는 이유

    • 개발자, 기획자, 고객 등 이해관계자들이 데이터 구조를 한눈에 파악하고 원활하게 소통하기 위한 공통 언어의 역할을 한다.
    • 실제 데이터베이스를 생성하기 전에 논리적 오류를 발견하고 수정함으로써 설계 단계에서의 시행착오를 줄이고 체계적인 시스템 구축을 가능하게 한다.
  • 핵심 역할 및 특징

    • 엔티티 표현: 데이터 관리 대상이 되는 실체를 사각형으로 정의한다.
    • 속성 상세화: 각 엔티티가 가지는 세부 정보와 성격을 정의하며, 기본키와 일반 속성을 구분한다.
    • 관계 설정: 엔티티 간의 논리적인 연결을 선으로 표현하며, 의존 관계나 참조 구조를 나타낸다.

0개의 댓글