데이터베이스와 DBMS 차이: 3단계 스키마와 데이터 독립성 이해하기

1장. 데이터베이스는 데이터를 저장하는 곳이 아니다#

고객이 이사를 했습니다.

고객센터 직원은 회원 정보를 열어 주소를 서울에서 대전으로 변경했습니다. 회원 화면에서도 새 주소가 정상적으로 표시됩니다.

그런데 며칠 뒤 문제가 발견됩니다.

지난달에 배송이 끝난 주문의 배송 주소까지 대전으로 바뀌어 있었습니다.

분명 고객의 현재 주소는 대전이 맞습니다. 하지만 지난달 주문이 배송된 장소는 서울입니다.

어느 쪽이 맞는 데이터일까요?

둘 다 맞습니다.

문제는 서로 다른 의미를 가진 데이터를 같은 정보처럼 취급했다는 것입니다.

현재 회원 주소는 지금 고객이 사는 곳을 나타냅니다. 반면 주문의 배송 주소는 해당 주문이 발생했던 시점의 사실을 기록해야 합니다.

이 차이를 구분하지 못하면 데이터베이스 안에 아무리 정확한 값이 들어 있어도 시스템은 잘못된 결과를 만들어냅니다.

데이터베이스를 공부할 때 많은 사람이 가장 먼저 SELECT, INSERT, UPDATE, DELETE 같은 SQL부터 떠올립니다.

하지만 SQL보다 먼저 이해해야 할 것이 있습니다.

어떤 데이터를 저장할 것인가.

그리고 그보다 더 중요한 질문이 있습니다.

그 데이터는 무엇을 의미하는가.

데이터베이스 설계는 결국 이 질문에서 시작합니다.

1.1 데이터와 데이터베이스는 다르다#

먼저 가장 기본적인 개념부터 구분해 보겠습니다.

회원 이름, 전화번호, 주문번호, 상품 가격처럼 하나하나의 값은 데이터입니다.

예를 들어 다음과 같은 정보가 있다고 하겠습니다.

회원ID 이름 주소
M01 김하늘 서울
M02 이바다 부산

이 표에 들어 있는 M01, 김하늘, 서울이라는 값들은 데이터입니다.

하지만 단순히 데이터를 많이 모아 놓았다고 해서 데이터베이스가 되는 것은 아닙니다.

데이터베이스는 조직이나 서비스에서 지속적으로 사용할 데이터를 일정한 구조와 규칙에 따라 통합하여 관리하는 데이터의 집합입니다.

즉 핵심은 저장량이 아니라 관리 구조입니다.

엑셀 파일에 고객 10만 명을 저장했다고 해서 자동으로 좋은 데이터베이스가 되는 것은 아닙니다.

반대로 회원이 100명뿐이라도 회원과 주문의 관계, 데이터 변경 규칙, 접근 권한, 데이터 무결성 등이 체계적으로 관리된다면 훨씬 제대로 된 데이터 관리 구조라고 할 수 있습니다.

1.2 데이터베이스의 네 가지 특징#

전통적으로 데이터베이스의 특징은 크게 다음 네 가지로 설명합니다.

특징 의미
통합 데이터 불필요한 중복을 줄이고 관련 데이터를 체계적으로 관리
저장 데이터 컴퓨터가 접근할 수 있는 저장 매체에 보존
운영 데이터 조직의 실제 업무를 수행하는 데 지속적으로 사용
공용 데이터 여러 사용자와 프로그램이 함께 사용

단순히 용어만 외우면 의미가 잘 와닿지 않습니다.

쇼핑몰을 예로 들어보겠습니다.

회원 정보가 다음과 같이 저장되어 있습니다.

회원ID 현재 이름 현재 주소
M01 김하늘 서울
M02 이바다 부산

그리고 주문 데이터가 있습니다.

주문ID 회원ID 배송 당시 주소 상태
O101 M01 서울 배송 완료
O102 M01 대전 접수
O103 M02 부산 접수

M01 회원이 서울에 살다가 대전으로 이사했다고 생각해 보겠습니다.

회원 테이블의 주소는 대전으로 변경됩니다.

그러나 O101 주문의 배송 당시 주소는 서울로 남아 있어야 합니다.

처음 보면 같은 주소를 회원 테이블과 주문 테이블에 두 번 저장했으므로 중복처럼 보입니다.

