DB 스키마란?(Schema)

스키마는 개체의 특성을 나타내는 속성(Attribute)과 속성들의 집합으로 이루어진 개체(Entity), 개체 사이에 존재하는 관계(Relation)에 대한 정의와 이들이 유지해야 할 제약조건을 정의한다.

`Employee`, `Department` 및 `Project` 라는 세 개의 테이블이 있다고 가정한다.
따라서 다음과 같이 스키마 다이어그램을 사용하여 이 세 테이블의 스키마를 나타낼 수 있다.
해당 스키마 다이어그램에서 `Employee` 와 `Department` 는 관련되어 있고 `Employee` 와 `Project` 테이블은 관련되어 있다.

DB 스키마 아키텍처

DB 스키마 아키텍처는 데이터의 논리적 구성과 물리적 스토리지 및 사용자가 데이터와 상호 작용하는 방식을 분리하는 데이터베이스 설계 개념이다.

DB 스키마는 사용자의 관점에 따라서 외부, 개념, 내부 스키마로 구분 된다.

1. 외부 스키마(External Schema) - (User View)

User View라고도 하는 외부 스키마는 개별 사용자 또는 응용프로그램이 데이터를 인식하고 상호 작용하는 방식을 나타낸다. 각 사용자 또는 응용프로그램은 자신의 특정 요구사항과 액세스 권한에 맞게 조정된 서로 다른 외부 스키마를 가질 수 있다. 외부 스키마는 개념 스키마의 하위 집합으로, 관련 데이터에 초점을 맞추고 전체 데이터베이스의 복잡성을 숨긴다.

전체 데이터베이스의 한 논리적인 부분으로 볼 수 있으므로 서브 스키마라고도 한다.응용프로그래머가 각 개인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의한 것이다.

2. 개념 스키마(Conceptual Schema) - (Logical View)

Logical View라고 하는 개념 스키마는 물리적 스토리지 또는 구현 세부 정보와 관계없이 데이터베이스에 있는 데이터의 전체 논리적 구성을 나타낸다. 모든 테이블, 열, 관계, 제약 조건 및 기타 데이터베이스 개체를 정의한다. 개념 스키마는 외부 스키마와 내부 스키마를 연결하는 브리지 역할을 하여 모든 사용자 및 응용프로그램에 대한 일관된 데이터 보기를 제공한다.

단순히 스키마라고 하면 개념 스키마를 의미하는 것이다. 데이터베이스 파일에 저장되는 데이터의 형태를 나타내는 것으로 DBA에 의해 구성된다.

3. 내부 스키마(Internal Schema) - (Physical View)

Physical View라고 하는 내부 스키마는 Hard Disk 또는 SSD(Solid-State Drives)와 같은 스토리지 미디어에 있는 데이터의 실제 물리적 저장소 및 구성을 나타낸다. 여기에는 파일 구조, 인덱싱 방법 및 데이터 저장 형식과 같은 세부 정보가 포함된다. 내부 스키마는 데이터와 상호 작용하는 사용자 및 애플리케이션으로부터 이러한 세부 정보를 숨기면서 데이터 저장, 액세스 및 검색을 최적화하는 것과 관련이 있다. 시스템 프로그래머나 시스템 설계자가 보는 관점의 스키마이다.

요약하자면, 데이터베이스 스키마의 개념은 데이터베이스 시스템의 데이터 구조 및 구성을 정의한다.
반면, 3개 스키마 아키텍처(외부, 개념 및 내부 스키마)는 데이터의 논리적 구성을 물리적 스토리지 및 사용자 상호 작용으로부터 분리하기 위한 프레임워크를 제공한다.

DB 스키마와 DB 인스턴스 (Schema vs. Instance)

스키마(Schema)와 인스턴스(Instance)는 데이터베이스 개념에서 중요한 개념이다.

스키마(Schema)
- 데이터베이스의 구조(Structure) 를 정의한 것.
- 데이터베이스에 어떤 테이블, 컬럼, 관계, 제약 조건 등이 있는지를 명세하는 설계도 같은 역할을 함.
- 시간이 지나도 변하지 않는 정적인 성격 을 가짐.

인스턴스(Instance)
- 특정 시점에서 DB에 저장된 실제 데이터 를 의미함.
- 시간이 지남에 따라 데이터가 추가/변경/삭제되면서 계속 변하는 동적인 성격 을 가짐.

비유

스키마는 건물 설계도, 인스턴스는 실제 건물에 사는 사람들과 가구 같은 개념!

DB 스키마와 테이블 스키마 (Schema vs. Table Schema)

DB 스키마는 전체적인 데이터베이스의 구조를 정의하는 반면, 테이블 스키마(Table Schema) 는 특정 테이블의 구조를 정의하는 개념이다.

