데이터베이스는 설계는 어떻게 할까?

서비스를 개발할 때 데이터는 체계적으로 관리해야 한다. 필요할 때마다 엑셀에 열을 추가하는 방식으로는 명백한 한계가 존재한다.

초기에는 이런 방식이 편리할 수 있지만, 데이터가 축적되면서 중복이 발생하고 수정이 어려워지는 문제를 마주하게 된다. 이 문제를 해결하기 위해 '데이터베이스 설계'라는 체계적인 과정이 필요하다.

그렇기에 이번에는 데이터베이스 수업을 들으면서 알게된 데이터베이스 설계 5단계에 대해 블로그를 쓰면서 학습하려고 한다.

1. 요구사항 분석: 뭘 만들어야 할지 정하는 단계
2. 개념적 설계: DBMS에 독립된 데이터의 전체적인 뼈대를 그리는 단계
3. 논리적 설계: 특정 DBMS에 맞게 설계도를 구체화하는 단계
4. 물리적 설계: 데이터를 디스크에 어떻게 저장할지 정하는 단계
5. 구현: 설계도를 바탕으로 실제 DB를 만드는 단계

1단계: 요구사항 분석

이 단계의 목표는 개발할 데이터베이스의 목적과 범위를 명확하게 이해하는 것이다. 어떤 데이터가 필요하고, 어떻게 사용될지, 어떤 기능을 지원해야 하는지 파악해야 한다.

• 주요 활동:
  • 이 시스템을 사용할 사용자가 누구인지 식별
  • 사용자가 어떤 업무를 보는지 분석
  • 인터뷰나 설문조사로 요구사항 수집
  • 수집된 내용을 바탕으로 명세서 작성
• 산출물: 요구사항 명세서 (Requirements Specification Document)

이 명세서는 앞으로 진행될 모든 설계의 기준이 되며 요구사항에 대한 예시는 다음과 같다.

• 요구사항 예시 (Requirement Example):
  1. 마트 회원(Memeber)으로 등록하려면 MemberID, Password, Name, Age, Job을 입력한다.
  2. 회원에게는 MembershipLevel과 RewardPoints가 부여된다.
  3. 회원은 MemberID로 식별한다.
  4. 회원은 여러 상품(Product)을 주문할(order) 수 있고, 상품은 여러 회원에게 주문될(ordered) 수 있다.
  5. 회원이 주문을 하면, 시스템은 OrderNumber, Quantity, ShippingAddress, OrderDate를 저장해야한다.

2단계: 개념적 설계 (E-R 모델링)

요구사항 분석이 끝나면, 데이터의 전체적인 뼈대를 설계할 차례다.

이 단계의 핵심은 특정 DBMS(MySQL, Oracle 등)에 종속되지 않는, 추상적인 수준에서 데이터의 구조와 개체들 간의 관계를 파악하는 것이다. 여기서 가장 많이 사용하는 도구는 바로 E-R(Entity-Relationship) 모델이다.

 

STEP 1: 개체(Entity)와 속성(Attribute) 추출하기

이제 위 요구사항 예시에서 '명사' 들을 중심으로, 저장할 가치가 있는 데이터의 단위인 ‘Entity’와 그 개체가 갖는 특성인 '속성'을 추출한다.

요구사항 1, 2, 3번을 통해 회원(Member) 개체와 그 속성을 식별할 수 있다.

• 개체 (Entity): 회원(Member)
• 속성 (Attributes): MemberID, Password, Name, Age, Job, MembershipLevel, RewardPoints
• 기본키 (Primary Key): MemberID

요구사항 4, 5번에서는 상품(Product)이라는 Entity를 확인할 수 있다.

 

STEP 2: 개체 간의 관계(Relationship) 추출하기

다음으로 명세서의 '동사' 를 통해 개체들 간의 관계를 정의한다. 요구사항 4번("회원은 여러 상품을 주문할 수 있고, 상품은 여러 회원에게 주문될 수 있다.")에서 회원과 상품 사이의 관계를 파악할 수 있다.

• 관계(Relationship): 주문(Order)
• 관련 Entity: 회원(Member), 상품(Product) 대응 수(Mapping Cardinality): N:M (다대다)

또한, 요구사항 5번을 통해 이 '주문'이라는 관계 자체가 가지는 속성들을 알 수 있다.

• 관계의 속성: OrderNumber, Quantity, ShippingAddress, OrderDate

 

STEP 3: E-R 다이어그램 작성

위에서 추출한 개체, 속성, 관계를 표준화된 기호를 사용하여 시각화한다. 이렇게 만들어진 그림이 바로 E-R 다이어그램(ERD)이다.

E-R 다이어그램

3단계: 논리적 설계 (데이터 모델링)

개념적 설계에서 작성한 E-R 다이어그램을 실제 DBMS가 이해할 수 있는 기술적인 구조(주로 테이블)로 변환하는 과정이다.

규칙 1: 모든 개체는 릴레이션(테이블)으로 변환 E-R 다이어그램의 각 개체는 하나의 테이블이 된다. 개체의 속성은 테이블의 컬럼이 되고, 개체의 기본키는 테이블의 기본키가 된다.

• 회원 Entity → Members 테이블
• 상품 Entity → Product 테이블

규칙 2: 다대다(N:M) 관계는 별도의 릴레이션으로 변환 N:M 관계는 그 자체로 하나의 새로운 테이블이 된다. 이 테이블은 관계에 참여하는 두 개체의 기본키를 각각 외래키(Foreign Key)로 가지며, 이 두 외래키의 조합이 새 테이블의 기본키가 된다.

• 주문(Order) 관계 → Orders 테이블

규칙 3: 일대다(1:N) 관계는 N측 릴레이션에 외래키 추가 '1'에 해당하는 개체의 기본키를 'N'에 해당하는 개체의 테이블에 외래키로 추가하여 관계를 표현한다.

규칙 4: 일대일(1:1) 관계는 한쪽에 외래키 추가 어느 한쪽 테이블에 상대방 테이블의 기본키를 외래키로 추가한다.

규칙 5: 다중값 속성은 별도의 릴레이션으로 변환 한 속성이 여러 값을 가질 수 있다면(e.g. 한 사람의 취미가 여러 개인 경우), 그 속성을 위한 별도 테이블을 만든다.

논리적 설계 예시

4단계: 물리적 설계

논리적 스키마를 기반으로, 데이터베이스를 실제 저장 장치에 어떻게 저장할지 결정한다. 이 단계는 성능 최적화와 직결된다.

• 인덱스 구조 설계
• 저장 형식 결정
• 접근 경로 설계

5단계: 구현

마지막 구현 단계이다. 설계된 내용을 바탕으로 CREATE TABLE과 같은 SQL DDL(데이터 정의어)을 사용해 실제 데이터베이스와 그 안의 객체들을 생성한다.

CREATE TABLE Member (
    MemberID INT PRIMARY KEY,
    ...
    RewardPoints INT DEFAULT 0
);

CREATE TABLE Product (
    ProductID INT PRIMARY KEY,
    ...
    Price DECIMAL INT DEFAULT 0
);

CREATE TABLE Orders (
    OrderNumber INT PRIMARY KEY,
    MemberID INT,
    ProductID INT,
    ...
    OrderDate DATE,
    FOREIGN KEY (MemberID) REFERENCES Member(MemberID),
    FOREIGN KEY (ProductID) REFERENCES Product(ProductID)
);