하지만 의미가 다릅니다.

회원 테이블의 주소는 현재 주소이고 주문 테이블의 주소는 주문 당시 배송지입니다.

따라서 이것은 무조건 제거해야 할 중복이 아닙니다.

데이터베이스 설계에서 중요한 것은 중복이 존재하느냐가 아니라 다음 질문입니다.

왜 이 값을 따로 저장해야 하는가?

그 이유를 설명할 수 있어야 합니다.

현재 상태와 과거 이력처럼 서로 다른 사실을 보존하기 위한 중복은 필요할 수 있습니다.

반대로 같은 고객 이름을 여러 시스템에 복사해 두고 어느 데이터가 원본인지 알 수 없다면 문제가 됩니다.

회원 이름을 변경했는데 고객센터에서는 새 이름이 나오고 배송 시스템에서는 이전 이름이 나온다면 데이터 일관성이 깨진 것입니다.

따라서 통합 데이터란 모든 중복을 없앤다는 의미가 아닙니다.

데이터의 의미와 변경 책임을 명확히 관리한다는 뜻에 더 가깝습니다.

1.3 그렇다면 DBMS는 무엇인가#

여기서 데이터베이스와 DBMS를 혼동하기 쉽습니다.

둘은 같은 것이 아닙니다.

데이터베이스는 관리 대상인 데이터의 집합입니다.

**DBMS(Database Management System)**는 그 데이터베이스를 생성하고 조회하고 변경하고 통제하는 소프트웨어입니다.

대표적인 DBMS에는 PostgreSQL, MySQL, Oracle Database, Microsoft SQL Server, SQLite 등이 있습니다.

쉽게 비유하면 다음과 같습니다.

데이터베이스가 도서관에 보관된 책과 자료라면 DBMS는 자료를 등록하고 검색하고 대출 권한을 확인하고 기록을 관리하는 도서관 운영 시스템에 가깝습니다.

데이터만 존재한다고 관리가 되는 것은 아닙니다.

쇼핑몰에서 고객이 주문 버튼을 눌렀다고 생각해 보겠습니다.

시스템에서는 여러 작업이 연속해서 발생할 수 있습니다.

  1. 주문을 생성합니다.
  2. 회원이 실제 존재하는지 확인합니다.
  3. 재고가 충분한지 확인합니다.
  4. 재고를 감소시킵니다.
  5. 결제 결과를 기록합니다.
  6. 주문 상태를 변경합니다.

이 가운데 하나라도 실패하면 어떻게 해야 할까요?

결제는 완료됐는데 주문이 저장되지 않을 수도 있습니다.

주문은 저장됐는데 재고 감소에 실패할 수도 있습니다.

동시에 두 사람이 마지막 남은 상품 하나를 주문할 수도 있습니다.

단순한 데이터 저장만으로는 이런 상황을 해결할 수 없습니다.

이때 DBMS가 필요합니다.

1.4 DBMS가 담당하는 세 가지 핵심 역할#

DBMS의 기능은 크게 정의, 조작, 제어라는 관점에서 이해할 수 있습니다.

정의#

어떤 데이터를 어떤 구조로 저장할지를 정합니다.

예를 들어 다음과 같은 구조를 만들 수 있습니다.

CREATE TABLE member (
    member_id VARCHAR(20) PRIMARY KEY,
    name VARCHAR(100) NOT NULL
);

여기서는 회원ID와 이름이라는 열을 만들고 member_id를 기본키로 지정했습니다.

즉 데이터가 따라야 할 구조와 규칙을 정의한 것입니다.

조작#

저장된 데이터를 조회하거나 추가하거나 수정하거나 삭제합니다.

SELECT *
FROM member;
INSERT INTO member
VALUES ('M01', '김하늘');
UPDATE member
SET name = '김하늘'
WHERE member_id = 'M01';

이런 작업은 실제 데이터를 다루는 조작 기능에 해당합니다.

제어#

사용자가 아무 데이터나 마음대로 변경하게 둘 수는 없습니다.

DBMS는 권한, 동시성, 트랜잭션, 복구 등 데이터의 안정성을 유지하기 위한 기능도 제공합니다.

예를 들어 고객센터 직원에게 주문 조회 권한은 주되 결제 정보를 임의로 변경할 권한은 주지 않을 수 있습니다.

