4. ERD 설계

1. ERD 설계의 개념과 궁극적 의의

ERD 설계는 단순한 테이블 드로잉이 아니라, 모호한 비즈니스 도메인을 표준 기호로 추환하여 단 하나의 의미로 고정하는 고도의 엔지니어링 및 추상화 과정입니다.

• 비용의 기하급수적 절감 (선 설계 후 구현):
  • 코딩 및 테스트 단계에서 데이터 구조 결함이 발견되면 시스템 전체를 뜯어고쳐야 하므로 막대한 재작업 비용이 듦.
  • 설계 단계에서의 수정은 지우개나 툴 클릭 몇 번으로 가능하여 리스크를 선제 해결
• 이해관계자 간의 번거로운 번거로움 해소 (Bridge): 현업 실무자(비즈니스 언어)와 개발자(데이터/코드 언어) 사이의 언어 격차를 연결하는 공통의 시각 언어(Universal Visual Language) 역할을 수행
• 데이터 무결성(Integrity) 확보:
  • 코드는 버그가 나면 패치하면 되지만, 한 번 오염되거나 꼬인 데이터는 복구 불가능
  • 설계 단계의 정규화와 제약조건 정의는 데이터의 수명 주기 전반을 방어하는 그릇을 만드는 과정

2. 실무형 ERD 설계 도구 선택 가이드

단순히 그림만 그리는 드로잉 툴(Draw.io 등)과 전문적인 데이터 모델링 툴을 가르는 4가지 핵심 기준입니다.

1. 포워드 엔지니어링(Forward Engineering): ERD 도면을 기반으로 실제 DBMS에 맞는 완전한 DDL 스크립트(CREATE TABLE 등)를 오차 없이 정밀하게 추출
2. 라운드 트립 & 동기화(Round-Trip/Synchronization): 개발 도중 구조가 변경되었을 때, 기존 데이터를 날리지 않고 차이점만 분석하여 안전한 ALTER 문을 자동 생성
3. 팀 협업 및 용어 사전(Version Control): 한글 논리명과 영문 물리명을 철저히 분리하고, 전사 표준 용어 사전을 연동하여 컬럼 명명 규칙을 강제
4. 시나리오별 최적 도구 매핑:

평가 기준 세부 검토 항목 비고

엔지니어링 성능(Engineering Capability)	• Forward: ERD 🡲 DB 생성 스크립트 추출 정확도• Reverse: 가동 중인 DB 🡲 ERD 시각화 정밀도• Diff/Sync: 설계와 실제 DB 간의 차이점 자동 동기화	• 실무형 설계 도구와 단순 드로잉 툴(Draw.io 등)을 가르는 가장 결정적인 기준
표기법 및 모델링 규격(Notation Support)	• 까마귀 발 표기법(Information Engineering) 지원 여부• IE, IDEF1X, Chen 등 다양한 표준 표기법 전환 가능 여부• 개념/논리/물리 단계별 뷰 전환 지원	• 교육 및 표준화 관점에서 매우 중요• 논리 모델(한글명)과 물리 모델(영문명)이 따로 관리되어야 진정한 모델링 툴
협업 및 클라우드(Collaboration)	• 동시 편집(Real-time Co-editing) 기능 제공 여부• 웹 브라우저 기반(SaaS) 가동 여부• 변경 사항에 대한 코멘트 및 승인(Approve) 워크플로우	• 원격 근무나 대규모 조별 프로젝트 강의 시 SaaS 기반 툴이 압도적으로 유리함 (예: DrawDB, ERDLab 등)
비용 및 라이선스(Cost & License)	• 오픈소스(Open-Source) 또는 완전 무료(Free) 여부• 상용 도구인 경우 학생/교육용 라이선스 제공 여부• 온프레미스(On-Premise) 구축 시 추가 비용 발생 여부	• 기업에서는 ERwin, DA# 같은 고가 장비를 쓰지만,• 교육 현장이나 스타트업에서는 오픈소스나 오픈소스 기반 무료 에디션이 최선
생산성 및 UI/UX(Productivity)	• 테이블/컬럼 드래그 앤 드롭의 직관성• 도메인(Domain) 정의 기능 (예: '주소' 타입을 정의해 재사용)• 사전 정의된 단어집/용어 사전(Dictionary) 연동 기능	• 데이터 표준화(명명 규칙)를 강제할 수 있는 용어 사전 기능이 있으면 대형 프로젝트 설계 시 품질이 비약적으로 상승함
인프라 및 설치 환경(Environment)	• OS 호환성 (Windows, Mac, Linux Mint/Ubuntu 등)• 웹 기반 가동 vs 무거운 데스크톱 가프리케이션 설치• 자원 소모량 (대규모 테이블 배치 시 렉 발생 여부)	• 리눅스 환경에서 AI 모델링과 DB를 동시에 다루는 개발자에게는 크로스 플랫폼(Java 기반 또는 웹 기반) 지원이 필수적

3. 까마귀 발 표기법 (IE: Information Engineering Notation)

관계선의 양 끝단에 선, 동그라미, 세 갈래 발을 조합하여 비즈니스 규칙을 시각적으로 통제하는 글로벌 표준 표기법입니다.

🔹 수량/사상수 (Cardinality) & 필수성 (Optionality) 해석

• 안쪽 기호는 최소값(필수/선택), 바깥쪽 기호는 최대값(하나/여러 개)으로 고정하여 안에서 바깥 순서로 읽습니다.
  • || (Mandatory One): 정확히 1개의 데이터와 매핑되어야 함 (최소 1개, 최대 1개)
  • O| (Optional One): 상대방 데이터가 없거나(0) 정확히 1개만 존재해야 함
  • |⤙ (Mandatory Many): 최소 1개 이상, 최대 수십 개 매핑 (필수적인 다수 관계)
  • O⤙ (Optional Many): 아예 없거나(0) 여러 개 존재할 수 있음

🔹 화살표 동사 리딩법 (어느 쪽 기준으로 읽는가?)

내가 출발하는 주체 엔터티에서 선을 따라 반대편 끝단에 박힌 최종 기호를 문장으로 읽어 내립니다.

• 고객 ➔ 주문: 반대편에 O⤙가 있으므로 ➔ "고객은 주문을 0번 또는 여러 번 할 수 있다."
• 주문 ➔ 고객: 반대편에 ||가 있으므로 ➔ "모든 주문은 반드시 한 명의 고유한 고객에 의해서만 유효하다."

🔹 선의 종류에 따른 종속성 제어

• 식별 관계 (Solid Line: 실선):
  • 부모의 주식별자(PK)가 자식의 주식별자(PK)의 일부로 흡수되는 강한 종속 관계
  • 부모가 지워지면 자식도 존재 가치가 없어 삭제됨 (ex: 주문 ➔ 주문상세)
• 비식별 관계 (Dashed Line: 점선):
  • 부모의 PK가 자식의 일반 컬럼(외래키: FK)으로만 연결되는 약한 참조 관계
  • 부모가 없어도 자식은 독립적으로 존재 (ex: 부서 ➔ 사원, 부서가 없어도 사원은 존재함)