ERD 표기법은 종류가 여러 개라 처음엔 헷갈리지만, 실무에서 읽고 쓰는 건 사실상 까마귀발(IE) 하나입니다. 이 글은 그 까마귀발 기호를 하나도 빠짐없이 익히는 데 대부분을 할애하고, 학교에서 배우는 Chen 표기법과 Oracle 문서에서 보이는 Barker까지 같은 예제로 비교합니다.
표기법이 여러 개인 이유는 간단합니다. 1970년대에 학계(Chen)가 개념을 만들었고, 이후 실무 도구들이 화면에 그리기 좋은 형태(IE)로 다듬어 채택했습니다. 그래서 배울 때와 일할 때 보는 그림이 다른 겁니다.
까마귀발 기호 읽는 법
본론입니다. IE(Information Engineering) 표기법에서 알아야 할 것은 딱 두 가지, 선 끝의 기호와 선의 종류입니다. 이것만 익히면 어떤 ERD를 열어도 관계를 읽을 수 있습니다.
선 끝 기호: ERD 기호와 화살표의 의미
먼저 알아둘 것이 있습니다. 선 끝에 붙는 표시는 화살표가 아니라 개수(카디널리티) 기호입니다. 기본 기호는 세 가지뿐입니다.
| 기호 | 의미 |
|---|---|
세로줄 | |
1 |
동그라미 ○ |
0 (없어도 됨) |
| 까마귀발 (세 갈래) | N (여러 건) |
실제 선 끝에는 이 기호가 두 개씩 조합되어 붙습니다. 읽는 순서가 핵심입니다. 안쪽(선 가운데 쪽) 기호가 최소, 엔터티에 붙은 바깥 기호가 최대입니다. 나올 수 있는 조합은 네 가지가 전부입니다.
||정확히 1. 그 행이 반드시 1건 있어야 합니다.○|0 또는 1. 없을 수도 있고, 있으면 1건입니다.|<1 이상(1..N). 최소 1건은 있어야 합니다.○<0 이상(0..N). 없을 수도, 여러 건일 수도 있습니다.
선의 종류: 실선과 점선
선 자체도 두 가지입니다. 실선은 식별 관계로, 부모의 키가 자식 기본키의 일부가 되는 경우입니다. 주문 상세 테이블의 PK가 (주문ID+상품ID) 복합키인 경우가 대표적입니다. 점선은 비식별 관계로, 부모의 키를 일반 FK 컬럼으로만 참조합니다. 게시글이 member_id 컬럼으로 회원을 참조하는, 실무에서 가장 흔한 형태가 이쪽입니다.
처음 읽을 때는 실선·점선 구분보다 선 끝 기호를 정확히 읽는 게 먼저입니다. 구분이 필요해지는 시점은 복합키 설계를 만났을 때입니다.
읽기 연습 1: 1:N 관계는 어떻게 표시하나
이제 게시판 DB로 연습합니다. 회원과 게시글 사이의 선이 이렇게 생겼습니다.
회원 ||──────○< 게시글회원 쪽 끝부터 읽습니다. 게시글 입장에서 회원은 ||, 정확히 1명입니다. 반대쪽, 회원 입장에서 게시글은 ○<, 0건일 수도 여러 건일 수도 있습니다. 합치면 이렇게 읽힙니다. "게시글은 반드시 회원 한 명의 것이고, 회원은 게시글이 없을 수도 많을 수도 있다." 가장 흔한 1:N 관계의 표준 형태입니다.
읽기 연습 2: 최소값이 달라지면
주문과 주문 상세는 모양이 조금 다릅니다.
주문 ||──────|< 주문상세주문 상세 쪽 끝이 ○<가 아니라 |<입니다. 최소가 0이 아니라 1이라는 뜻입니다. 읽으면 "주문 상세는 반드시 주문 하나에 속하고, 주문에는 상세가 최소 1건은 있어야 한다"가 됩니다. 빈 주문을 허용하지 않겠다는 업무 규칙이 기호 하나에 담긴 겁니다. ○<와 |<의 차이를 놓치면 이 규칙이 그림에서 사라집니다.
읽기 연습 3: 0 또는 1
회원과 회원 프로필처럼 1:1로 대응하는 관계에서 자주 보는 모양입니다.
회원 ||──────○| 프로필프로필 쪽 끝이 ○|, 0 또는 1입니다. "회원은 프로필이 없을 수도 있고, 있어도 하나뿐이다"로 읽습니다.
읽기 연습 4: 점선이 섞이면
이번에는 선 종류까지 함께 읽습니다. 게시글과 회원 사이가 점선으로 그려져 있습니다.
회원 ||- - - - ○< 게시글끝 기호는 연습 1과 같으니 관계의 개수는 동일합니다. 달라진 건 점선, 즉 비식별 관계라는 정보입니다. "게시글은 회원의 키를 일반 컬럼(member_id)으로 참조하고, 그 컬럼은 게시글 기본키에 포함되지 않는다"까지 읽어낼 수 있습니다. 반대로 이 선이 실선이었다면 member_id가 게시글 PK의 일부라는 뜻이 되니, 선 하나로 키 설계가 달라집니다.
읽기 연습 5: 다대다가 풀린 모양
마지막으로 실무 다이어그램에서 다대다가 실제로 보이는 형태입니다. 게시글과 태그의 N:M은 보통 중간 테이블을 사이에 두고 이렇게 그려져 있습니다.
게시글 ||──────○< post_tags >○──────|| 태그중간 테이블 post_tags에서 양쪽으로 뻗은 선을 각각 읽으면 됩니다. 게시글 1건에 post_tags가 0건 이상, 태그 1건에도 post_tags가 0건 이상. 두 개의 1:N이 합쳐져 "게시글 하나에 태그 여러 개, 태그 하나에 게시글 여러 개"라는 다대다가 완성됩니다. 다이어그램에서 이런 모래시계 모양을 보면 다대다를 풀어놓은 것이라고 읽으면 됩니다.
다섯 연습을 통과했다면 IE 표기법에서 만날 조합은 전부 읽은 셈입니다. 남은 건 실제 다이어그램에서 반복하는 것뿐이고, ERD 그리는 법의 게시판 실습에서 이어서 연습할 수 있습니다.
읽을 때 자주 틀리는 세 가지
연습을 마친 김에, 설계 리뷰에서 자주 보는 오독 유형도 짚어 둡니다.
기호를 화살표로 읽는 것. 까마귀발이 화살촉처럼 생겨서 "데이터가 이쪽으로 흐른다"로 읽는 경우가 있는데, 방향이 아니라 개수입니다. 까마귀발이 붙은 쪽이 여러 건이라는 뜻일 뿐입니다.
최소와 최대를 반대로 읽는 것. ○<를 "최대 0"으로 읽으면 관계 전체가 뒤집힙니다. 항상 안쪽이 최소, 엔터티에 붙은 쪽이 최대입니다. 헷갈릴 때는 엔터티에 닿아 있는 기호부터 확인하면 됩니다.
카디널리티와 FK 위치를 혼동하는 것. "회원 1 : N 게시글"에서 FK(member_id)는 항상 N쪽인 게시글에 있습니다. 다이어그램을 읽다가 FK가 1쪽에 있는 것처럼 보인다면, 관계를 반대로 읽었을 가능성부터 의심하는 게 맞습니다.
Chen 표기법: 학교에서 배우는 그것
데이터베이스 수업에서 마름모와 타원으로 그렸던 기억이 있다면 그게 Chen 표기법입니다. 시험 대비를 겸해 기호를 표로 정리해 두면 이렇습니다.
| Chen 기호 | 의미 |
|---|---|
| 사각형 | 개체(엔터티) |
| 마름모 | 관계 |
| 타원 | 속성 |
| 밑줄 친 타원 | 키 속성 |
| 이중 타원 | 다중 값 속성 |
| 선 위의 1, N, M | 카디널리티 |
개념을 배우기에는 좋은 구조입니다. 관계 자체가 마름모라는 독립된 도형이라 "개체와 개체 사이에 관계가 있다"는 모델의 뼈대가 눈에 보입니다. 시험 문제로 나오는 이유이기도 합니다.
실무에서 안 쓰는 이유도 같은 구조에서 나옵니다. 관계마다 마름모, 속성마다 타원을 그리면 테이블 서른 개짜리 스키마에서 도형 수백 개가 생깁니다. 화면이 감당하지 못하고, 컬럼의 자료형·제약 같은 구현 정보를 담을 자리도 없습니다. 그래서 과제에서 Chen을 지정받은 경우가 아니라면 IE로 그리는 게 실무 기준입니다.
Chen에서 IE로 넘어올 때의 대응은 단순합니다. 마름모(관계)는 두 테이블을 잇는 선이 되고, 선 위의 1과 N은 선 끝의 기호가 되고, 타원(속성)은 테이블 박스 안의 컬럼 행이 됩니다. 개념은 하나도 버릴 게 없고 그리는 방식만 바뀝니다.
Barker 표기법: Oracle 문서에서 보이는 방식
하나 더, Oracle 계열 문서와 오래된 설계 자료에서 Barker 표기법을 만날 수 있습니다. 까마귀발로 N을 표시하는 건 IE와 비슷한데, 선의 절반을 점선(없어도 됨)·절반을 실선(반드시 있어야 함)으로 그려 필수 여부를 표현하고, 관계 이름을 양방향으로 적는 게 특징입니다. 직접 그릴 일은 드물어도, 읽을 줄 알면 오래된 설계 문서 앞에서 당황하지 않습니다.
같은 관계, 세 가지 표기법 비교
말로 비교하는 것보다 같은 관계를 나란히 보는 게 빠릅니다. "회원 1 : N 게시글"을 세 표기법으로 그리면 이렇게 됩니다.
담는 정보는 같습니다. 다른 건 그리는 비용과 읽는 비용입니다. IE가 가장 압축적이고, Chen이 가장 설명적이고, Barker가 그 사이 어딘가에 있습니다.
실무는 왜 IE로 수렴했나
실무 ERD 도구 대부분이 IE를 기본 표기법으로 채택하고 있습니다. 이유는 위에서 본 그대로입니다. 테이블이 수십 개로 늘어나도 박스와 선만으로 그림이 유지되고, 테이블 박스 안에 컬럼·자료형·키 정보를 함께 담을 수 있어서 다이어그램이 곧 구현 문서가 됩니다. Mermaid의 erDiagram도, 무료 온라인 ERD 툴들도 같은 까마귀발 체계를 씁니다. 한 번 익혀 두면 도구가 바뀌어도 어떤 툴이든 쉽게 사용할 수 있다는 뜻입니다.
자주 묻는 질문
학교에서는 Chen 표기법을 배웠는데 실무는 왜 IE를 쓰나요?
실무에서 IE를 쓰는 이유는 공간과 도구 때문입니다. Chen은 관계마다 마름모, 속성마다 타원을 그려서 테이블 서른 개만 되어도 화면이 감당이 안 됩니다. IE는 테이블 박스와 선만으로 같은 정보를 담아 큰 스키마에서도 읽을 수 있고, 실무 ERD 도구 대부분이 IE를 채택하면서 사실상 표준이 됐습니다. Chen으로 배운 개념은 그대로 유효하니 기호만 옮겨 읽으면 됩니다.
ERD의 점선과 실선은 뭐가 다른가요?
점선과 실선의 차이는 식별 관계인지 여부입니다. 실선(식별 관계)은 부모의 키가 자식 기본키의 일부가 되는 경우로, 주문 상세의 PK(주문ID+상품ID)가 대표적입니다. 점선(비식별 관계)은 부모의 키를 일반 FK 컬럼으로만 참조하는 경우로, 게시글의 member_id처럼 대부분의 관계가 여기에 속합니다.
ERD 화살표의 방향은 무슨 의미인가요?
IE 표기법의 선 끝 기호는 방향을 가리키는 화살표가 아니라 개수(카디널리티)를 나타내는 기호입니다. 까마귀발처럼 세 갈래로 벌어진 쪽이 여러 건(N), 짧은 세로줄이 1건을 뜻합니다. 화살표로 오해하고 데이터가 흐르는 방향으로 읽으면 반대로 읽게 되니, 각 끝을 그 테이블 쪽의 개수로 읽어 주세요.
다대다(N:M) 관계는 어떻게 그리나요?
다대다는 양쪽 끝에 까마귀발을 그려 표현합니다. 다만 관계형 DB는 N:M을 직접 저장할 수 없어서, 구현 단계에서는 두 테이블의 키를 가진 중간 테이블을 두고 1:N 관계 두 개로 풀게 됩니다. 그래서 실무 ERD에서는 N:M 선 대신 중간 테이블(post_tags 같은)이 그려진 형태를 더 자주 보게 됩니다.
마지막으로 이 글 전체를 네 문장으로 요약합니다. 선 끝의 기호는 화살표가 아니라 개수다. 안쪽이 최소, 엔터티 쪽이 최대다. 조합은 ||, ○|, |<, ○< 네 가지가 전부다. 실선은 식별, 점선은 비식별이다. 이 네 문장이 머리에 있으면 어떤 ERD든 읽어낼 수 있습니다.
기호를 외우는 것보다 중요한 건 반복해서 읽어 보는 겁니다. 그리고 하나 더 말해 두면, 기호를 완벽히 몰라도 시작에는 지장이 없습니다. DDL을 WorksCove ERD에 붙여넣으면 관계선이 까마귀발 표기법대로 그려져 나오니, 그 그림을 이 글의 기호표와 대조하며 읽는 것도 좋은 연습이 됩니다.