또한 여러 사용자가 동시에 같은 데이터를 수정하는 상황도 관리해야 합니다.

1.5 마지막 재고 한 개를 두 사람이 동시에 주문한다면#

DBMS의 필요성은 동시 사용 상황에서 더 명확하게 드러납니다.

상품 A의 재고가 하나 남아 있다고 가정해 보겠습니다.

두 명의 고객이 거의 동시에 주문 버튼을 누릅니다.

고객 A가 재고를 조회합니다.

재고 = 1

고객 B도 거의 같은 순간 재고를 조회합니다.

재고 = 1

두 프로그램 모두 이렇게 판단할 수 있습니다.

재고가 있으므로 주문 가능.

그 결과 두 주문이 모두 승인된다면 어떻게 될까요?

실제 상품은 하나인데 두 명에게 판매한 셈입니다.

이런 문제는 프로그램 코드에서 단순히 다음처럼 처리한다고 해결되지 않습니다.

재고 조회
→ 재고가 1 이상인지 확인
→ 주문 생성
→ 재고 감소

재고를 읽은 순간과 감소시키는 순간 사이에 다른 요청이 들어올 수 있기 때문입니다.

따라서 실제 시스템에서는 트랜잭션, 잠금, 격리 수준, 조건부 갱신 등 다양한 방법을 이용해 동시 변경을 제어합니다.

DBMS는 단순한 데이터 저장 프로그램이 아니라 여러 사용자가 같은 데이터를 동시에 안전하게 사용할 수 있게 하는 관리 시스템입니다.

1.6 파일 시스템과 데이터베이스의 진짜 차이#

데이터베이스를 처음 배울 때 다음과 같은 설명을 접하기도 합니다.

파일 시스템은 데이터가 중복되지만 데이터베이스는 중복이 없다.

정확한 설명은 아닙니다.

데이터베이스에도 중복은 존재할 수 있습니다.

앞에서 살펴본 주문 당시 배송 주소처럼 의도적으로 같은 값이 저장되는 경우도 있습니다.

반대로 파일을 사용한다고 해서 반드시 데이터 관리가 엉망인 것도 아닙니다.

파일 기반 시스템도 충분히 잘 설계할 수 있습니다.

핵심적인 차이는 데이터를 어떤 관리 체계 안에서 다루느냐입니다.

DBMS는 일반적으로 다음과 같은 문제를 하나의 시스템 안에서 관리합니다.

  • 데이터 구조
  • 무결성 규칙
  • 관계
  • 접근 권한
  • 동시성
  • 트랜잭션
  • 장애 복구
  • 데이터 조회와 변경

즉 DBMS를 사용하는 가장 큰 이유는 데이터를 단순히 한곳에 모으기 위해서가 아닙니다.

데이터가 잘못된 상태로 변하는 것을 통제하기 위해서입니다.

2장. 같은 데이터인데 왜 사용자마다 다르게 보여야 할까#

이번에는 고객센터 직원과 물류 담당자가 같은 주문을 조회한다고 생각해 보겠습니다.

고객센터 직원에게 필요한 정보는 다음과 같습니다.

  • 주문번호
  • 고객 이름
  • 주문 상태
  • 문의 내용

물류 담당자에게 필요한 정보는 다릅니다.

  • 주문번호
  • 수령인
  • 배송 주소
  • 송장번호
  • 배송 상태

같은 주문 데이터를 사용하지만 필요한 정보는 서로 다릅니다.

그렇다고 고객센터용 주문 데이터베이스와 물류용 주문 데이터베이스를 각각 만들어야 할까요?

그럴 필요는 없습니다.

하나의 데이터베이스를 사용하면서 사용자와 업무에 따라 서로 다른 관점을 제공하면 됩니다.

이 생각을 체계적으로 설명하는 것이 3단계 스키마 구조입니다.

2.1 스키마란 무엇인가#

스키마는 쉽게 말하면 데이터베이스의 구조를 정의한 설계 정보입니다.

어떤 테이블이 있는지, 어떤 열이 있는지, 어떤 관계를 맺는지, 어떤 제약조건이 존재하는지 등을 나타냅니다.

여기서 중요한 것은 스키마와 실제 데이터를 구분하는 것입니다.

예를 들어 다음 구조가 있다고 하겠습니다.

