개념적 모델링 (2) - 엔티티 관계와 ERD 실습

 
 

강한 엔티티와 약한 엔티티

강한 엔티티 (Strong Entity)

• 독립적인 존재가 가능하다.
• 자신만의 고유한 주식별자를 가진다.
• 다른 엔티티의 존재에 의존하지 않는다.
• 예시: 사원, 고객, 상품, 부서 등과 같이 독립적으로 관리되는 엔티티

약한 엔티티 (Weak Entity)

• 소유 엔티티가 있어야만 자신의 존재가 의미를 가진다.
• 소유 엔티티의 주식별자를 빌려와 자신의 속성과 결합하여 복합키를 구성한다.
• 예시: 부양가족

실무 이야기: 식별 관계, 비식별 관계
전통적인 설계 방식에서 약한 엔티티는 소유 엔티티의 주식별자를 빌려와 자신의 속성(부분키)과 결합해서 복합 키를 만드는 방식을 사용한다.
이것을 논리적 모델링 단계에서 식별 관계라 하며 이렇게 되면 자식을 만들 때 반드시 부모의 PK 값을 입력해야 한다.
최근에는 더 유연하고 실용적인 비식별 관계라는 방법을 주로 사용한다.

 

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

엔티티 간의 관계가 단순한 연결선을 넘어 그 자체가 하나의 독립된 의미를 갖는 개념이 있다.
사건(Event)이나 분류(Classification)와 같은 복잡한 관계를 효과적으로 모델에 반영하기 위해 특수 엔티티를 사용한다.

연관 엔티티 (Associative Entity)

• 두 개 이상의 엔티티 간에 발생하는 특정 사건, 행위, 계약 등을 표현하기 위해 도출되는 엔티티다.
• 두 개 이상의 다른 엔티티 간에 존재하는 다대다(M:N) 관계를 해소한다.
• 중간 엔티티를 통해 하나의 다대다 관계를 일대다(1:N), 다대일(N:1) 관계로 변환한다.

슈퍼타입/서브타입 엔티티 (Supertype/Subtype Entity)

• 논리적으로 동일한 개념 그룹에 속하지만 일부 속성이나 관계에서 차이가 있는 엔티티들을 효과적으로 표현하기 위한 기법이다.
• 객체지향 프로그래밍의 상속(Inheritance) 개념과 매우 유사하다.

슈퍼타입 (Supertype)

• 그룹 내 모든 엔티티(서브타입)들이 공통적으로 가지는 속성과 관계를 정의하는 상위 엔티티다.

서브타입 (Subtype)

• 슈퍼타입으로부터 공통 속성을 상속받고, 자신만의 고유한 속성이나 관계를 추가로 가지는 하위 엔티티다.

카디널리티와 참여도

카디널리티 (Cardinality)

카디널리티는 엔티티 인스턴스(행) 하나가 다른 엔티티의 인스턴스와 맺을 수 있는 최대 숫자를 기준으로 표기한다.
카디널리티 관계의 4가지 종류

• 일대일(1:1)
• 일대다(1:N)
• 다대일(N:1)
• 다대다(M:N)

참여도 (Optionality)

참여도는 한 엔티티의 인스턴스가 관계에 반드시 참여해야 하는지(필수), 아니면 참여하지 않을 수도 있는지(선택)를 결정한다.
예를 들어 회원과 주문의 관계를 보면 다음과 같다.

• 회원 → 주문 관계는 선택(Optional): 회원이 주문을 하지 않을 수도 있다.
• 주문 → 회원 관계는 필수(Mandatory): 주문은 반드시 회원과 연결되어야 한다.

관계의 표현과 외래 키

• 개념적 모델링 단계에서는 엔티티 간의 관계를 관계선(Relationship)으로 표현한다.
• 외래 키 같은 특정 기술의 구현적 요소는 포함하지 않는 것이 원칙이다.
• 실무에서는 개념적 모델링과 논리적 모델링을 따로 구분하지 않고 함께 진행하는 경우가 많다.

ERD (Entity-Relationship Diagram)

ERD는 복잡한 데이터 구조를 시각적으로 표현해서 개발자, 기획자 등 모든 관계자가
시스템의 청사진을 한눈에 파악하고 소통할 수 있게 도와주는 설계 도구다.

피터 첸 표기법

피터 첸 표기법 예시

• 실무에서 사용하지는 않는다.
• 엔티티는 사각형, 관계는 마름모, 속성은 타원으로 표현하는 전통적인 방식이다.

