DB/일반

[DB] 다대다 관계의 문제점과 해결

  • -
반응형

이번 포스트에서는 다대다 관계의 문제점과 해결 방법에 대해서 살펴보자.

 

다대다 관계



다대다 관계의 예

DB 모델링 과정에서 다대다 관계가 나올 수 있다.

쉽게 생각할 수 있는 관계로는 학생과 과목의 관계를 들 수 있다.

학생은 학번, 이름, 학과에 대한 정보를 갖는다. 당연히 학번이 각각의 학생을 구별하는 P.K가 된다.

 

학과는 과목코드, 과목명, 담당교수를 갖는다. 여기서는 과목코드가 각 과목을 구별하는 P.K가 된다.

 

이 두 테이블의 관계를 보면 학생은 여러 과목을 수강할 수 있고 한 과목은 여러 학생이 수강할 수 있다. 따라서 두 테이블은 서로 관계를 가져야 한다.

만약 홍길동이 S1, S2를 수강하고 장길산은 S2와 S3를 수강했다고 생각해보자.

학생 테이블에서 학생의 수강 정보를 확인하기 위해서는 학생이 수강한 과목에 대한 정보가 필요하다. 또한 과목의 입장에서 과목의 수강생 정보를 관리하기 위해서는 수강 학생의 학번 정보가 유지 되어야 한다. 그럼 테이블은 아래와 같이 구성된다.

 

문제점

위와같이 구성된 다대다 관계에는 어떤 문제가 있을까?

  • 테이블의 PK가 없어져버렸다. 학생 테이블에서는 학번만으로 데이터를 구분할 수 없어졌다. 과연 학번+과목코드의 조합키가 학생 데이터를 구별하는 데이터일까? S1과목을 수강한 1번 학생과 S2를 수강한 1번 학생은 다른가? 과목 테이블 역시 마찬가지이다.
  • 1번 학생의 수강 과목을 확인하기 위해서 학생 테이블을 확인해야할까? 아니면 과목 테이블을 확인해야할까? 데이터가 중복되다 보니 학생에서도 가능하고 과목에서도 가능해져서 애매한 상황이 발생한다.
  • 만약 홍길동이 전과를 해서 수학과로 학과를 변경해야 한다면 어떻게 될까? 학생 테이블에서 현재는 2군데의 데이터를 수정해야 한다. 여러 과목을 수강했다면 더욱 많은 데이터를 수정해야 한다.

 

그래서 대책은?

그래서 대첵은 N:M 관계를 각각 1:N, 1:M으로 풀어줄 수 있는 연관 테이블을 추가해주는 것이다.

반응형

'DB > 일반' 카테고리의 다른 글

[index] index 성능 확인  (0) 2023.10.12
[Transaction] 02. Transaction Isolation Level  (0) 2023.10.11
[Transaction] 01. Transaction  (0) 2023.10.10
[subquery] order by 절에서의 sub query  (1) 2023.04.13
[h2]설정  (0) 2022.11.05
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.