회원(
    회원ID,
    이름,
    주소
)

이것은 구조를 설명하므로 스키마에 해당합니다.

반면 다음 값은 실제 저장된 데이터입니다.

M01, 김하늘, 서울

특정 시점에 실제 저장되어 있는 데이터의 상태를 인스턴스라고 부릅니다.

스키마는 상대적으로 자주 변하지 않지만 인스턴스는 주문이 발생하고 회원 정보가 수정될 때마다 계속 달라집니다.

3장. 데이터베이스의 3단계 스키마#

데이터베이스 구조를 바라보는 관점은 크게 세 단계로 나눌 수 있습니다.

사용자와 프로그램
        ↓
외부 스키마
        ↓
개념 스키마
        ↓
내부 스키마
        ↓
실제 저장 장치

각 단계는 서로 다른 질문에 답합니다.

3.1 외부 스키마 — 사용자에게 무엇을 보여줄 것인가#

외부 스키마는 특정 사용자나 프로그램이 데이터베이스를 바라보는 관점입니다.

고객센터 직원에게는 다음과 같이 보일 수 있습니다.

주문번호
고객명
주문일
주문상태

반면 물류팀에는 다음 정보가 보일 수 있습니다.

주문번호
수령인
배송지
송장번호
배송상태

두 화면이 사용하는 원본 데이터는 같을 수 있습니다.

하지만 업무 목적이 다르기 때문에 필요한 정보도 달라집니다.

외부 스키마는 이런 차이를 표현합니다.

그리고 외부 스키마는 하나만 존재해야 하는 것이 아닙니다.

고객센터, 물류, 재무, 관리자, 모바일 앱 등 여러 사용자와 프로그램에 따라 다양한 외부 관점이 존재할 수 있습니다.

3.2 개념 스키마 — 시스템 전체의 데이터 구조#

개념 스키마는 특정 사용자의 화면이 아니라 데이터베이스 전체의 논리적 구조를 설명합니다.

예를 들어 쇼핑몰이라면 다음과 같은 구조를 생각할 수 있습니다.

회원
 └─ 회원ID
 └─ 이름
 └─ 현재주소

주문
 └─ 주문ID
 └─ 회원ID
 └─ 주문일
 └─ 배송주소
 └─ 주문상태

그리고 다음 관계가 존재합니다.

회원 1 : N 주문

회원 한 명이 여러 주문을 할 수 있다는 의미입니다.

이 단계에서는 다음과 같은 내용을 정의합니다.

  • 어떤 테이블이 존재하는가
  • 어떤 속성을 가지고 있는가
  • 기본키는 무엇인가
  • 외래키는 무엇인가
  • 테이블은 어떤 관계를 가지는가
  • 어떤 데이터가 허용되는가

즉 개발자나 데이터 모델러가 설계하는 논리적인 데이터 구조가 개념 스키마에 가깝습니다.

3.3 내부 스키마 — 데이터를 실제로 어떻게 저장할 것인가#

내부 스키마는 데이터가 실제 저장 장치에서 어떻게 관리되는지에 관한 관점입니다.

예를 들어 주문 데이터가 많아져 주문일 검색이 느려졌다고 생각해 보겠습니다.

DBA가 주문일에 인덱스를 추가할 수 있습니다.

CREATE INDEX idx_orders_order_date
ON orders(order_date);

이 작업은 데이터를 찾는 방법을 바꿉니다.

하지만 사용자 입장에서 다음 SQL의 의미는 달라지지 않습니다.

SELECT *
FROM orders
WHERE order_date = '2026-10-01';

테이블의 논리적 구조도 그대로입니다.

바뀐 것은 데이터를 찾는 내부 방식입니다.

이것이 내부 스키마에서 다루는 대표적인 영역입니다.

스키마 핵심 질문
외부 스키마 사용자에게 무엇을 보여줄 것인가
개념 스키마 데이터 전체를 어떤 논리 구조로 표현할 것인가
내부 스키마 데이터를 실제로 어떻게 저장하고 접근할 것인가

이 세 단계를 구분하면 데이터베이스의 변경을 훨씬 명확하게 이해할 수 있습니다.

4장. 데이터 독립성이 필요한 이유#

서비스는 한번 만든 뒤 영원히 같은 구조를 사용하지 않습니다.

처음에는 회원 테이블이 단순할 수 있습니다.

