2장. 개념적 모델링

개념적 모델링은 개발자, 기획자, 현업 담당자 등 모두가 함께 모여 "우리가 만들려는 서비스는 이런 모습이다"라고 합의하는 과정이다.

기술적인 용어 대신, 모두가 이해할 수 있는 그림과 용어로 소통하며 생각의 차이를 줄이고, 우리가 만들어야 할 것의 본질을 명확히 하는 중요한 단계이다.

요구사항 분석과 핵심 요소 식별

모든 설계는 요구 사항 분석에서 시작한다.

요구 사항 속에 우리가 만들어야 할 데이터 세상의 모든 뼈대가 숨어있다. 아주 효과적인 방법은 바로 명사와 동사에 집중하는 것이다.

• 명사 : 우리가 관리해야할 데이터의 대상. 즉 엔티티(Entity)또는 그 엔티티가 가지는 속성(Attribute)이 될 확률이 높다.
• 동사 : 데이터들 사이의 행위나 관계, 즉 관계(Relationship)가 될 확률이 높다.

핵심 데이터 덩어리, 엔티티(Entity) 도출하기

엔티티는 저장할 가치가 있는 중요 데이터를 가지고 있으면서, 다른 것과 명확히 구별되는 대상이다.
엔티를 찾는 쉬운 방법은 먼저 명사에서 시작하는 것이다.

엔티티 간의 연결고리, 관계(Relationship) 파악하기

이번에는 동사를 살펴보며 엔티티들이 서로 어떻게 연결되는지, 즉 관계(Relationship)를 찾아보자.

• 회원은 상품을 주문한다.
  • 회원과 주문 사이에 관계가 있다. (누가 주문했는가?)
  • 주문과 상품 사이에 관계가 있댜. (무엇을 주문했는가?)

엔티티란?

"우리가 데이터를 저장하고 관리해야할 대상"

조금 더 구체적으로는 '저장할 만한 가치가 있는 정보를 여러 개 가지고 있으면서, 다른 것과 명확히 구분되는 유무형의 모든 것'을 말한다.

엔티티는 우리가 만들 데이터베이스의 가장 핵심적인 뼈대(테이블)이 된다.
좋은 엔티티는 다음과 같은 특징을 가진다.

• 1. 업무 관련성(Business Relevance)
  • 엔티티는 반드시 해당 업무에 필요하고 관리해야 하는 정보여야 하며, 업무 프로세스에 의해 이용되어야 한다.
• 2. 식별 가능해야 한다(Uniquely Identifiable)
  • 엔티티에 속하는 각각의 데이터는 서로 명확하게 구분될 수 있어야 한다.
    • 만약 '회원' 엔티티에 회원명이 똑같은 사람이 두명 있을 수 있다.
    • 각 회원에게 고유한 '회원번호'나 '아이디'를 부여해서 구분할 수 있을 것이다.
    • 이 것이 나중에 '식별자' 또는 '기본 키'가 된다.
• 3. 두 개 이상의 정보를 가진다(Has Attributes)
  • 관리할 만한 가치가 있는 여러 정보, 즉 속성(Attribute)들을 가진다.
• 4. 인스턴스(Instance)의 집합이다
  • 엔티티는 영속적으로 존재하는 두 개 이상의 인스턴스로 구성된 집합이어야 한다.
  • 참고: 엔티티 (틀, 클래스), 인스턴스 (실제 데이터)
• 5. 다른 엔티티와 관계를 맺는다(Has Relationship)
  • 다른 엔티티와 서로 관계를 맺는다.
  • 회원은 주문을 하고, 주문은 여러 상품을 포함하는 것처럼 말이다.

엔티티와 속성의 분류

"이게 엔티티인가? 속성인가?" 헷갈릴 떄는 이렇게 생각해보자.
"이것이 우리 비즈니스에서 독립적으로 관리되어야 할 정보 덩어리인가?"
예를 들어, '회원 주소'는 독립적인 정보 덩어리가 아니라 '회원'이라는 더 큰 정보 덩어리에 속한 일부다. 따라서 '주소'는 속성이다.

엔티티 분류

'회원' 데이터와 '주문' 데이터는 성격이 다르다. '회원' 데이터는 한 번 가입하면 잘 변하지 않고 꾸준히 유지되지만, '주문' 데이터는 매 순간 새롭게 쌓이는 데이터이다.

결과적으로 시간이 지남에 따라 주문 데이터가 폭발적으로 증가할 것을 쉽게 예측할 수 있다.

이처럼 엔티티의 성격과 역할을 파악하고 구분하는 과정이 엔티티 분류이다.
이 분류 과정을 통해 앞으로 만들 테이블의 구조, 키 설계, 관계 설정, 성능 최적화 전략까지 설계의 큰 그림을 그릴 수 있을 것이다.

