89. 확장 ER 모델 (EER) - 서브클래스, 슈퍼클래스, 상속(일반화/특수화) 개념 추가

핵심 인사이트 (3줄 요약)

본질: 확장 ER 모델 (Enhanced Entity-Relationship Model, EER)은 기존 ER 모델에 객체지향의 상속(Inheritance) 개념인 슈퍼클래스와 서브클래스를 결합하여, 복잡한 데이터 계층 구조를 정밀하게 표현하는 진화된 데이터 스케치 도구다.

가치: 데이터를 '공통점'과 '차이점'으로 분리하여 모델링함으로써, 불필요한 빈칸(NULL) 속성 발생을 막고 공통 속성의 중복 설계를 제거하여 데이터베이스의 공간 효율성과 재사용성을 극대화한다.

판단 포인트: EER은 모든 개체를 무조건 세분화하는 것이 아니라, 서브클래스만이 가지는 '고유한 속성'이나 '고유한 관계'가 명확히 존재할 때만 분리(특수화)해야 시스템 복잡도를 통제할 수 있다.

Ⅰ. 개요 및 필요성

확장 ER 모델 (EER)은 기본 개체-관계(ER) 모델이 가진 표현의 한계를 극복하기 위해 등장한 개념이다. 전통적인 ER 모델은 모든 고객을 하나의 '고객' 개체로 뭉뚱그려 표현하거나, '개인고객'과 '법인고객'을 완전히 남남처럼 분리해서 중복 속성을 여러 번 그리게 만드는 딜레마를 안고 있었다.

데이터베이스 규모가 커지고 비즈니스 로직이 객체지향적으로 복잡해지면서, 개체들 사이의 '포함 관계(IS-A)'를 정확히 그려낼 방법이 필요해졌다. EER은 공통된 뼈대(슈퍼클래스)와 구체적인 자식(서브클래스)이라는 계층 구조를 도입하여, 개인고객은 주민번호를, 법인고객은 사업자번호를 각각 따로 가지면서도 이름과 연락처는 부모로부터 물려받아(상속) NULL 값 없이 깔끔하게 저장되도록 만든다.

📢 섹션 요약 비유: EER은 대형 마트의 진열대 분류표와 같다. '음료수(공통)'라는 큰 팻말 아래에 '탄산(차이점)'과 '주스(차이점)'를 나누어 두어야지, 모든 상품에 '탄산 유무' 스티커를 다 붙이거나 음료수라는 공통점 없이 제각각 흩어두면 관리자가 물건을 찾을 수 없다.

Ⅱ. 아키텍처 및 핵심 원리

EER의 핵심 원리는 공통점과 차이점을 위아래로 재배치하는 일반화(Generalization)와 특수화(Specialization) 메커니즘, 그리고 이들을 통제하는 상속 제약조건(Constraints)이다.

구성 요소	역할	방향 및 특징
특수화 (Specialization)	하나의 상위 개체를 속성 차이에 따라 하위 개체로 분할	Top-Down (직원 $\rightarrow$ 정규직, 계약직)
일반화 (Generalization)	여러 하위 개체의 공통 속성을 뽑아 상위 개체를 생성	Bottom-Up (승용차, 트럭 $\rightarrow$ 자동차)
슈퍼클래스 (Superclass)	공통 속성을 가진 부모 개체	자식에게 속성을 상속해 줌
서브클래스 (Subclass)	고유 속성을 추가로 가진 자식 개체	부모의 모든 속성을 100% 물려받음

서브클래스를 나눌 때는 두 가지 중요한 제약조건(규칙)이 작동한다. 첫째, 중복(Disjointness) 제약조건은 자식들끼리 겹칠 수 없는 배타적 분리(Disjoint, d)인지, 교집합이 가능한 중복 허용(Overlap, o)인지 결정한다. 둘째, 참여(Completeness) 제약조건은 부모가 반드시 자식 중 하나에 속해야 하는 전체 참여(Total, ===)인지, 어디에도 안 속하는 예외 부모가 존재하는 부분 참여(Partial, ─)인지를 규정한다.