회원
- 회원ID
- 이름
- 주소

서비스가 성장하면 요구사항이 늘어납니다.

회원
- 회원ID
- 성
- 이름
- 기본주소
- 상세주소
- 가입일
- 회원등급

데이터 구조는 계속 변합니다.

문제는 데이터베이스 구조를 변경할 때마다 모든 화면과 프로그램까지 다시 수정해야 한다면 시스템 유지보수 비용이 급격히 증가한다는 점입니다.

그래서 데이터베이스에는 중요한 설계 개념이 등장합니다.

데이터 독립성입니다.

데이터 독립성이란 한 단계의 구조가 변경되더라도 다른 단계에 미치는 영향을 가능한 한 줄이는 성질을 말합니다.

데이터 독립성은 크게 두 종류로 나뉩니다.

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

이 둘을 혼동하지 않는 것이 중요합니다.

5장. 논리적 데이터 독립성#

논리적 데이터 독립성은 개념 스키마가 변경되어도 외부 스키마나 응용 프로그램에 미치는 영향을 최소화하는 것입니다.

예를 들어 직원 정보를 다음 테이블 하나에서 관리했다고 하겠습니다.

직원
- 사번
- 이름
- 고용형태

서비스가 커지면서 정규직과 계약직을 별도로 관리하기로 했습니다.

구조가 다음과 같이 변경됩니다.

정규직원
- 사번
- 이름

계약직원
- 사번
- 이름

개념 스키마가 바뀐 것입니다.

그런데 기존 인사 시스템은 여전히 다음 구조를 기대합니다.

직원
- 사번
- 이름
- 고용형태

이때 기존 프로그램을 전부 수정하는 대신 뷰를 이용할 수 있습니다.

CREATE VIEW 직원 AS

SELECT
    사번,
    이름,
    '정규직' AS 고용형태
FROM 정규직원

UNION ALL

SELECT
    사번,
    이름,
    '계약직' AS 고용형태
FROM 계약직원;

실제 데이터 구조는 달라졌지만 기존 프로그램에서는 여전히 직원이라는 구조를 조회할 수 있습니다.

개념 구조 변경
        ↓
변환 또는 뷰
        ↓
기존 외부 관점 유지

이것이 논리적 데이터 독립성입니다.

5.1 논리적 독립성은 무조건 호환된다는 의미가 아니다#

여기서 중요한 주의점이 있습니다.

데이터 독립성이 있다고 해서 어떤 구조 변경도 기존 시스템에 영향을 주지 않는다는 의미는 아닙니다.

예를 들어 기존 프로그램이 직원 뷰에서 조회만 했다면 호환시키기 비교적 쉽습니다.

하지만 다음과 같이 직접 데이터를 추가했다면 문제가 복잡해질 수 있습니다.

INSERT INTO 직원
VALUES (1001, '김하늘', '정규직');

뷰의 구조와 DBMS에 따라 이런 쓰기 작업이 그대로 가능하지 않을 수도 있습니다.

따라서 데이터 독립성을 검증할 때는 단순히 화면이 뜨는지만 확인해서는 안 됩니다.

다음을 함께 확인해야 합니다.

  • 조회 결과
  • 데이터 입력
  • 수정
  • 삭제
  • 권한
  • 제약조건
  • 프로그램이 기대하는 반환 형식

논리적 데이터 독립성의 본질은 기존 사용자와 프로그램이 기대하는 데이터 계약을 얼마나 유지할 수 있느냐에 있습니다.

6장. 물리적 데이터 독립성#

물리적 데이터 독립성은 데이터의 내부 저장 구조가 바뀌더라도 개념적인 데이터 구조를 유지하는 것입니다.

주문 테이블이 있다고 하겠습니다.

주문
- 주문ID
- 회원ID
- 주문일
- 상태

처음에는 데이터가 적어 별도의 인덱스가 없어도 충분히 빨랐습니다.

하지만 주문이 수천만 건으로 늘어나면서 주문일 검색이 느려졌습니다.

그래서 인덱스를 추가합니다.

CREATE INDEX idx_orders_order_date
ON orders(order_date);

DBMS 내부에서는 데이터를 찾는 방식이 달라집니다.

하지만 응용 프로그램에서는 여전히 같은 SQL을 사용합니다.

SELECT *
FROM orders
WHERE order_date = '2026-10-01';

