1장. 데이터베이스 설계의 중요성

Java나 Python 같은 애플리케이션 코드는 상대적으로 수정하기 쉽다. 최신 프레임워크와 아키텍처 패턴 덕분에 기능 개선이나 코드 리팩토링이 과거보다 훨씬 유연해졌다. 하지만 데이터베이스 스키마, 즉 테이블의 구조는 한번 잘못 만들어지면 바로잡는 데 엄청난 비용과 시간이 소요된다.

1. 잘못된 설계가 부르는 재앙

'나쁜 설계'가 실제로 어떤 재앙을 불러오는지 구체적인 사례를 통해 알아보자. 이제 막 시작한 스타트업 '쇼핑몰'이 있다고 가정하자. 빠르게 서비스를 출시하기 위해 고객과 주문 정보를 관리하기 위해 다음과 같이 orders 테이블 하나에서 모든 정보를 관리하고 있다.

orders 테이블 구조

• order_id : 주문 번호
• customer_id : 고객 아이디
• customer_name : 고객 이름
• customer_address : 고객 주소
• product_id : 상품 번호
• product_name : 상품 이름
• product_price : 상품 가격
• ordered_at : 주문 날짜

겉보기에는 문제가 없어보인다. 지금부터 이 설계가 어떤 문제를 안고있는지 하나씩 살펴보자.

2. 나쁜 설계의 3대 문재점

바로 데이터 무결성 훼손, 성능 저하, 그리고 유지 보수 비용 증가다.

• 1. 데이터 무결성 훼손(신뢰도 하락)

  • 데이터 중복:
    • 주문할 때마다 고객 정보가 반복해서 저장된다.
    • 수백만 건의 주문이 쌓인다면 어떨까? 엄청난 양의 데이터가 불필요하게 중복되어 저장 공간을 낭비하게 된다.
  • 수정 이상 (Update Anomaly):
    • 어느날 고객이 이사를 가서 주소를 변경해달라고 요청한다. 그런데 데이터 변경 중 누락이 발생했다면?
    • 이제 이 데이터는 더 이상 신뢰할 수 없는 상태가 된다.
    • 하나의 정보를 바꾸기 위해 여러 레코드를 수정해야하고, 그 과정에서 일부가 누락될 떄 데이터 불일치가 발생하는 현상이다.
  • 삽입 이상 (Insertion Anomaly):
    • 쇼핑몰이 사업을 확장해서, 아직 주문은 하지 않았찌만 마케팅 수신에 동의한 잠재 고객을 미리 등록하고 싶어졌다.
    • 이 고객은 아직 주문한 적이 없으므로 주문 관련 정보는 없다.
    • 이 테이블 구조에서는 주문을 하지 않으면 고객 정보를 등록할 수 없는 모순이 발생한다.
  • 삭제 이상 (Deletion Anomaly):
    • 시간이 흘러 고객이 탈퇴를 요청했다. 법적인 보관 기간이 지나 그의 주문 기록을 삭제해야하는 상황이다.
    • DELETE 쿼리로 주문정보를 삭제하면 해당 고객이 우리 쇼핑몰을 이용했다는 고객 정보 자체가 시스템에서 완전히 사라져 버린다
    • 이처럼 특정 정보를 삭제했을 뿐인데, 유지되어야 할 다른 중요한 정보까지 연쇄적으로 삭제되는 현상을 삭제 이상이라고 한다.

• 2. 성능 저하

  • 느려지는 조회 속도:
    • 고객의 주문 목록을 조회하는 간단한 쿼리를 생각해보자.
    • 이 쿼리는 매번 거대한 orders 테이블 전체를 뒤져야 한다. 고객 정보, 상품 정보, 주문 정보가 모두 한 테이블에 섞여 있으니 테이블이 '뚱뚱'해진다.
    • 디스크에서 읽어야 할 데이터 양이 많아지니 당연히 속도가 느려진다.

• 3. 유지보수 비용 증가(확장성 저하)

  • 작은 변경의 큰 파급효과:
    • 고객별 등급을 관리하고 싶다는 새로운 요구사항을 제시했다. 이 간단한 '등급' 정보를 추가하려면 어떻게 해야할까?
    • orders 테이블에 customer_grade라는 컬럼을 추가해야 한다.

3. 설계의 3단계 - 개념, 논리, 물리

• 1. 개념적 설계(Conceptual Design)
  • 목표 : 비즈니스의 아이디어나 요구 사항을 이해하고 밑그림을 그리는 단계.
  • 핵심 질문 : 우리가 다루어야 할 데이터는 무엇이며(Entity), 그 데이터들은 서로 어떤 관계(Relationship)을 맺고 있는가?
  • 산출물 :
    • ERD(Entity-Relationship Diagram) 사람의 눈으로 이해하기 쉬운 형태의 설계도
    • 고객은 주문을 할 수 있고, 주문에는 여러 개의 상품이 포함될 수 있다는 식의 관계를 그림으로 표현한다.
• 2. 논리적 설계(Logical Design)
  • 목표 : 개념적 설계에서 만든 밑그림을, RDBMS의 원리에 맞게 구체적인 구조로 다듬는 단계이다.
    • 특정 RDBMS에 종속되지 않는, 순수한 논리적인 데이터 구조를 만든다.
  • 핵심 질문 :
    • "개념 모델의 각 요소들을 어떤 테이블(Table) 구조로 표현할 것인가?"
    • "데이터의 중복을 막고 관계를 명확히 하기 위해 어떤 규칙(정규화)을 적용해야 하는가?"
  • 산출물 : 정규화된 테이블 스키마
    • 각 테이블이 어떤 컬럼들을 가질지, 기본키와 외래키는 무엇을로 할지 등을 명확하게 정의한다.
• 3. 물리적 설계(Physical Design)
  • 목표 : 논리적 설계에서 만든 테이블 스키마를, 실제 우리가 사용할 특정 RDBMS의 특성에 맞게 최적화 하여 구현하는 마지막 단계이다.
  • 핵심 질문:
    • "각 컬럼에 어떤 데이터 타입(VARCHAR, INT, DATETIME 등)을 할당해야 가장 효율적일까?"
    • "어떤 컬럼에 인덱스를 설정해야 조회 속도가 빨라질까?"
  • 산출물 : 물리적인 테이블 정의서, SQL 스크립트(CREATE TABLE ...)

용어 정리

개념, 논리, 물리 각각의 설계 모델에서 사용하는 용어

각 모델링 단계마다 용어가 다른 이유는 각 단계가 가진 고유한 목표와 바라보는 관점이 다르기 때문이다.

참고:
 
릴레이션(Relation)
 
릴레이션은 관계형 데이터 베이스의 이론적 모델에서 '테이블(Table)'을 부르는 공식적인 이름이다.
릴레이션은 데이터가 저장되는 2차원 테이블 그 자체로 수학적 집합 개념을 의뜻한다.
관계형 데이터베이스는 '릴레이션(테이블)의 집합으로 구성된 데이터베이스'를 의미하며, 이 릴레이션들을 이용해 데이터간의 관계(Relationship)를 표현하는 것이다.