[하루 1 CS] 데이터베이스 4 - 데이터베이스 설계 과정

관계형 데이터베이스의 키와 데이터베이스의 연관 관계에 대해 알아봤으니, 이번에는 데이터베이스를 실제로 어떻게 설계하는지 그 과정을 살펴보겠다.

그냥 테이블 바로 만들면 안 될까? 라는 생각이 들 수 있다. 물론 간단한 토이 프로젝트라면 상관없겠지만, 어느 정도 규모가 있는 시스템이라면 설계 없이 만들었다가 나중에 구조를 갈아엎는 상황이 반드시 온다.

 

따라서 체계적인 설계 과정이 필요하다.

데이터베이스 설계는 크게 다음과 같은 5단계로 진행된다.

1. 요구사항 분석
2. 개념적 설계
3. 논리적 설계
4. 물리적 설계
5. 구현

이제 하나씩 알아보겠다.

---

1. 요구사항 분석

첫 번째 단계이자 가장 중요한 단계다. 이 단계에서는 데이터베이스를 사용할 사람이 어떤 정보를 저장하고 조회해야 하는지를 파악한다.

쉽게 말해 "이 시스템에서 어떤 데이터가 필요하고, 누가 어떤 데이터에 접근하고 어떤 기능을 수행해야 하는가?"를 정리하는 과정이다.

요구사항 분석에서 수행하는 것들은 다음과 같다.

1. 사용자 인터뷰 또는 기획 문서 분석
2. 어떤 데이터 항목을 저장할 것인지 파악
3. 데이터 간의 관계 파악
4. 각 데이터의 특성 파악 (고유해야 하는지, 빈 값이 허용되는지 등)

예를 들어 학교 수강 신청 시스템을 만든다고 하면, "학생 정보, 강의 정보, 수강 신청 내역이 필요하다"는 게 나온다.

이 단계에서 제대로 정리하지 않으면, 나중에 빠진 정보가 생겨서 테이블을 추가하거나 기존 테이블을 대대적으로 수정해야 하는 상황이 온다.

---

2. 개념적 설계

요구사항을 바탕으로 실제 데이터베이스와는 독립적인 추상적인 데이터 구조를 만드는 단계다.

이 단계의 결과물은 ER 다이어그램(Entity-Relationship Diagram)이다. 쉽게 말해 데이터가 어떤 엔티티(Entity)들로 구성되고, 그것들이 서로 어떤 관계(Relationship)를 가지는지를 시각적으로 표현한 것이다.

ER 다이어그램을 그릴 때 핵심이 되는 요소는 다음 세 가지다.

• 엔티티(Entity): 데이터를 저장할 대상. 학생, 강의, 교수 같은 것들이다.
• 속성(Attribute): 엔티티가 가지는 특성. 학생이라면 학번, 이름, 학과 같은 것들이다.
• 관계(Relationship): 엔티티 간의 연관성. 학생은 강의를 수강한다, 교수는 강의를 담당한다.

이 단계에서는 특정 DBMS(MySQL, PostgreSQL 등)에 종속되지 않고 순수하게 개념적으로만 설계한다. 따라서 DBMS를 나중에 바꾸더라도 이 설계는 그대로 재사용할 수 있다.

---

3. 논리적 설계

개념적 설계에서 만든 ER 다이어그램을 실제 관계형 데이터베이스 모델로 변환하는 단계다.

쉽게 말해 ER 다이어그램의 엔티티들이 실제 테이블 스키마로 변환되는 과정이다.

이 과정에서 중요한 변환 규칙들이 있다.

• 엔티티 → 테이블
• 속성 → 컬럼
• 관계 → 외래키(FK) 또는 연결 테이블

학생-강의 관계를 예로 들면, 학생 테이블과 강의 테이블이 각각 만들어지고, 학생과 강의는 다대다(N:M) 관계이므로 수강신청 테이블이 별도로 만들어진다.

학생 테이블	강의 테이블	수강신청 테이블
학번 (PK)	강의코드 (PK)	학번 (FK)
이름	강의명	강의코드 (FK)
학과	담당교수	수강연도
		학기

이 단계에서 정규화(Normalization)도 진행된다. 중복 데이터를 없애고, 데이터 이상(Anomaly)이 발생하지 않도록 테이블을 적절히 분리하는 과정이다. (정규화에 대한 자세한 내용은 다음에 따로 다뤄볼 예정이다.)

---

4. 물리적 설계

논리적 설계가 "무엇을 저장할 것인가"라면, 물리적 설계는 "어떻게 저장할 것인가"다.

실제 DBMS에서 동작하도록 구체적인 저장 방식과 성능을 고려하는 단계이다.

물리적 설계에서 결정하는 것들은 다음과 같다.

• 데이터 타입: 이름을 VARCHAR(50)으로 할지, 학번을 INT로 할지 CHAR(6)으로 할지
• 인덱스(Index): 자주 조회되는 컬럼에 인덱스를 걸어 검색 속도를 높임
• 파티셔닝: 데이터가 너무 많으면 테이블을 물리적으로 분리하여 성능을 최적화
• 저장 공간 계산: 테이블의 예상 데이터 크기와 디스크 사용량 산정

이 단계부터는 MySQL, PostgreSQL, Oracle 같은 특정 DBMS에 맞게 설계가 달라진다.

예를 들어 학번 컬럼 하나를 설계하더라도

-- MySQL 기준
student_id INT NOT NULL AUTO_INCREMENT,

-- Oracle 기준
student_id NUMBER(6) NOT NULL,

이렇게 DBMS마다 문법과 타입이 다르다.

---

5. 구현

마지막 단계다. 물리적 설계를 바탕으로 실제 SQL로 테이블을 만들면 된다.

CREATE TABLE student (
    student_id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(50) NOT NULL,
    department VARCHAR(50),
    phone VARCHAR(20),
    PRIMARY KEY (student_id)
);

CREATE TABLE course (
    course_id CHAR(8) NOT NULL,
    course_name VARCHAR(100) NOT NULL,
    professor VARCHAR(50),
    PRIMARY KEY (course_id)
);

CREATE TABLE enrollment (
    student_id INT NOT NULL,
    course_id CHAR(8) NOT NULL,
    year INT,
    semester TINYINT,
    PRIMARY KEY (student_id, course_id, year, semester),
    FOREIGN KEY (student_id) REFERENCES student(student_id),
    FOREIGN KEY (course_id) REFERENCES course(course_id)
);

코드로 보면 간단해 보이지만, 앞에서 거쳐온 요구사항 분석 → 개념적 설계 → 논리적 설계 → 물리적 설계 단계가 제대로 이루어져야 이 SQL도 의미가 있다.

---

마무리

전체 설계 과정을 한 줄로 정리하면 이렇다.

단계	핵심 질문	결과물
요구사항 분석	무엇이 필요한가?	요구사항 명세서
개념적 설계	어떤 개념들이 있고 어떻게 연결되는가?	ER 다이어그램
논리적 설계	테이블로 어떻게 표현할 것인가?	테이블 스키마
물리적 설계	어떻게 저장하고 최적화할 것인가?	물리적 스키마 및 인덱스 설계
구현	SQL로 어떻게 만드는가?	실제 DDL 쿼리

처음 DB 설계를 할 때는 이 과정이 번거롭게 느껴질 수 있다. 사실 작은 프로젝트는 ER 다이어그램까지 그릴 필요는 없겠지만, 어느 정도 규모가 있는 시스템이라면 초반에 설계에 시간을 투자하는 게 나중에 훨씬 편하다.

다음에는 논리적 설계 단계에서 언급했던 정규화에 대해 알아보겠다.