SQLD 시험 문제: ERD 관계(Relationship) 분석과 카디널리티

ERD 관계와 카디널리티 완벽 정복하기

SQLD 시험을 준비하거나 데이터베이스 설계를 처음 접하는 분들에게 ERD(Entity Relationship Diagram)는 가장 먼저 넘어야 할 산입니다. 특히 ‘관계(Relationship)’와 ‘카디널리티(Cardinality)’는 데이터 모델링의 핵심이자 실무에서도 데이터의 논리적 흐름을 결정짓는 가장 중요한 요소입니다. 단순히 시험 문제를 풀기 위한 암기를 넘어, 실제 데이터베이스가 어떻게 데이터를 주고받는지 이해하는 깊이 있는 가이드를 준비했습니다.

데이터 모델링에서 관계란 무엇인가

데이터 모델링에서 관계란 두 엔터티(Entity) 사이에 존재하는 논리적인 연관성을 의미합니다. 예를 들어 ‘고객’과 ‘주문’이라는 엔터티가 있다면, 고객은 주문을 할 수 있고 주문은 고객에 의해 생성됩니다. 이처럼 두 대상이 업무적으로 어떤 상호작용을 하는지 정의하는 것이 바로 관계입니다. 관계를 잘 설계해야만 나중에 SQL 쿼리를 작성할 때 JOIN 문을 효율적으로 사용할 수 있고, 데이터의 중복을 방지하며 정합성을 유지할 수 있습니다.

카디널리티의 의미와 유형 이해하기

카디널리티는 한 엔터티의 인스턴스가 다른 엔터티의 인스턴스와 몇 개의 관계를 맺을 수 있는지를 나타내는 수치입니다. 데이터베이스 설계의 꽃이라고 할 수 있는 카디널리티는 크게 세 가지 유형으로 나뉩니다.

• 1대1 (One to One) 관계: 한 엔터티의 인스턴스가 다른 엔터티의 인스턴스 하나와만 관계를 맺는 경우입니다. 예를 들어 ‘사원’과 ‘사원 상세 정보’가 있다면, 한 사원은 하나의 상세 정보만 가질 수 있습니다. 실무에서는 테이블을 굳이 나누지 않고 하나로 합치는 경우가 많지만, 보안상 분리해야 할 때 주로 사용합니다.

• 1대다 (One to Many) 관계: 가장 흔하게 볼 수 있는 유형입니다. 한 명의 ‘고객’은 여러 번의 ‘주문’을 할 수 있지만, 특정 주문 하나는 오직 한 명의 고객에게만 속합니다. 1대다 관계에서는 1 쪽의 기본 키(Primary Key)를 다 쪽의 외래 키(Foreign Key)로 전달하여 연결합니다.
• 다대다 (Many to Many) 관계: ‘학생’과 ‘수강 과목’의 관계를 생각하면 쉽습니다. 한 학생은 여러 과목을 들을 수 있고, 한 과목에는 여러 학생이 수강합니다. 하지만 관계형 데이터베이스(RDBMS)에서는 다대다 관계를 직접 구현할 수 없으므로, 중간에 ‘수강 신청’이라는 연결 엔터티를 두어 1대다 관계로 풀어내는 과정이 반드시 필요합니다.

선택성과 필수성 옵셔널리티의 이해

카디널리티와 함께 반드시 고려해야 할 것이 바로 ‘옵셔널리티(Optionality)’입니다. 이는 관계가 필수적인지 선택적인지를 나타냅니다. 예를 들어 ‘모든 주문은 반드시 고객이 있어야 한다’면 고객과의 관계는 필수(Mandatory)입니다. 반면 ‘신규 고객은 아직 주문을 하지 않았을 수도 있다’면 주문과의 관계는 선택(Optional)입니다. 이 개념은 데이터 설계 시 ‘NULL 값을 허용할 것인가’를 결정하는 중요한 기준이 됩니다.

SQLD 시험 문제 해결을 위한 실전 팁

SQLD 시험에서는 ERD 그림을 보고 관계를 올바르게 해석하거나, 식별자 관계와 비식별자 관계를 구분하는 문제가 자주 출제됩니다. 다음은 문제를 풀 때 바로 적용할 수 있는 전략입니다.

식별자와 비식별자 관계 구분하기

• 식별자 관계: 부모 엔터티의 주식별자가 자식 엔터티의 주식별자로 상속되는 경우입니다. 부모 없이는 자식이 존재할 수 없는 강력한 관계를 의미하며, 실선으로 표시합니다.

• 비식별자 관계: 부모 엔터티의 주식별자가 자식 엔터티의 일반 속성으로 상속되는 경우입니다. 부모가 바뀌더라도 자식의 정체성에는 큰 영향이 없거나, 관계가 필수가 아닐 때 사용하며 점선으로 표시합니다.

시험 문제 풀이 전략

• 주어와 목적어를 바꿔보세요. ‘고객이 주문을 한다’와 ‘주문이 고객에 의해 이루어진다’를 양방향으로 생각하면 관계의 방향성이 명확해집니다.
• 카디널리티 기호(까마귀 발 모양)를 주의 깊게 보세요. 끝이 세 갈래로 갈라진 것은 ‘다(Many)’를 의미하고, 막대기 하나는 ‘1’을 의미합니다.
• 동그라미 기호가 있는지 확인하세요. 관계 선 끝에 작은 동그라미가 있다면 그것은 ‘선택(Optional)’ 관계를 의미합니다.

