툴을 바꾸면 모델이 다르게 보인다

DW 프로젝트에 투입되면 보통 기존 모델부터 받아서 훑습니다. 이때 한 가지 확인하지 않으면 나중에 고생하는 게 있습니다. 모델을 그린 툴과 그 툴의 표기법입니다.

ERwin으로 설계한 모델을 DA#으로 열면 관계선 해석이 달라집니다. 관계선의 점선이 한쪽에서는 “비식별 관계"인데 다른 쪽에서는 “선택적 참여"입니다. 둘 다 정상입니다. 표기법이 다를 뿐입니다. 문제는 이걸 모른 채 모델 리뷰를 하면 같은 ERD를 놓고 서로 다른 이야기를 하게 된다는 것입니다.

ERD는 모델러, 개발자, 현업이 공통으로 읽는 언어입니다. 그 언어에 방언이 여러 개 있다는 걸 모르면 소통이 꼬입니다.

같은 까마귀발인데 해석이 갈린다

ERD 표기법 중 가장 널리 쓰이는 건 까마귀발(Crow’s Foot) 계열입니다. 관계선 끝에 대시(1), 원(0), 까마귀발(N) 기호를 조합해서 카디널리티를 표현합니다. 여기까지는 공통입니다.

문제는 까마귀발 안에 두 계열이 있다는 점입니다.

IE(Information Engineering) 방식 은 ERwin, PowerDesigner 등에서 기본으로 씁니다. 식별 관계를 실선, 비식별 관계를 점선으로 구분합니다. 식별 관계란 상위 엔터티의 PK가 하위 엔터티 PK의 일부로 포함되는 것입니다.

Barker 방식 은 Oracle 계열 툴과 DA#에서 씁니다. 겉보기엔 같은 까마귀발인데 기호의 의미가 다릅니다.

기호IE 방식Barker 방식
점선비식별 관계선택적 참여 (0 or 1)
실선식별 관계필수 참여 (정확히 1)
대시정확히 1식별 관계

점선의 의미가 완전히 다릅니다. IE에서 점선은 “상위 PK가 하위 PK에 포함되지 않는다"는 구조적 정보입니다. Barker에서 점선은 “참여가 선택적이다"라는 비즈니스 규칙입니다. 같은 기호가 다른 층위의 정보를 담고 있습니다.

DA#으로 설계한 모델을 ERwin으로 가져와서 리뷰하면 이 차이를 모르는 사람이 점선을 전부 비식별 관계로 읽어버립니다. 설계 의도가 그대로 왜곡됩니다.

까마귀발을 안 쓰는 표기법도 있다

IDEF1X라는 표기법은 까마귀발 대신 원으로 카디널리티를 나타냅니다. 원이 없으면 정확히 1, 빈 원은 0 또는 1, 속이 찬 원은 0 또는 N입니다. 식별/비식별은 IE와 동일하게 실선/점선으로 구분합니다.

변형도 있습니다. 모든 원을 속이 찬 원으로 통일하면서 Z(0 or 1), P(1 or N) 같은 문자를 붙이는 방식입니다. ERwin에서 IDEF1X 모드로 전환하면 이걸 쓸 수 있습니다.

까마귀발 계열과 IDEF1X는 카디널리티를 표현하는 기호 체계 자체가 다릅니다. 까마귀발 계열 내에서의 혼동(IE vs Barker)이 같은 기호를 다르게 읽는 문제라면, IDEF1X와의 차이는 기호 자체를 모르면 읽지 못하는 문제입니다. 성격이 다른 혼동입니다.

프로젝트에서 부딪히는 현실

표기법을 외우라는 게 아닙니다. 프로젝트에서 실제로 생기는 문제를 미리 아는 게 중요합니다.

모델링 툴을 바꿀 때 표기법 전환이 자동으로 되기는 하지만 완벽하지 않습니다. 세부 표현이 달라지거나, 뒤에서 다룰 수퍼-서브 타입처럼 구조 자체가 바뀌는 경우도 있습니다. 같은 IE 방식이라도 툴에 따라 대시 2개를 하나로 표현하는 것 같은 미세한 차이가 있습니다.

프로젝트 시작할 때 세 가지를 맞추면 됩니다.

  • 어떤 표기법을 쓸 건지 정합니다
  • 팀 전원이 해당 표기법의 기호 의미를 압니다
  • 툴의 도움말에서 표기법 상세를 한 번은 확인합니다

이게 안 된 프로젝트에서는 모델 리뷰가 표기법 논쟁으로 빠집니다. 설계를 논의해야 할 시간에 “이 선이 뭔 뜻이냐"를 따지게 됩니다.

코드로 그리는 ERD

클라우드 DW 환경에서는 ERD를 GUI 툴로 그리지 않는 팀도 많습니다. dbt에서 SQL 기반으로 모델을 정의하고, Mermaid나 DBML 같은 텍스트 기반 다이어그램으로 관계를 표현합니다. 코드 리뷰처럼 모델 변경 이력을 추적할 수 있다는 게 장점입니다.

도구가 바뀌어도 표현해야 하는 건 같습니다. 카디널리티, 식별/비식별 관계, 필수/선택 참여. 이 개념을 모르면 GUI 툴이든 텍스트 기반이든 모델을 제대로 읽을 수 없습니다.

다음 글에서는 수퍼-서브 타입을 다룹니다. 고객을 개인고객과 법인고객으로 나누는 구조인데, 논리 모델에서 물리 모델로 넘어갈 때 선택지가 갈리고 DW에서는 그 선택이 차원 설계로 이어집니다.