개념적 모델링 (1) - 요구사항 분석과 엔티티의 이해

요구사항 분석에서 시작하는 설계

모든 설계는 요구사항 분석에서 시작한다.
요구사항 문서를 읽을 때는 특히 '명사'와 '동사'에 집중해야 한다.
이들이 바로 데이터베이스의 구조를 결정하는 핵심 요소이기 때문이다.

명사 (Nouns)

• 우리가 관리해야 할 데이터의 대상을 나타낸다.
• 엔티티(Entity) 또는 그 엔티티가 가지는 속성(Attribute)이 될 수 있다.
• 예시: 회원, 아이디, 비밀번호, 회원명, 주소, 연락처, 상품, 상품 코드, 상품명, 가격, 재고 수량, 주문서, 주문 번호, 배송지, 주문 일시, 결제 금액, 주문 내역, 주문 수량

동사 (Verbs)

• 데이터들 사이의 행위나 관계를 나타낸다.
• 관계(Relationship)가 될 수 있다.
• 예시: 가입하다, 수정하다, 탈퇴하다, 등록하다, 변경하다, 주문하다, 조회하다

엔티티(Entity)란 무엇인가

엔티티는 개념적 모델링의 가장 기본적인 구성 요소다. 엔티티가 제대로 정의되려면 다음 다섯 가지 특징을 만족해야 한다.

1. 업무 관련성 (Business Relevance)

반드시 해당 업무에 필요하고 관리해야 하는 정보여야 하며, 업무 프로세스에 의해 실제로 이용되어야 한다.

2. 식별 가능성 (Uniquely Identifiable)

각각의 데이터(인스턴스, 행)는 서로 명확하게 구분될 수 있어야 한다. 이를 위해 주로 Primary Key를 사용한다.

3. 두 개 이상의 속성 보유 (Has Attributes)

관리할 만한 가치가 있는 여러 정보, 즉 속성(Attribute)들을 가져야 한다.

4. 인스턴스의 집합

두 개 이상의 인스턴스(실제 데이터)로 구성된 집합이어야 한다. 예를 들어 회원1, 회원2와 같이 여러 개의 데이터가 존재해야 한다.

5. 관계 형성 (Has Relationships)

다른 엔티티와 관계를 맺어야 한다. 엔티티 간의 관계를 파악하는 것이 데이터베이스 설계의 핵심이다.

엔티티 분류의 의미와 목적

엔티티 분류는 데이터 덩어리의 성격과 역할을 제대로 파악하고 구분하는 과정이다. 이 작업이 중요한 이유는 다음과 같다.

분류 목적

1. 모델의 이해도와 커뮤니케이션 비용 감소 엔티티의 성격을 명확히 분류하면 팀원들과의 소통이 원활해진다.

2. 체계적인 개발 순서와 일정 관리 엔티티 분류는 기본 → 중심 → 행위 순서 그대로 개발의 우선순위가 된다.

3. 성능과 데이터 관리 전략 수립의 기준 엔티티의 특성은 곧 데이터의 특성을 의미한다.

• 기본 엔티티: 데이터 변경이 잦지 않고 주로 조회(READ) 작업이 많다. 따라서 조회 성능에 최적화된 인덱싱 전략이 중요하다.
• 중심 엔티티: 조회의 중심축이자 트랜잭션의 핵심이다. 조회(SELECT)뿐만 아니라 주문 상태 변경(UPDATE)도 빈번하게 발생하므로, 각각의 쓰임새에 맞는 인덱스를 생성하는 것이 성능 유지의 관건이다.
• 행위 엔티티: 데이터가 폭발적으로 증가하며 가장 많은 저장 공간을 차지한다. 설계 초기부터 데이터 파티셔닝이나 주기적인 아카이빙 전략을 고민하는 것이 좋다.

존재 형태에 따른 엔티티 분류

유형 엔티티

• 물리적 형태가 존재한다.
• 업무로부터 식별이 용이하다.
• 상대적으로 안정적이며 지속적으로 활용되는 정보를 담는다.
• 예시: 사원, 학생, 고객, 교수(사람), 상품, 자재, 물품, 차량, 건물(사물)

개념 엔티티

• 물리적 형태가 없는 추상적인 개념이다.
• 업무 규칙이나 제도, 분류 기준 등을 표현한다.
• 유형 엔티티와 마찬가지로 비교적 안정적인 정보를 관리한다.
• 예시: 부서, 조직, 팀(조직 구조), 계좌, 보험상품(금융 상품 및 장부)

사건 엔티티 (이벤트 엔티티)

• 업무 수행에 따라 발생하는 행위를 기록한다.
• 시간의 흐름에 따라 인스턴스가 계속해서 발생한다.
• 발생량이 많고 각종 통계 자료에 활용될 수 있다.
• 예시: 주문, 계약, 청구, 매출(판매 및 계약 관련 사건), 예약, 취소, 사고접수(서비스 관련 사건)

역할 및 발생 시점에 따른 엔티티 분류

기본 엔티티 (Fundamental/Key Entity)

• 독립적으로 생성이 가능하다.
• 주로 다른 엔티티의 부모 역할을 한다.
• 자신만의 고유한 주식별자를 가진다.
• 예시: 회원, 상품, 사원, 부서, 고객, 자재

중심 엔티티 (Main/Center Entity)

• 기본 엔티티로부터 발생한다.
• 업무 프로세스의 중심적인 역할을 담당한다.
• 데이터 발생량이 많고 많은 행위 엔티티를 파생시킨다.
• 예시: 주문, 계약, 청구, 매출

행위 엔티티 (Action/Behavioral Entity)

• 두 개 이상의 부모 엔티티로부터 발생한다.
• 데이터 내용이 자주 변경되거나 데이터양이 빠르게 증가한다.
• 상세 설계 단계에서 도출되는 경우가 많다.
• 예시: 주문 이력, 신청변경이력, 결제 내역, 로그, 주문 항목

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

이 분류법은 데이터베이스를 설계하는 '사고의 틀(Framework)'을 제공한다. 용어 자체를 암기해서 사용하는 것이 목적이 아니라, 각 테이블이 가지는 데이터의 '본질'과 '성격'을 빠르고 정확하게 간파하는 훈련을 하는 것이다. 엔티티 분류는 복잡한 요구사항 속에서 데이터의 구조와 성격을 보고 최적의 해결책을 찾아가는 과정에서 머릿속에 그려지는 '설계 지도'인 것이다!