자료의 항목과 관계를 개체 관계도로 설계하기

한 표에 모든 정보를 넣으면 같은 사실이 반복된다

독서 모임 신청표 한 줄에 참가자 이름, 이메일, 모임 제목, 날짜, 장소, 결제 상태를 모두 넣으면 간단해 보인다. 그러나 같은 모임에 30명이 신청하면 날짜와 장소가 30번 반복된다. 장소가 바뀔 때 한 행만 고치면 서로 다른 날짜가 남는 갱신 오류가 생긴다.

개체 관계도는 따로 관리할 대상을 개체로, 대상의 성질을 속성으로, 대상 사이 연결을 관계로 표현한다. 참가자, 모임, 신청을 각각 구분하면 참가자 이메일은 참가자에 한 번, 모임 날짜는 모임에 한 번 저장하고 신청 상태만 연결 기록에 둘 수 있다.

사각형·속성·관계선을 먼저 읽는다

Chen의 개체 관계 모형은 개체 집합과 관계 집합, 속성을 구분해 현실의 정보를 개념 구조로 나타낸다. 표기 방식은 도구마다 다르지만 핵심 질문은 같다. 무엇을 독립적으로 식별할 것인가, 어떤 값을 그 대상에 붙일 것인가, 두 대상이 어떤 업무 관계로 이어지는가를 묻는다.

이 글에서는 사각형을 개체, 사각형 안의 목록을 속성, 두 개체 사이 이름이 붙은 선을 관계로 쓴다. 기본키는 한 항목을 고유하게 식별하는 값이다. 이름은 겹칠 수 있으므로 참가자ID처럼 변하지 않고 중복되지 않는 식별자를 둔다.

1, N, 0..1은 허용되는 개수를 말한다

카디널리티는 관계의 한쪽 항목이 다른 쪽 항목과 몇 개까지 연결될 수 있는지 나타낸다. 참가자 한 명은 여러 모임에 신청할 수 있고, 한 모임에는 여러 참가자가 올 수 있으므로 참가자와 모임은 다대다 관계다. 이를 그대로 두기보다 신청이라는 연결 개체를 사이에 둔다.

최소 개수도 중요하다. 새로 만든 모임은 아직 신청이 0개일 수 있고, 신청 기록은 반드시 참가자 한 명과 모임 한 개를 가리켜야 한다. “0..N”, “1”처럼 최소와 최대를 함께 적으면 선택 관계와 필수 관계를 구분할 수 있다.

속성은 그 값이 누구에게 속하는지 따진다

결제 상태는 참가자 자체의 성질이 아니다. 같은 참가자가 10월 모임 비용은 냈고 11월 모임 비용은 아직 내지 않았을 수 있기 때문이다. 따라서 결제 상태는 참가자와 모임 사이의 특정 신청 기록에 속한다. 참석 여부, 신청 시각, 취소 사유도 같은 위치에 둔다.

반대로 이메일은 신청마다 복사하기보다 참가자에 둔다. 다만 신청 시점 연락처를 보존해야 하는 규정이 있다면 연락처 스냅샷을 별도 속성으로 둘 수 있다. 정답은 도형 모양이 아니라 업무에서 어떤 사실을 언제까지 보존해야 하는지에 달려 있다.

도서 대출과 저자 정보에서도 같은 질문을 쓴다

도서관에서는 책 제목이라는 작품과 실제 대출되는 책 한 권을 구분한다. 같은 제목의 책이 세 권이면 작품 정보는 하나지만 소장본ID는 세 개다. 대출은 회원과 소장본을 연결하고 대출일·반납일을 가진다. 작품과 소장본을 섞으면 어느 책이 반납됐는지 알 수 없다.

문서 자료에서는 문서, 작성자, 기관, 인용을 나눌 수 있다. 문서 한 편에 저자가 여러 명이고 저자 한 명이 여러 문서를 쓸 수 있으므로 저작 관계는 다대다다. 저자 순서와 교신 여부는 사람 자체가 아니라 특정 문서와 저자 사이 관계의 속성이다.

LLM에는 업무 규칙과 예외 사례를 준다

“신청 시스템의 ERD를 그려 줘”만으로는 필수 관계나 삭제 규칙을 알 수 없다. 참가자는 신청 없이 가입할 수 있는지, 신청은 취소 뒤에도 보존하는지, 한 모임에 여러 회차가 있는지를 원문 규칙으로 제공해야 한다. 알 수 없는 부분은 질문 목록으로 돌려 달라고 요청한다.