존재 형태에 따른 분류 : 유형, 개념, 사건 엔티티

• 유형 엔티티
  • 물리적인 형태를 가지고 있는 실체를 표현하는 엔티티
  • 특징: 업무적으로 식별이 용이하다
  • 예시: 회원, 상품
• 개념 엔티티
  • 물리적인 형태는 없지만, 업무적으로 관리해야 할 중요한 개념이나 아이디어를 표현하는 엔티티
  • 특징:
    • 추상적인 개념이다.
    • 업뮤 규칙이나 제도, 분류 기준등을 표현할 수 있다.
  • 예시: 계좌, 배송지
• 사건 엔티티(이벤트 엔티티)
  • 업무 프로세스가 진행됨에 따라 발생하는 특정 행위나 사건을 표현하는 엔티티
  • 특정 시점에 발생하며, 비즈니스 활동의 결과를 기록하는 역할을 한다.
  • 시간이 지남에 따라 데이터가 지속적으로 누적되는 특징을 가진다.
  • 예시: 주문, 결제, 매출

위 분류가 어떤식으로 도움이될까?

• 사건 엔티티는 시간이 지남에 따라 데이터가 폭발적으로 증가할 것을 쉽게 예측할 수 있다.
• 이렇게 데이터의 성격과 증가 추이를 미리 파악하면, 주문 같은 테이블을 설꼐할 떄부터 다음과 같은 전략을 세울 수 있다.
  • 인덱스 전략
  • 데이터 파티셔닝 및 아카이빙

역할 및 발생 시점에 따른 분류 : 기본, 중심, 행위 엔티티

• 기본 엔티티
  • 다른 엔티티에 의해 생성되지 않고 독립적으로 존재할 수 있는 핵심 엔티티
  • 키 엔티티라고도 불린다.
  • 특징:
    • 독립적으로 생성 가능하다.
    • 주로 다른 엔티티의 부모 역할을 한다.
    • 자신만의 고유한 주식별자를 가진다.
  • 예시: 회원, 상품, 사원, 부서, 고객
• 중심 엔티티
  • 기본 엔티티로부터 파생되어 생성되며, 해당 업무에서 중심적인 역할을 수행하는 엔티티다.
  • 독립적으로 존재하기보다 기본 엔티티 간의 관꼐에서 발생하는 핵심적인 비즈니스 트랜잭션을 나타내는 경우가 많다.
  • 특징:
    • 기본 엔티티로부터 발생한다
    • 업무 프로세스의 중심적인 역할을 담당한다.
    • 데이터 발생량이 많고, 많은 행위 엔티티들을 파생시킨다.
  • 예시: 주문, 매출
• 행위 엔티티(Action/Behaviroal Entity)
  • 두 개 이상의 부모 엔티티로부터 발생하며, 업무가 흘러가면서 생성되는 상세 정보를 기록하는 엔티티다.
  • 특징:
    • 두 개 이상의 부모 엔티티로부터 발생한다.
    • 데이터 내용이 자주 변경되거나 데이터양이 빠르게 증가한다.
  • 예시:
    • 주문 이력, 신청 변경 이력, 결제 내역, 로그, 주문 항목

위 분류가 어떤식으로 도움이될까?

• 체계적인 개발 순서와 일정 관리
• 성능과 데이터 관리 전략 수립의 기준
  • 기본 엔티티 :
    • 데이터 변경이 잦지 않고, 주로 조회 작업이 많다
  • 중심 엔티티 :
    • 조회의 중심축이자 트랜잭션의 핵심
    • 데이터는 꾸준히 증가하며, 조회뿐만 아니라 상태 변경도 빈번하게 일어남.
    • 각각의 쓰임새에 맞는 인덱스를 생성하는 것이 성능 유지의 관건이다.
  • 행위 엔티티
    • 하나의 주문을 할 떄 결제 방식만큼 행이 만들어진다.
    • 따라서 데이터가 폭발적으로 증가하며, 가장 많은 저장 공간을 차지하게될 테이블이다.
    • 따라서 설계 초기부터 데이터 파티셔닝이나 주기적인 아카이빙 전략을 고민해야 한다.

실무 이야기: 분류 용어를 외우기보다 본질을 이해하는 것

• 이 분류법은 데이터베이스를 설꼐하는 사고의 틀을 제공한다.
• 각 테이블이 가지는 데이터의 본질과 성격을 빠르고 정확하게 간파하는 훈련을 하는 것이다.

엔티티 분류 2

강한 엔티티와 약한 엔티티

• 강한 엔티티
  • 다른 엔티티의 존재 여부와 관계없이 독립적으로 존재할 수 있는 엔티티를 의미한다.
  • 특징:
    • 독립적인 존재가 가능하다.
    • 자신만의 고유한 주식별자를 가진다.
    • 다른 엔티티의 존재에 의존하지 않는다.
  • 예시: 사원, 고객, 상품