까마귀발(Crow's Foot) 표기법

까마귀발 표기법 예시

• 현재 실무에서 가장 널리 사용되는 사실상의 표준이다.
• 선의 양 끝에 기호를 붙여 카디널리티와 참여도를 동시에 표현한다.

연관 엔티티 - 다대다 관계 해결

M:N 관계는 물리적으로 구현이 불가능하다.
이를 해결하는 방법은 연관 엔티티(Associative Entity) 를 사용하는 것이다.
두 엔티티의 관계를 나타내는 새로운 엔티티를 만들어 기존의 M:N 관계를 두 개의 1:N, N:1 관계로 풀어내는 방식이다.
연관 엔티티는 논리/물리적 모델링 단계에서는 연결 테이블(Link Table), 조인 테이블(Join Table), 매핑 테이블(Mapping Table) 등으로 불린다.
다대다 관계를 해소하고 관계에 대한 추가 데이터를 저장하기 위해 두 개 이상의 테이블을 연결하는 중간 테이블을 의미한다.

실무 이야기: 연관 엔티티 추천 이름 및 특징
1. 연결 강조
- 주문 상품(order_product):
'주문'과 '상품' 테이블을 직접적으로 연결한다는 관계를 이름에 명시적으로 보여준다.
매우 직관적이고 단순하여 관계를 파악하기 쉽다는 장점이 있다.
2. 의미 있는 이름
- 주문 항목(order_item):
'주문'에 포함된 '항목'이라는 의미를 가장 명확하게 전달한다.
실제 쇼핑몰 비즈니스 로직(예: 장바구니 항목, 주문 항목)과 용어가 일치하여 이해하기 쉽다.
- 주문 상세(order_detail):
'주문의 상세 내역'이라는 의미로, order_item과 거의 동일한 의미로 널리 사용된다.
주문에 속한 각 상품 정보를 상세히 나타낸다는 점을 강조한다.

 

용어 사전

용어 사전은 프로젝트에 참여하는 모든 구성원의 공통 언어(Ubiquitous Language)를 만드는 핵심적인 과정이다.

용어 사전 작성 원칙

• 용어를 역할별로 분류하고, 약어와 전체 영문명을 명확히 구분하며, 실제 시스템에서 어떻게 사용되는지 구체적인 예시를 함께 기록한다.
• 단일어(Single Word) 중심으로 용어를 사용한다.
  • 가장 작은 단위의 단일어를 중심으로 사전을 구성한다.
  • 회원id = member + id = member_id
  • 상품 가격 = product + price = product_price
• 잘 정의된 단일어 사전은 무한한 용어를 일관되게 만들어내는 강력한 기반이 된다.
• 축약어는 반드시 용어사전에 등록하고 모두의 동의하에 사용한다.
• 프로젝트가 진행되면서 새로운 용어가 추가되고 새로운 비즈니스 용어가 생겨날 때마다 지속적으로 업데이트되어야 한다.

전체를 보는 개발자의 접근법

훌륭한 개발자는 단순히 주어진 기능을 '어떻게' 구현할지에만 집중하지 않는다.
그보다 먼저 이 기능을 '왜' 만들어야 하는지 질문해야 한다.
단순히 기술 구현에만 매몰되는 것이 아니라 비즈니스의 성공이라는 더 큰 그림을 보는 것을 지향해야 한다.

실전 개념적 모델링

1단계: 핵심 요구사항 다시 정의하기 (MVP)

• MVP(Minimum Viable Product, 최소 기능 제품)를 정의하는 과정이다.
• 시장에서 살아남기 위해 필요한 최소한의 기능을 정의하는 것이다.

2단계: 핵심 엔티티 도출

• 단순해진 요구사항에서 데이터의 뼈대, 엔티티를 찾아내는 단계다.
• 예시: 회원, 상품, 주문, 결제, 배송

3단계: 속성 정의 및 관계 설정

• 각 엔티티의 세부 정보(속성)를 정의하고 엔티티 간의 관계를 설정하는 단계다.
• 예시: product 테이블의 속성 - id, product_name, price, stock 등

4단계: M:N 관계 해소와 '연관 엔티티'

• 두 엔티티의 관계 속에서만 의미를 가지는 속성이 있는가를 판단한다.

주문과 주문 항목의 관계 (1:N)

• 하나의 주문은 여러 개의 주문 항목을 가질 수 있다.
• 하나의 주문 항목은 반드시 하나의 주문에 속한다.

상품과 주문 항목의 관계 (1:N)

• 하나의 상품은 여러 주문 항목에 포함될 수 있다.
• 하나의 주문 항목은 반드시 하나의 상품을 가진다.