논리적인 테이블 구조도 바뀌지 않았습니다.

이것이 물리적 데이터 독립성입니다.

6.1 물리적 독립성과 성능은 다른 문제다#

인덱스를 만들었다고 해서 모든 것이 그대로인 것은 아닙니다.

조회 성능은 좋아질 수 있습니다.

하지만 INSERT와 UPDATE 비용은 증가할 수 있습니다.

새 행을 저장할 때 테이블뿐 아니라 인덱스도 함께 수정해야 하기 때문입니다.

저장 공간도 추가로 필요합니다.

따라서 물리적 데이터 독립성이 의미하는 것은 다음과 같습니다.

저장 방법을 바꿔도 데이터가 가진 논리적 의미를 유지한다.

다음 의미는 아닙니다.

저장 방법을 바꿔도 성능과 비용까지 모두 같다.

이 차이는 매우 중요합니다.

7장. 논리적 독립성과 물리적 독립성 한 번에 구분하기#

두 개념은 이름이 비슷해 처음에는 혼동하기 쉽습니다.

다음 질문 하나로 구분하면 훨씬 쉽습니다.

무엇을 바꿨는가?

테이블의 논리적인 구조를 변경했다면 논리적 데이터 독립성과 관련될 가능성이 큽니다.

인덱스나 저장 방식처럼 내부 구현을 변경했다면 물리적 데이터 독립성과 관련됩니다.

구분 논리적 데이터 독립성 물리적 데이터 독립성
변경 대상 개념 스키마 내부 스키마
보호 대상 외부 스키마 개념 스키마
대표 사례 테이블 구조를 변경하고 기존 화면 유지 인덱스를 변경하고 기존 테이블 구조 유지
사용자 영향 기존 화면·프로그램 영향 최소화 SQL과 논리 구조 영향 최소화
핵심 질문 구조를 바꿔도 기존 사용자가 같은 의미의 데이터를 볼 수 있는가 저장 방법을 바꿔도 논리적인 데이터 구조가 유지되는가

쉽게 정리하면 다음과 같습니다.

외부 스키마
   ↑
   │ 논리적 데이터 독립성
   │
개념 스키마
   ↑
   │ 물리적 데이터 독립성
   │
내부 스키마

이 그림을 기억하면 시험 문제뿐 아니라 실제 시스템 변경에서도 구분하기 쉬워집니다.

8장. 회원 이름을 두 개의 열로 나누면 어떤 일이 생길까#

조금 더 현실적인 사례를 살펴보겠습니다.

초기 시스템에서는 이름을 하나의 열에 저장했습니다.

member

id
name
address

서비스가 해외로 확장되면서 성과 이름을 별도로 관리해야 하는 요구사항이 생겼습니다.

member

id
last_name
first_name
address

논리적인 데이터 구조가 변경된 것입니다.

그런데 오래된 고객센터 프로그램에서는 여전히 name이라는 하나의 값을 요구합니다.

기존 프로그램을 모두 동시에 수정하기는 어렵습니다.

이럴 때 일정 기간 다음과 같은 호환 계층을 둘 수 있습니다.

CREATE VIEW legacy_member AS
SELECT
    id,
    last_name || first_name AS name,
    address
FROM member;

기존 프로그램에서는 계속 다음과 같이 조회할 수 있습니다.

SELECT id, name, address
FROM legacy_member;

새로운 구조를 사용하면서 기존 시스템의 관점을 일정 기간 유지하는 것입니다.

실제 시스템에서는 이름 표기 규칙, 다국어 이름, 공백, 정렬 순서 등 훨씬 복잡한 문제가 있으므로 문자열을 단순히 합치는 것만으로 해결되지 않을 수 있습니다.

중요한 것은 SQL 문법 자체가 아닙니다.

데이터 구조를 변경하더라도 기존 사용자와 프로그램의 계약을 어떻게 보호할 것인가라는 사고방식입니다.

9장. 주소 변경 사례로 데이터베이스 설계를 다시 바라보기#

처음의 주소 문제로 돌아가 보겠습니다.

회원 M01의 현재 주소가 서울에서 대전으로 변경됐습니다.

회원

M01 | 김하늘 | 대전

그런데 지난 주문은 다음과 같습니다.

O101 | M01 | 서울 | 배송 완료

