툴을 바꾸면 모델이 다르게 보인다 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에서는 그 선택이 차원 설계로 이어진다.