┌──────────────────────────────────────────────────────────────┐
│           EER 상속 계층과 제약조건 (직원 모델링 예시)             │
├──────────────────────────────────────────────────────────────┤
│                     [ 직 원 (슈퍼클래스) ]                       │
│                     (사번, 이름, 입사일)                       │
│                              │                               │
│                              d (Disjoint: 배타적 분리)         │
│             ┌────────────────┴────────────────┐              │
│             ▼                                ▼              │
│    [ 정규직 (서브클래스) ]              [ 계약직 (서브클래스) ]    │
│        (연봉, 보너스)                      (시급, 계약기간)      │
│                                                              │
│ * 특징: 직원은 정규직이면서 계약직일 수 없음 (d).                  │
│        정규직은 부모의 '사번, 이름'을 그대로 물려받아 사용함.           │
└──────────────────────────────────────────────────────────────┘

이 다이어그램은 특수화의 과정을 보여준다. 하나의 직원이 두 서브클래스에 속할 수 없음을 명확히 하여, 시스템이 데이터 무결성을 유지하게 만든다.

📢 섹션 요약 비유: 부모의 붕어빵 틀(슈퍼클래스)을 그대로 복사해서, 하나는 슈크림(정규직 속성)을 넣고 다른 하나는 팥(계약직 속성)을 넣어 서로 다른 두 개의 붕어빵을 구워내는 과정이다.

Ⅲ. 비교 및 연결

EER을 명확히 이해하려면 전통적 ER 모델 및 객체지향 프로그래밍(OOP) 개념과 비교해야 한다.

항목	전통적 ER 모델	확장 ER 모델 (EER)
표현 한계	단일 개체에 모든 속성 집중 (NULL 발생)	슈퍼/서브클래스 계층으로 분리 (NULL 제거)
관계성	단순 연결 관계 (1:N, M:N)	상속 관계 (IS-A) 추가 지원
다형성 지원	불가능	카테고리(Category) 개념을 통한 다중 상속 지원

EER은 단순히 데이터베이스 설계의 영역을 넘어 소프트웨어 공학의 객체지향 분석/설계(OOAD)와 강하게 연결된다. EER의 슈퍼클래스/서브클래스는 자바(Java)의 부모 클래스와 상속(extends) 개념과 1:1로 매칭되며, 이는 결국 ORM (Object-Relational Mapping) 기술이 테이블과 객체를 부드럽게 이어주는 논리적 근거가 된다.

📢 섹션 요약 비유: 전통 ER 모델이 모든 사람의 인적 사항을 한 장의 거대한 엑셀 시트에 때려 적는 방식이라면, EER은 기본 이력서를 작성한 뒤 필요한 사람에게만 별도의 첨부 서류(서브클래스)를 스테이플러로 찍어주는(상속) 합리적 서류철이다.

Ⅳ. 실무 적용 및 기술사 판단

실무 프로젝트에서 데이터 모델러는 무조건 EER을 남발해서는 안 되며, 다음과 같은 판단 기준을 통해 EER 계층 분리의 득실을 계산해야 한다.

테이블 변환 시의 조인(Join) 비용 계산: EER로 그린 모델을 실제 RDBMS 테이블로 바꿀 때는 부모 테이블과 자식 테이블로 쪼개진다. 자식 데이터를 조회할 때마다 부모 테이블을 매번 조인해야 하므로, 트랜잭션 빈도가 엄청나게 높은 시스템에서는 성능 병목을 유발할 수 있다.
서브클래스의 고유성 검증: 서브클래스가 자신만의 고유한 속성이나, 다른 개체와의 고유한 관계를 가지지 않는다면 분리할 필요가 없다. 이 경우 차라리 부모 개체에 '구분자(Type)' 칼럼 하나를 추가하는 것이 낫다.
유연성 vs 복잡성: 도메인 요건이 자주 바뀌어 새로운 타입의 서브클래스가 계속 추가될 예정이라면 EER 기반의 설계가 확장성 측면에서 유리하다.