출력에는 개체, 기본키, 속성, 관계, 양쪽 최소·최대 개수, 판단 근거 문장을 포함시킨다. 모델이 임의로 “결제”나 “출석” 개체를 추가하지 않도록 제공된 규칙 밖의 가정을 금지한다. 결과를 받은 뒤에는 정상 사례뿐 아니라 빈 모임, 중복 이메일, 취소 신청 같은 실패 사례도 대입한다.

준비된 예시 결과를 레코드로 시험한다

예시 결과는 참가자(P01), 모임(M10), 신청(A101)을 구분한다. A101은 P01과 M10을 정확히 한 번씩 가리키고 상태 “승인”, 신청시각 “2026-10-01 09:10”을 가진다. P01이 다른 모임 M11에 신청하면 참가자 정보는 복사하지 않고 A102만 추가한다.

이것은 데이터베이스를 실제 실행한 결과가 아니라 구조를 검토하기 위한 준비된 레코드다. 도표가 허용하는 사례를 표로 만들어 보면 카디널리티 오류를 찾기 쉽다. 신청에 참가자ID가 비어 있거나 하나의 신청이 두 모임을 가리키면 규칙 위반으로 판정해야 한다.

잘못된 ERD는 명사를 모두 개체로 만든다

“이름”, “날짜”, “상태”처럼 값을 담는 항목까지 모두 독립 개체로 만들면 관계가 불필요하게 늘어난다. 반대로 참가자와 모임만 두고 신청 상태를 참가자에 붙이면 여러 모임별 상태를 표현할 수 없다. 개체와 속성을 결정할 때 독립 식별과 반복되는 관계를 함께 본다.

수정 전에는 참가자—모임 사이 다대다 선에 결제상태가 어색하게 매달려 있었다. 수정 후에는 신청을 연결 개체로 만들고 신청ID, 상태, 결제상태를 옮겼다. 동시에 “모임 삭제 시 신청 기록을 지울지 보존할지”는 정책 질문으로 남겼다.

도표에서 표 구조로 옮기기 전에 역검사를 한다

각 개체가 고유하게 식별되는지, 속성이 원자적인 값인지, 관계의 양쪽 최소·최대 개수가 실제 규칙과 맞는지 차례로 확인한다. 그다음 실제 사례를 넣어 중복 없이 기록되는지 보고, 금지해야 할 사례가 도표에서 허용되지 않는지도 확인한다.

ERD는 데이터베이스 구현 그 자체가 아니다. 자료형, 색인, 접근 권한, 삭제 정책, 개인정보 보존 같은 결정은 별도 설계가 필요하다. 따라서 “ERD가 완성됐으니 시스템도 완성됐다”고 말하지 않고, 개념 구조를 검토한 단계라고 명시한다.

복사해서 쓸 수 있는 LLM 요청문

아래 요청문은 교육용 예시다. 원문을 함께 제공하고, 모델이 빈칸을 추측하지 않도록 금지 조건을 넣었다. 결과를 받으면 원문 문장과 노드·선의 대응을 사람이 다시 확인한다.

아래 업무 규칙만 사용해 개체 관계도를 설계해 줘.
1. 개체, 기본키, 속성, 관계를 표로 먼저 정리한다.
2. 모든 관계에 양쪽 최소·최대 개수를 적고 업무 문장으로 풀어 쓴다.
3. 다대다 관계에 속성이 있으면 연결 개체가 필요한지 검토한다.
4. 각 판단 옆에 근거가 된 규칙 문장 번호를 적는다.
5. 규칙에 없는 개체·속성·삭제 정책은 추정하지 말고 '결정 필요'로 모은다.
6. 정상 사례 2개와 실패 사례 2개로 구조를 점검한다.

[업무 규칙]
R1: ...
R2: ...

직접 실습하고 결과를 읽기

이 실습은 브라우저 안에 준비한 교육용 자료만 사용한다. 외부 LLM을 호출하거나 실제 기관 자료를 조회하지 않는다. 입력을 바꾸어 결과가 어떻게 달라지는지 보고, 설명과 맞지 않는 결과가 나오면 어떤 정보가 빠졌는지 적어 본다.

자료와 출처

아래 자료는 이번 글의 정의와 표기법을 확인하는 데 사용했다. 생각그림과 사례 문장은 원자료를 복제하지 않고 이 글의 교육 목적에 맞게 새로 구성했다.

• Peter P. Chen, The Entity-Relationship Model—Toward a Unified View of Data (ACM, 1976)
• MIT DSpace, Chen 1976 paper record