예시: Employee 테이블 스키마

CREATE TABLE Employee (
    emp_id INT PRIMARY KEY,
    name VARCHAR(50),
    department_id INT,
    salary DECIMAL(10,2),
    CONSTRAINT fk_department FOREIGN KEY (department_id) REFERENCES Department(department_id)
);

위 예제에서 Employee 테이블은 각 컬럼의 타입, 기본 키, 외래 키 등을 정의하는 테이블 스키마를 포함하고 있다.

DB 스키마의 제약 조건 (Constraints)

스키마에는 단순히 테이블을 정의하는 것뿐만 아니라 데이터 무결성을 유지하기 위한 제약 조건(Constraints) 도 포함된다.

주요 제약 조건 종류

Primary Key (기본 키): 한 테이블에서 각 행을 유일하게 식별하는 키 (예: `emp_id`)
Foreign Key (외래 키): 다른 테이블과의 관계를 정의 (예: `department_id`)
Unique: 중복을 허용하지 않음 (예: `email 컬럼`)
Not Null: 반드시 값이 존재해야 함 (예: `name 컬럼`)
Check: 특정 조건을 만족해야 함 (예: `salary > 0`)

DB 스키마 설계 시 고려할 요소

데이터베이스 스키마를 설계할 때 다음과 같은 점을 고려해야 한다.

정규화(Normalization)
- 데이터 중복을 최소화 하여 효율적인 데이터 저장 구조를 설계해야 함.
- 1NF, 2NF, 3NF 등의 정규화 과정이 있음.

반정규화(Denormalization) 고려
- 정규화된 데이터를 성능 개선을 위해 일부 중복을 허용하는 방식.
- 자주 조회하는 데이터를 조인 연산 없이 빠르게 가져올 수 있음.

인덱스(Index) 설정
- 검색 속도를 빠르게 하기 위해 적절한 인덱스를 설정해야 함.
- 너무 많은 인덱스를 설정하면 INSERT/UPDATE 성능이 저하될 수 있음.

트랜잭션과 동시성 제어
- 데이터 일관성을 유지하기 위해 트랜잭션을 고려해야 함.
- ACID 원칙(Atomicity, Consistency, Isolation, Durability)을 준수하는 것이 중요함.

데이터베이스 스키마 유형

DBMS에 따라 스키마를 정의하는 방식이 다를 수 있다.

관계형 데이터베이스 (RDBMS)
- MySQL, PostgreSQL, Oracle, SQL Server 등
- 테이블 기반 스키마 정의 (`CREATE TABLE, ALTER TABLE`등)

NoSQL 데이터베이스
- MongoDB, Cassandra, DynamoDB 등
- 스키마리스(Schema-less) 구조도 가능하지만, 모델링이 중요함.
- JSON/BSON 같은 문서 기반 저장 구조를 가짐.

DB 스키마 변경 (Schema Evolution)

운영 중인 데이터베이스의 스키마를 변경해야 할 경우 마이그레이션(Migration) 과정이 필요하다.

DDL (Data Definition Language) 사용
- `ALTER TABLE ADD COLUMN`
- `ALTER TABLE DROP COLUMN`
- `ALTER TABLE MODIFY COLUMN`

데이터 마이그레이션 툴 활용
- Flyway, Liquibase 같은 DB 마이그레이션 도구 사용 가능

주의할 점

기존 데이터를 보호하는 전략 필요 (백업, 데이터 변환 등)
서비스 중단 최소화 를 위해 롤링 업데이트 방식 적용

DB 스키마와 성능 최적화

스키마 설계 시 성능을 고려해야 한다.

JOIN 최적화
- 관계형 데이터베이스는 JOIN이 많으면 성능이 저하될 수 있음.
- 외래 키(Foreign Key)를 적절히 사용하고, 필요하면 중복 데이터 허용.

파티셔닝(Partitioning) 활용
- 대량의 데이터를 처리할 때 테이블을 여러 개로 분할하여 성능 개선.
- RANGE, LIST, HASH 파티셔닝 전략 활용.

캐싱(Caching) 도입
- 자주 조회하는 데이터를 캐싱(DB 캐시, Redis 활용)하여 성능 개선.

ERD (Entity-Relationship Diagram)와 스키마의 관계

ERD(Entity-Relationship Diagram)는 데이터베이스를 설계할 때 데이터 간의 구조와 관계를 시각적으로 표현한 다이어그램이다.
스키마 설계의 초기 단계에서 핵심 개체, 속성, 관계를 정의하고 이해관계자 간 커뮤니케이션 도구로 활용된다.

ERD → 논리적 모델 → 스키마 구현 흐름

