IE·Barker ERD 표기법 읽기

핵심 요약

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

핵심 질문

1. IE·Barker ERD 표기법 읽기를 실제 업무 사례에서 어떤 기준으로 판별하는가?
2. 한 행이 나타내는 업무 사실과 유일성·필수성·변경 가능성은 무엇인가?
3. 잘못 모델링하면 어떤 중복·이상 현상·변경 영향이 발생하는가?
4. 여러 설계안 중 업무 의미와 변경 용이성을 가장 잘 보존하는 안을 어떻게 고르는가?

학습 목표

• 표기법이 달라도 엔터티·속성·관계의 같은 업무 의미를 읽는다.
• 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를 정확한 문법으로 선언한다.

흔한 오해와 주의점

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

문항 풀이 보강: ERD를 문장과 DDL로 변환하기

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)를 쓴다.

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

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의 선·원 표기를 기계적으로 대응시키기보다 최소/최대 카디널리티와 식별 관계를 자연어로 먼저 확정한 뒤 기호를 읽습니다.

사례를 판별하는 순서

1. 모델이 표현해야 하는 업무 사실과 행 단위(Grain)를 한 문장으로 정의합니다.
2. 각 인스턴스를 유일하게 식별할 수 있는 후보와 변경 가능성을 확인합니다.
3. 속성이 어느 사실에 종속되는지와 관계의 필수성·카디널리티를 확인합니다.
4. 중복 저장으로 삽입·갱신·삭제 이상이 생기는지 검토합니다.
5. 물리 성능을 이유로 구조를 바꿀 때 원천 데이터와 동기화·복구 규칙을 함께 설계합니다.

모델 품질 확인표

• 같은 업무 사실이 여러 곳에 중복 저장되지 않는가?
• 이름과 도메인이 한 가지 의미로 사용되는가?
• PK·FK가 실제 업무 관계와 선택성을 정확히 표현하는가?
• 현재 화면이나 프로세스에 과도하게 종속되지 않는가?
• 정규화와 성능 설계의 이유를 측정 가능한 근거로 설명할 수 있는가?

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

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

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

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

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

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

마지막 점검

• 화면의 입력 항목이나 현재 프로세스를 그대로 엔터티·관계로 옮기지 않습니다.
• 한 행의 업무 사실, 후보 식별자와 함수 종속성을 먼저 확정합니다.
• 중복과 비일관성을 만들면서 조회 편의만 얻는 설계를 정답으로 선택하지 않습니다.
• 반정규화와 물리 설계는 측정된 성능 문제와 동기화·복구 대책이 있을 때 적용합니다.

복습 문제

1. o로 표시된 속성은 Oracle DDL에서 어떤 NULL 속성을 가지는가?
2. 까마귀발은 최소값과 최대값 중 무엇을 나타내는가?
3. 이 개념을 실제 업무 사례에서 판별할 수 있는가?
4. 한 행의 업무 의미와 식별자를 설명할 수 있는가?