• 약한 엔티티
  • 다른 엔티티가 존재하지 않으면 독립적으로 존재할 수 없는 종속적인 엔티티다.
  • 특징:
    • 약한 엔티티는 소유 엔티티가 있어야만 자신의 존재가 의미를 가진다.
    • 식별자 구성: 소유 엔티티의 주식별자를 빌려와 자신의 속성(부분키)과 결합하여 주식별자로 삼는다.
  • 예시: 부양가족(부양가족 정보는 특정 사원에게 소속될 때만 의미가 있다)

실무 이야기 - 식별 관계, 비식별 관계

• 약한 엔티티는 소유 엔티티의 주식별자를 빌려와 자신의 속성과 결합해서 복합 기본키를 만드는 방식을 사용한다.
• 이것을 논리적 모델링 단계에서 식별 관계라 한다.
• 누가 봐도 관계를 명확하게 이해할 수 있고 데이터 무결성을 PK 레벨에서 보장한다.
• 하지만 이런 전통적인 방식은 최근에는 잘 사용하지 않고, 대신에 더 유연하고 실용적인 비식별 관계라는 방법을 주로 사용한다.

구조적 관계 표현을 위한 특수 엔티티

엔티티 간의 관계 그 자체가 하나의 독립된 의미를 갖는 개념일 때가 있다.
이러한 복잡한 관계를 효과적으로 모델에 반영하기 위해 사용하는 것이 바로 연관 엔티티와 슈퍼타입/서브타입구조이다.

• 연관 엔티티(Associative Entity)
  • 두 개 이상의 엔티티 간에 발생하는 특정 사건, 행위, 계약 등을 표현하기 위해 도출되는 엔티티다.
  • 관계(Relationship) 자체가 중요한 속성을 가져 하나의 독립된 엔티티로 다뤄져야 할 때 사용된다.
• 슈퍼타입 / 서브타입 엔티티
  • 논리적으로 동일한 개념 그룹에 속하지만 일부 속성이나 관계에서 차이가 있는 엔티티들을 효과적으로 표현하기 위한 기법이다.
  • 객체지향 프로그래밍에서 상속을 떠올리면 이해가 쉬울 것이다.

속성과 식별자

• 속성(Attribute)
  • 엔티티가 가지는 구체적인 특성이나 정보이다.
• 식별자(Identifier)
  • 각 데이터를 다른 데이터와 유일하게 구별해주는 이름표 역할을 한다.
  • 데이터베이스 테이블에서는 기본 키(Primary Key)가 된다.

카디널리티와 참여도

'회원'과 '주문' 사이에 관계가 생겼지만, "한 명의 회원이 여러 주문을 할 수 있는가?",
"주문 없이 회원만 존재할 수 있는가?" 와 같은 구체적인 규칙을 정립해야 한다.

위와 같이 관계의 규칙을 정의하는 데에 사용하는 두 가지 핵심요소가 있다.
바로 카디널리티와 참여도다.

• 카디널리티
  • 한 엔티티의 인스턴스(개별 데이터)와 다른 엔티티의 인스턴스와 몇 개나 관계를 맺을 수 있는지 나타내는 수량 제약이다.
  • 간단히 1:1, 1:N, N:1, M:N 관계를 따지는 것이다.
  • 일대일 (1:1)
    • 주문과 배송 관계
  • 일대다 (1:N)
    • 회원과 주문 관계
  • 다대다 (M:N)
    • 주문과 상품 관계
  • 카디널리티는 엔티티 인스턴스(행)가 다른 엔티티의 인스턴스와 맺을 수 있는 최대 숫자를 기준으로 표기한다.
    • 1(하나): 한 엔티티의 인스턴스가 다른 엔티티의 인스턴스와 최대 1개의 관계를 가질 떄 사용
    • N(하나 이상): 한 엔티티의 인스턴스가 다른 엔티티의 인스턴스와 1개 이상, 즉 여러 개의 관계를 가질 수 있을 떄 사용한다.
• 참여도(Optionality)
  • 한 엔티티의 인스턴스가 관계에 반드시 참여해야 하는지(필수), 아니면 참여하지 않을 수도 있는지(선택)을 결정한다.

관계의 표현과 외래 키

개념적 모델링 단계는 관계형 데이터베이스를 포함한 특정 기술에 종속되지 않는다.
쉽게 얘기하면 개념적 모델링의 결과로 RDBMS 뿐만 아니라 NoSQL 같은 곳에도 사용할 수 있다.

개념적 모델링 단꼐에서는 엔티티 간의 관계를 관계선으로 표현하며, 외래 키 같은 특정 기술의 구현적 요소는 포함하지 않는 것이 원칙이다.