안티패턴: 속성이 단 한 개뿐인 서브클래스를 10개 이상 만들어버려, 전체 ERD가 알아볼 수 없을 만큼 복잡한 거미줄이 되는 설계.

📢 섹션 요약 비유: 서재를 정리할 때, 책이 수백 권이면 소설, 과학, 역사로 서랍을 나누는 게 맞지만, 책이 3권밖에 없는데 서랍장을 3개 사는 것은 낭비다. EER 분리는 데이터의 볼륨과 고유성을 보고 결정해야 한다.

Ⅴ. 기대효과 및 결론

EER을 도입하면 데이터 설계의 의미적 정확성이 비약적으로 향상된다. 현실 세계의 복잡한 비즈니스 규칙과 계층을 ERD 스케치 단계에서 완벽하게 잡아내므로, 개발자들이 객체지향 코드를 짤 때 설계도와 코드 간의 불일치(Impedance Mismatch)가 사라지는 기대효과가 있다. 또한 텅 빈 NULL 값들로 인한 디스크 공간 낭비를 막고 데이터 품질을 끌어올릴 수 있다.

미래의 데이터 아키텍처에서도, 시스템이 아무리 MSA(마이크로서비스)로 쪼개지더라도 각 도메인 내의 데이터 계층을 정의하는 EER의 상속 및 제약조건 철학은 여전히 핵심 뼈대로 작동할 것이다. EER은 단순한 그림 기호가 아니라, 복잡도를 계층으로 제압하는 논리적 사고방식 그 자체다.

📢 섹션 요약 비유: EER은 복잡한 도심의 도로를 1차선에서 지하차도와 고가도로로 입체화시키는 작업이다. 차선이 나뉘면 길은 복잡해 보이지만, 결과적으로 데이터(차량)는 충돌 없이 가장 빠르고 정확하게 흐른다.

📌 관련 개념 맵

개념	연결 포인트
객체지향 프로그래밍 (OOP)	EER의 상속 개념이 코드로 그대로 구현되는 프로그래밍 패러다임
ORM (Object-Relational Mapping)	객체의 상속 계층과 RDBMS의 테이블 구조 간 불일치를 해결하는 미들웨어
정규화 (Normalization)	중복 데이터를 제거하는 또 다른 관점. EER은 구조적으로 1차 정규화를 돕는다.
슈퍼타입/서브타입 데이터 모델	EER을 실제 물리적 RDBMS 테이블로 구현하기 위한 물리 설계 기법

📈 관련 키워드 및 발전 흐름도

전통적 ER 모델 (Entity-Relationship)
    │
    ▼
객체지향 설계 사상 등장 (OOP)
    │
    ▼
확장 ER 모델 (EER) · 일반화(Generalization) 및 특수화(Specialization)
    │
    ▼
상속 제약조건 (Disjoint, Overlap, Total, Partial)
    │
    ▼
ORM 연계 및 물리적 슈퍼타입/서브타입 테이블 변환

이 흐름도는 단순한 개체 분리에서 출발하여, 객체지향의 상속이 모델링에 들어오고, 결국 물리적 테이블 설계로 이어지는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

옛날에는 '동물'이라는 도화지에 강아지와 물고기 특징을 섞어서 막 그렸어요.
EER은 먼저 '동물'이라는 기본 몸통을 그리고, 그 아래에 꼬리를 추가하면 강아지, 지느러미를 추가하면 물고기가 되도록 뼈대를 나누는 똑똑한 그림 그리기 방법이에요.
이렇게 하면 공통된 눈, 코, 입은 부모 동물에게 한 번만 그리면 돼서 훨씬 빠르고 정확하게 수천 마리의 동물을 그릴 수 있답니다.