ERD 작성 (개념적 모델링)
- 비즈니스 개체(Entity), 속성(Attribute), 관계(Relationship) 도출
- 예: User, Order, Product 간의 관계 및 주요 속성 시각화
논리적 모델 변환
- 관계형 모델(RDBMS)에 맞게 테이블, 컬럼, 제약 조건으로 변환
- 정규화(NF) 적용 → 중복 최소화
스키마 구현 (DDL)
- SQL DDL로 실제 DBMS에 테이블/제약조건 생성
- `CREATE TABLE`, `FOREIGN KEY`, `PRIMARY KEY` 등

ERD는 “데이터 설계의 청사진”
스키마는 “ERD의 실현된 SQL 결과물”

간단 예시

ERD 예 (개념적 설계)

[User] ------------< [Order] >------------ [Product]
 user_id             order_id              product_id
 name                user_id (FK)          name
 email               product_id (FK)       price

스키마 예 (SQL DDL)

CREATE TABLE User (
  user_id INT PRIMARY KEY,
  name VARCHAR(100),
  email VARCHAR(100) UNIQUE NOT NULL
);

CREATE TABLE Product (
  product_id INT PRIMARY KEY,
  name VARCHAR(100),
  price DECIMAL(10, 2)
);

CREATE TABLE Order (
  order_id INT PRIMARY KEY,
  user_id INT,
  product_id INT,
  FOREIGN KEY (user_id) REFERENCES User(user_id),
  FOREIGN KEY (product_id) REFERENCES Product(product_id)
);

ERD 설계 도구

도구	특징
dbdiagram.io	간단한 코드 기반 ERD 설계 및 SQL 추출 지원
draw.io	자유도 높은 도식화 도구, ERD 템플릿 제공
MySQL Workbench	MySQL 전용, 시각적 모델링 → 자동 DDL 생성
ERD Cloud, Lucidchart, DBeaver, SQLDBM 등	협업과 실시간 공유 기능 지원

정리

ERD는 개념적인 구조와 관계를 시각적으로 표현
스키마는 ERD 설계를 기반으로 실제 DB에 구현된 논리적/물리적 구조
설계 흐름: ERD → 논리 모델링 → SQL DDL 스키마 구현
좋은 ERD 설계는 유지보수성과 확장성이 뛰어난 데이터베이스 구조의 출발점!

스키마 버전 관리 전략

스키마 버전 관리(Schema Versioning)는 DB 구조 변경 이력을 추적하고, 협업 및 배포 환경에서의 일관성을 유지하기 위한 필수 전략이다. 애플리케이션은 코드만 버전 관리해서는 안 되고, DB 구조도 동일한 수준의 이력 관리가 필요하다.

왜 스키마 버전 관리가 중요한가?

협업 중 누가, 언제, 어떤 변경을 했는지 추적 가능
운영 환경과 개발 환경 간 스키마 불일치 방지
롤백 및 환경 재현 용이 (테스트 환경, CI/CD, 로컬 셋업 등)
자동 배포 파이프라인에서 스키마 업데이트 자동화 가능

스키마 마이그레이션 도구

Flyway

Java 기반의 오픈소스 도구
versioned SQL 파일을 순차적으로 실행하여 변경 이력을 관리
Spring Boot와 통합에 적합하며, CI/CD 파이프라인에서 널리 사용됨

V1__create_users_table.sql
V2__add_email_column.sql

Liquibase

`XML, YAML, JSON, SQL` 등 다양한 방식으로 마이그레이션 스크립트 작성 가능
변경 이력을 `DATABASECHANGELOG` 테이블에 저장
트랜잭션 단위 적용 및 rollback 기능이 강점

마이그레이션 방식 비교

항목	Versioned Migration	State-based Migration
설명	각 변경을 순차적인 파일로 기록 (V1__init.sql, V2__alter.sql)	현재 DB 구조(State)를 기준으로 이전 상태와 비교해 자동 스크립트 생성
대표 도구	Flyway, Liquibase (SQL mode)	Liquibase (Diff mode), Atlas
장점	명확한 변경 이력 추적, 수동 제어	빠른 스키마 정합성 확보, 자동화에 유리
단점	스크립트 누락 시 오류 발생	자동 비교 결과에 대한 신뢰성 필요
사용 시기	협업, 코드 리뷰 중심 환경	빠르게 변하는 구조, 자동화 중심 환경

실무 팁

Git에 마이그레이션 폴더 분리 관리 (예: `/db/migration`)
팀 코드 리뷰 시, DDL 변경도 리뷰에 포함시키기
스테이징 환경에서 항상 자동 테스트 + 마이그레이션 검증 수행
모든 환경(DB, 애플리케이션)이 동일한 마이그레이션 버전을 유지하도록 관리

멀티 테넌시(Multi-Tenancy)와 스키마 전략