두 주소가 다릅니다.

하지만 이것은 오류가 아닙니다.

오히려 두 값이 같아지면 문제가 될 수 있습니다.

회원 데이터가 답해야 하는 질문은 다음과 같습니다.

이 고객은 현재 어디에 살고 있는가?

주문 데이터가 답해야 하는 질문은 다릅니다.

이 주문은 당시 어디로 배송되었는가?

같은 주소라는 단어를 사용하지만 의미가 다릅니다.

데이터 모델링에서 가장 위험한 실수 가운데 하나가 이름이 같다는 이유로 같은 데이터라고 판단하는 것입니다.

데이터는 이름보다 의미와 시점으로 구분해야 합니다.

9.1 외래키가 모든 문제를 해결해 주지는 않는다#

회원과 주문 사이에는 일반적으로 다음 관계를 만들 수 있습니다.

회원
  1
  │
  │
  N
주문

주문 테이블의 회원ID가 회원 테이블의 회원을 참조하도록 외래키를 설정할 수 있습니다.

FOREIGN KEY (member_id)
REFERENCES member(member_id)

그러면 존재하지 않는 회원 M99를 주문에 마음대로 넣는 것을 방지하는 데 도움이 됩니다.

하지만 외래키가 다음 문제까지 결정해 주지는 않습니다.

  • 회원 주소가 변경되면 과거 주문 주소도 바꿀 것인가
  • 탈퇴 회원의 주문 이력은 어떻게 보존할 것인가
  • 회원 이름 변경 시 영수증의 과거 이름은 유지할 것인가
  • 주문 당시 연락처를 별도로 보관할 것인가

이것들은 업무 규칙과 데이터 모델링의 문제입니다.

DBMS의 제약조건은 설계자가 정한 규칙을 강제할 수 있지만, 어떤 규칙이 옳은지 스스로 판단하지는 않습니다.

이 점이 중요합니다.

좋은 데이터베이스는 DBMS가 자동으로 만들어 주는 것이 아닙니다.

좋은 설계를 DBMS가 지켜 주도록 만드는 것입니다.

10장. ‘스키마’라는 단어에서 생기는 또 하나의 혼동#

데이터베이스를 공부하다 보면 다음과 같은 SQL을 만나게 됩니다.

CREATE SCHEMA sales;

여기서 혼동하기 쉽습니다.

앞에서 배운 외부·개념·내부 스키마의 스키마와 SQL의 SCHEMA가 완전히 같은 개념이라고 생각하기 때문입니다.

하지만 문맥이 다릅니다.

PostgreSQL 같은 DBMS에서 스키마는 데이터베이스 객체를 구분하는 이름 공간(namespace)으로 사용됩니다.

예를 들어 다음처럼 같은 이름의 테이블을 서로 다른 스키마에 둘 수 있습니다.

sales.orders
archive.orders

sales.orders는 현재 주문을 관리하고 archive.orders는 보관 데이터를 관리하도록 설계할 수 있습니다.

반면 3단계 스키마 구조에서 말하는 외부·개념·내부 스키마는 데이터베이스를 바라보는 추상화 수준을 의미합니다.

같은 단어를 사용한다고 해서 동일한 개념은 아닙니다.

따라서 문맥을 보고 구분해야 합니다.

11장. 데이터 독립성을 실무에서는 어떻게 확인할까#

데이터 독립성은 시험 문제에서 정의를 고르는 것으로 끝나는 개념이 아닙니다.

실제 시스템을 변경할 때 매우 현실적인 질문이 됩니다.

예를 들어 주문 테이블에 새로운 인덱스를 추가했다고 해 보겠습니다.

변경 전 조회 결과가 120건이었다면 변경 후에도 같은 조건에서는 같은 120건이 나와야 합니다.

하지만 처리 속도는 달라질 수 있습니다.

이것이 물리적 데이터 독립성 검증입니다.

이번에는 회원 이름 구조를 변경했다고 하겠습니다.

name

을

last_name
first_name

으로 바꿨습니다.

고객센터 화면에서 기존과 같은 의미의 고객 이름이 표시되는지 확인해야 합니다.

하지만 그것만으로 부족합니다.

다음도 함께 확인해야 합니다.

  • 고객 이름 수정이 되는가
  • 검색이 정상적으로 되는가
  • 기존 API가 같은 형식으로 응답하는가
  • 권한이 유지되는가
  • 기존 배치 프로그램이 정상 동작하는가