ERD 완성하기

• 피터 첸(Peter Chan) 표기법
  • 엔티티는 사각형, 관계는 마름모, 속성은 타원으로 표현하는 전통적인 방식이다.
  • 속성까지 모두 표현되어 너무 복잡하다.
  • 실용성이 떨어져 현재는 사용하지 않는다.
• 까마귀발(Crow's Foot) 표기법
  • 현재 실무에서 가장 널리 사용되는 사실상의 표준이다.
  • 왜 실무에서는 위 방식을 사용할까?
    • 정보 밀도와 가독성: 적은 공간에 많은 정보를 깔끔하게 표현할 수 있다.
    • 직관적인 표현: 기호 자체가 관계의 수량(카디널리티)를 직관적으로 보여준다.
    • 대부분의 도구 지원: MySQL WorkBench, DBeaver, ERDCloud 등 대부분의 데이터베이스 모델링 도구가 지원한다.

까마기발 표기법의 핵심 기호

• 엔티티는 사각형 상자로 표현한다.
• 관계는 두 엔티티를 잇는 직선으로 표현한다.
• 선의 양 끝에 기호를 붙여 카디널리티와 참여도를 동시에 표현한다.
  • | : 1 (One)
  • < : 다 (Many, 까마귀발 모양)
  • 0 : 0 (Zero)

까마기발 표기법을 읽을 떄 가장 중요한 원칙은 한 엔티티 쪽 끝에 있는 기호는 반대편 엔티티에 대한 규칙을 설명한다는 것이다.

연관 엔티티 - 다대다 관계 해결 (M:N 관계의 두 가지 문제점과 해결책)

문제 1 - M:N 관계는 물리적으로 구현할 수 없다.

RDBMS는 테이블이라는 2차원 표 형태를 사용하며, 관계는 한 테이블의 기본 키를 다른 테이블의 외래 키로 포함시켜 표현한다.

• 한 주문 행(레코드)에 여러 상품을 담을 수 없음
  • 한 주문 행에 여러 컬럼을 만들어 상품을 담기 (X)
  • 한 주문 행에 상품 ids 라는 컬럼을 만들어 List로 담기 (X)
    • 하지 말자.
      • 데이터 검색이 어려워진다
      • 데이터 수정 및 삭제가 복잡해진다
      • 원자성을 위반한다: 테이블의 모든 컬럼은 원자적인 값 하나만 가져야 한다.

문제 2 - 관계에 속한 데이터를 저장할 장소가 없다

• 주문한 상품의 가격을 저장하고 싶다면? (상품의 가격은 달라 질 수 있다)

• 주문한 상품의 수량을 저장하고 싶다면?

• 이 처럼 주문 수량과 주문 당시 가격은 주문이나 상품에 속한 속성이 아니다.

• 이들은 주문과 상품이 관계를 맺음으로써 발생하는 속성이다.

• 데이터를 관리하는 역할은 바로 엔티티의 몫이다

해결책 - 관계를 엔티티로 승격하자.

해결하는 방법은 M:N 관계를 연관 엔티티로 바꾸는 것이다.

• M:N 관계를 두 개의 1:N 관계로 분해하여 문제 1을 해결한다.
• 새로운 엔티티에 관계 속성을 저장하여 문제 2를 해결한다.

연관 엔티티의 다양한 용어

개념적 모델링 단계의 연관 엔티티는 논리/물리적 모델링 단계에서는 다양한 이름으로 불린다.

• 연결 테이블 (Link Table)
• 조인 테이블 (Join Table)
• 매핑 테이블 (Mapping Table)

다대다 관계를 해소하고 관계에 대한 추가 데이터를 저장하기 위해 두 개 이상의 테이블을 연결하는 중간 테이블이라는 의미만 잘 기억하자.

용어 사전

프로젝트의 모든 이해 관계자들은 같은 비즈니스 용어를 사용하는 것이 중요하다.
이 때 용어 사전을 만들어 관리해두면 유용하다.

이렇게 잘 정리된 용어 사전은 단순한 명명 규칙을 넘어, 시스템의 구조와 비즈니스 로직을 이해하는 좋은 가이드가 된다. 그리고 이렇게 만든 용어 사전은 앞으로 우리가 만들 모든 데이터베이스 객체와 애플리케이션 코드의 기준이 된다.

단일어 중심 (Single Word)

가장 작은 단위의 단일어를 중심으로 사전을 구성하는 것이 좋다.

• 회원: member
• 상품: product
• ID: id
• 가격: price

이제 우리는 이 단어들을 조립해서 일관된 용어를 만들어낼 수 있다.

• 회원id = member + id = member_id
• 상품 가격 = product + price = product_price

이 방식은 다른 변형을 원천적으로 차단하고, 시스템 전체의 예측 가능성을 극대화한다.