멀티 테넌시는 하나의 애플리케이션 인스턴스가 여러 고객(테넌트)에게 서비스를 제공하는 아키텍처이다.
SaaS 기반 시스템, 대규모 플랫폼에서 필수적으로 고려되는 전략이다.

멀티 테넌시 스키마 설계 전략

전략	설명	장점	단점
1. 단일 스키마 전략 (Shared Schema)	모든 고객 데이터를 하나의 스키마, 테이블에 함께 저장. 테이블에 tenant_id 컬럼을 추가해 구분	관리 간편, 유지보수 용이	보안 취약 가능성, 쿼리 복잡도 증가
2. 분리된 스키마 전략 (Schema-per-Tenant)	고객마다 고유한 스키마 제공 (tenant_a.orders, tenant_b.orders)	보안 강화, 데이터 충돌 방지	스키마 관리 부담, 마이그레이션 복잡
3. 분리된 데이터베이스 전략 (Database-per-Tenant)	고객마다 완전한 DB 분리	완전한 격리, 독립적 백업 가능	리소스 소비 증가, 운영 부담 큼

전략 선택 시 고려사항

보안 요구 수준, 고객 수, 유지보수 인력, 데이터 격리 요구사항, 확장성

보안 관점에서의 스키마 권한 관리

스키마 단위 혹은 개별 테이블에 대해 접근 권한을 제한하여 보안을 강화할 수 있다.
특히 멀티 테넌시 환경이나 데이터 민감도가 높은 시스템에서 중요하다.

주요 명령어: GRANT, REVOKE

GRANT: 특정 객체에 대한 권한을 사용자에게 부여
REVOKE: 기존에 부여한 권한을 제거

예시 (PostgreSQL / MySQL / Oracle)

-- 읽기 전용 사용자에게 특정 테이블의 조회 권한 부여
GRANT SELECT ON sales.customer_orders TO readonly_user;

-- 쓰기 권한까지 부여
GRANT SELECT, INSERT, UPDATE ON hr.employee TO hr_manager;

-- 프로시저 실행 권한 부여 (Oracle 기준)
GRANT EXECUTE ON hr.calculate_bonus TO auditor;

-- 권한 회수
REVOKE INSERT, UPDATE ON hr.employee FROM hr_manager;

스키마 단위 권한 부여 (PostgreSQL 예)

-- 스키마에 접근할 수 있도록 USAGE 권한 부여
GRANT USAGE ON SCHEMA tenant_a TO app_user;

-- 특정 테이블에 SELECT 권한 부여
GRANT SELECT ON tenant_a.orders TO app_user;

주의: 테이블 접근을 허용하려면 해당 스키마에 대한 USAGE 권한이 먼저 있어야 함

실무 팁

멀티 테넌시에서는 Row-Level Security (RLS) 또는 View 기반 필터링도 자주 활용됨
정기적으로 권한 감사(audit) 수행
최소 권한 원칙(Principle of Least Privilege)을 따를 것

정리

멀티 테넌시 환경에서는 단일/분리 스키마 또는 DB 전략 중 선택 필요
보안 강화를 위해 사용자에게 필요한 최소 권한만 정밀하게 부여
스키마 전략과 권한 관리의 조합은 유지보수성, 성능, 보안에 직결됨

NoSQL vs RDBMS 스키마 설계 차이 요약

항목	RDBMS	NoSQL (예: MongoDB)
구조	고정 스키마	유연한/스키마리스
관계	테이블 간 명시적 관계	Embedded Document로 관계 표현
정규화	중요	반정규화가 일반적
제약 조건	강력한 제약 설정 가능	제약 조건 없음 (앱 로직으로 처리)

마무리

데이터베이스 스키마는 단순한 구조 설계를 넘어 데이터의 효율적인 관리와 성능 최적화를 결정하는 핵심 요소이다.

좋은 스키마 설계는 데이터 무결성을 보장하며, 유지보수를 쉽게 만든다.
정규화와 반정규화를 적절히 활용하여 성능을 최적화해야 한다.
스키마 변경 시에는 마이그레이션(Migration) 전략을 신중하게 계획해야 한다.

이번 글을 통해 DB 스키마의 개념과 중요성을 이해하고, 효율적인 데이터베이스 설계를 위한 기본 원칙을 익히는 데 도움이 되길 바란다.

Reference

What is Schema?(After Academy)

What is a Database Schema?

728x90

'Database' 카테고리의 다른 글

데이터베이스 인덱스(Index) 최적화 방법 (4)	2025.03.21
DB 샤딩(Sharding): 개념 및 동작방식 (0)	2024.05.10
PostgreSQL 개념 및 특징(with MySQL) (0)	2024.03.29
MongoDB란? (2)	2023.05.20
Mariadb란? (사용법) (0)	2022.01.14

현재글DB 스키마란?(Schema)