IE·Barker ERD 표기법 읽기

핵심 요약

IE와 Barker 표기에서 필수·선택 속성, 카디널리티와 식별 관계를 읽는 요령을 익힌다.

학습 목표

• 표기법이 달라도 엔터티·속성·관계의 같은 업무 의미를 읽는다.
• Barker의 *, o와 IE의 관계 기호를 제약조건으로 변환한다.

본문

개념 지도

업무 사실→엔터티와 행 단위→속성·도메인→관계·카디널리티→제약

핵심 내용

ERD 표기법은 모양이 달라도 “무엇이 필수인가, 몇 건까지 연결되는가, 무엇으로 식별하는가”를 표현한다.

• Barker 속성의 *는 필수, o는 선택을 뜻한다.
• IE 관계의 원은 최소 0, 선은 최소 1, 까마귀발은 최대 다수를 뜻한다.
• 식별 관계는 부모 식별자가 자식 PK에 포함되는지를 확인한다.

예를 들어 다음 Barker 표현은 REGR_NO만 NULL을 허용하고 PROD_ID는 PK가 될 수 있음을 뜻한다.

PRODUCT
* PROD_ID
* PROD_NM
* REG_DT
o REGR_NO

물리 DDL에서는 필수 속성에 NOT NULL, 식별자에 PRIMARY KEY, 관계에 FOREIGN KEY를 정확한 문법으로 선언한다.

표기 기호보다 먼저 읽을 문장

ERD 표기법이 달라도 관계는 다음 네 가지 질문으로 번역하면 됩니다.

1. 어느 엔터티가 부모이고 어느 엔터티가 자식인가?
2. 부모 한 건에 자식이 최소 몇 건, 최대 몇 건 가능한가?
3. 자식은 부모 없이 존재할 수 있는가?
4. 부모 식별자가 자식 주식별자에 포함되는가?

예를 들어 “고객은 주문을 0건 이상 가질 수 있고, 주문은 반드시 한 고객에 속한다”면 고객→주문은 1:M이고 고객 입장에서는 선택적, 주문 입장에서는 필수입니다.

DDL로 검증하기

CREATE TABLE orders (
  order_id   NUMBER PRIMARY KEY,
  customer_id NUMBER NOT NULL,
  CONSTRAINT orders_customer_fk
    FOREIGN KEY (customer_id) REFERENCES customer(customer_id)
);

NOT NULL과 FK가 주문의 부모 필수성을 구현합니다. 반면 “고객이 주문을 반드시 한 건 이상 가져야 한다”는 최소 자식 수 1 규칙은 FK만으로 자동 보장되지 않으며 별도의 업무 절차나 지연 검증이 필요합니다.

IE의 Crow's Foot, Barker의 선·원 표기를 기계적으로 대응시키기보다 최소/최대 카디널리티와 식별 관계를 자연어로 먼저 확정한 뒤 기호를 읽습니다.

표기법을 관계 의미로 번역하기

ERD 기호는 모양보다 관계의 최소·최대 참여도를 읽어야 합니다.

고객 1 ─── 0..N 주문
주문 1 ─── 1..N 주문상품

첫 관계는 고객이 주문 없이 존재할 수 있고, 주문은 반드시 한 고객에 속한다는 뜻입니다. 두 번째 관계는 주문에 최소 한 개의 상품이 있어야 한다는 업무 규칙을 표현합니다. 실제 Database FK만으로 부모 쪽 “최소 한 자식”을 자동 보장하기는 어려우므로 Transaction Logic이나 별도 검증이 필요할 수 있습니다.

식별 관계에서는 부모 식별자가 자식 PK의 일부가 됩니다. 비식별 관계에서는 부모 Key가 자식의 일반 FK이고 자식은 독립 PK를 가집니다.

IE와 Barker의 선·원·까마귀발 모양을 통째로 외우기보다, 각 끝점에서 0/1의 최소 참여와 1/N의 최대 참여를 문장으로 번역해 검증합니다.

시험 포인트

ERD 문제는 기호의 이름보다 양쪽 끝을 업무 문장으로 읽는 것이 빠르다.

고객 쪽 1, 주문 쪽 0..N
→ 각 주문은 한 고객에 속한다.
→ 고객은 주문이 없거나 여러 건일 수 있다.

까마귀발은 최대 다수, 원은 최소 0, 막대는 최소 또는 최대 1을 나타낸다. 관계선의 어느 쪽에 기호가 붙었는지 바꾸어 읽지 않는다.

Barker 속성의 *는 필수, o는 선택이다. 필수 속성은 NOT NULL로 구현하지만, 필수라는 이유만으로 모두 PK가 되는 것은 아니다.

CREATE TABLE product (
  prod_id VARCHAR2(10) NOT NULL,
  prod_nm VARCHAR2(100) NOT NULL,
  reg_dt  DATE NOT NULL,
  regr_no NUMBER(10),
  CONSTRAINT product_pk PRIMARY KEY (prod_id)
);

CREATE TABLE 내부에서는 CONSTRAINT product_pk PRIMARY KEY (product_id)를 쓰고, 생성 후 추가할 때는 ALTER TABLE product ADD CONSTRAINT product_pk PRIMARY KEY (product_id)를 쓴다.

자주 틀리는 부분

• 속성의 필수 표기와 PK 표기는 같은 개념이 아니다. PK는 유일성까지 갖는다.
• 관계선의 기호는 반드시 양쪽 끝을 각각 읽는다.
• 표기법 이름을 암기하기보다 최소·최대 카디널리티를 업무 문장으로 바꿔 검증한다.