이것이 논리적 데이터 독립성을 실제 시스템에서 바라보는 방법입니다.

12장. 데이터베이스 변경에서 가장 먼저 확인해야 할 것#

데이터베이스 구조를 변경해야 한다는 요구가 들어오면 개발자는 흔히 가장 먼저 SQL부터 생각합니다.

하지만 그보다 먼저 확인해야 하는 것이 있습니다.

이 데이터가 무엇을 의미하는가?

회원 주소를 변경한다고 했을 때도 질문해야 합니다.

현재 주소인가요?

배송 주소인가요?

청구 주소인가요?

주문 당시 주소인가요?

마찬가지로 이름도 그렇습니다.

현재 이름인가요?

계약 당시 이름인가요?

배송 당시 수령인 이름인가요?

데이터의 의미가 정의되지 않은 상태에서 테이블부터 수정하면 나중에 더 큰 문제가 생깁니다.

데이터베이스 설계의 핵심은 컬럼을 만드는 기술보다 현실의 사실을 어떤 구조로 표현할 것인가를 결정하는 일입니다.

13장. 데이터베이스를 이해하면 변경이 다르게 보인다#

처음 데이터베이스를 공부하면 테이블과 SQL이 가장 눈에 띕니다.

하지만 실제 시스템에서 더 중요한 것은 변화입니다.

사용자 요구사항은 계속 바뀝니다.

데이터는 증가합니다.

서비스 기능도 늘어납니다.

기존 프로그램은 한 번에 모두 교체할 수 없습니다.

그래서 좋은 데이터베이스 구조는 단지 오늘의 데이터를 저장하는 데 그치지 않습니다.

내일 구조가 바뀌더라도 시스템 전체가 무너지지 않도록 경계를 만들어야 합니다.

외부 스키마는 사용자와 프로그램이 보는 세계를 정의합니다.

개념 스키마는 시스템 전체의 논리적인 데이터 구조를 정의합니다.

내부 스키마는 데이터를 실제로 저장하고 접근하는 방법을 담당합니다.

그리고 이 계층 사이의 영향을 줄이는 것이 데이터 독립성입니다.

정리하면 다음과 같습니다.

사용자의 관점
      ↓
외부 스키마
      ↓
논리적 데이터 독립성
      ↓
개념 스키마
      ↓
물리적 데이터 독립성
      ↓
내부 스키마
      ↓
저장 장치

이 구조를 이해하면 데이터베이스를 단순한 저장소가 아니라 변화를 견디도록 설계된 데이터 관리 시스템으로 바라볼 수 있습니다.

14장. 핵심 정리#

데이터베이스는 조직이나 서비스에서 지속적으로 사용할 데이터를 통합하여 관리하는 데이터의 집합입니다.

DBMS는 데이터베이스를 정의하고 조회하고 변경하며 권한·동시성·트랜잭션·복구 등을 관리하는 소프트웨어입니다.

데이터베이스의 대표적인 특징은 통합 데이터, 저장 데이터, 운영 데이터, 공용 데이터입니다.

그러나 통합 데이터라고 해서 모든 중복을 제거해야 하는 것은 아닙니다.

현재 주소와 주문 당시 배송 주소처럼 의미와 시점이 다르다면 의도적인 중복이 필요할 수 있습니다.

3단계 스키마는 다음과 같이 구분합니다.

  • 외부 스키마: 사용자와 프로그램이 보는 데이터
  • 개념 스키마: 데이터베이스 전체의 논리적 구조
  • 내부 스키마: 데이터의 물리적인 저장 및 접근 구조

그리고 데이터 독립성은 다음과 같이 구분합니다.

  • 논리적 데이터 독립성: 개념 스키마가 변경되어도 외부 관점에 미치는 영향을 최소화
  • 물리적 데이터 독립성: 내부 스키마가 변경되어도 개념 구조에 미치는 영향을 최소화

마지막으로 가장 중요한 한 문장을 기억하면 됩니다.

데이터베이스 설계에서 중요한 것은 데이터를 어디에 저장할 것인가보다, 그 데이터가 무엇을 의미하며 변경될 때 무엇을 지켜야 하는지를 결정하는 것이다.

이 페이지의 목차