흔한 오해와 사실 관계

많은 입문자가 데이터 모델링을 할 때 ‘무조건 테이블을 많이 쪼개는 것이 좋은 설계’라고 오해합니다. 하지만 테이블이 너무 많아지면 JOIN 연산이 과도하게 발생하여 시스템 성능이 저하될 수 있습니다. 반대로 테이블을 너무 합치면 데이터 중복이 발생하여 무결성이 깨집니다. 좋은 모델링은 업무의 핵심 규칙을 정확히 반영하면서도, 조회 성능과 데이터 관리 효율성 사이의 균형을 맞추는 것입니다.

또한, 다대다 관계를 무조건 피해야 한다는 오해를 하기도 합니다. 다대다 관계는 논리적인 설계 단계에서는 매우 자연스러운 표현입니다. 이를 물리적으로 구현할 때만 중간 테이블(교차 엔터티)을 활용하여 해소하면 되는 것이지, 설계 단계에서부터 다대다 관계를 원천 차단하려고 고민할 필요는 없습니다.

전문가들이 강조하는 효율적인 모델링 습관

데이터베이스 설계 전문가들은 항상 ‘데이터의 생명주기’를 고민하라고 조언합니다. 어떤 데이터가 먼저 생성되고, 어떤 데이터가 사라지면 다른 데이터에 어떤 영향을 미치는지 시뮬레이션해보는 습관이 중요합니다. 또한, 현실 세계의 복잡한 업무 프로세스를 ERD로 옮길 때는 지나치게 상세한 속성까지 나열하기보다, 엔터티 간의 핵심적인 관계와 카디널리티를 먼저 정의한 뒤 세부 속성을 채워 나가는 ‘Top-Down’ 방식을 추천합니다.

비용 효율적인 활용 방법 측면에서는 모델링 툴을 적극적으로 활용하는 것을 권장합니다. 간단한 ERD는 화이트보드나 종이에 그릴 수 있지만, 복잡한 업무는 버전 관리가 되지 않으면 나중에 수정하기가 매우 어렵습니다. 무료로 제공되는 ERD 도구들을 활용하여 모델을 디지털화하고, 데이터 사전(Data Dictionary)을 함께 관리하면 나중에 SQL 쿼리를 짤 때 불필요한 시간을 획기적으로 줄일 수 있습니다.

자주 묻는 질문과 답변

Q: 1대1 관계는 왜 실무에서 잘 쓰이지 않나요?

A: 1대1 관계는 데이터의 논리적 분류를 위해 사용되지만, 물리적으로는 두 테이블을 조회할 때마다 JOIN이 발생하여 성능상 손해를 볼 수 있습니다. 특별한 사유(보안, 특정 데이터의 빈도수 차이)가 없다면 하나의 테이블로 합치는 것이 관리와 성능 면에서 유리한 경우가 많습니다.

Q: 식별자 관계를 쓰면 무조건 좋은가요?

A: 그렇지 않습니다. 식별자 관계를 과도하게 사용하면 주식별자의 길이가 너무 길어져서 인덱스 성능이 저하될 수 있습니다. 또한, 부모 데이터가 삭제될 때 자식 데이터도 연쇄적으로 영향을 받는 강한 결합이 생기므로, 데이터의 독립성을 고려하여 비식별자 관계를 적절히 섞어 쓰는 것이 좋습니다.

Q: 다대다 관계를 해소할 때 중간 테이블에는 어떤 키를 넣나요?

A: 일반적으로 각 엔터티의 주식별자를 가져와서 복합키(Composite Key)로 사용하거나, 중간 테이블만의 새로운 대리키(Surrogate Key)를 생성하여 사용합니다. 이는 시스템의 성격에 따라 결정되는데, 조회 빈도가 높다면 별도의 대리키를 생성하는 것이 인덱스 관리 측면에서 효율적입니다.

데이터 모델링 역량 강화를 위한 조언

SQLD 시험 합격을 넘어 데이터 전문가로 성장하고 싶다면, 단순히 ERD 그리는 법을 익히는 데 그치지 마세요. 실제 자신이 사용하는 앱이나 웹사이트의 데이터가 어떻게 구성되어 있을지 상상해 보는 것이 가장 좋은 공부입니다. ‘이 서비스는 왜 사용자와 게시물을 1대다로 연결했을까?’, ‘댓글은 왜 별도의 테이블로 분리했을까?’ 같은 질문을 스스로 던져보세요. 이러한 분석적 사고가 쌓이면 ERD는 단순한 시험 과목이 아니라, 데이터를 다루는 강력한 도구가 될 것입니다.

마지막으로, 모델링은 한 번에 완벽하게 할 수 없습니다. 업무 환경은 계속 변하고 데이터 요구사항도 달라지기 때문입니다. 처음부터 완벽한 설계를 하겠다는 강박을 버리고, 핵심 관계를 명확히 정의한 뒤 변화에 유연하게 대응할 수 있는 확장성 있는 구조를 만드는 데 집중하시기 바랍니다. 이 가이드가 여러분의 SQLD 학습과 실무 역량 향상에 실질적인 도움이 되기를 바랍니다.