[하루 1 CS] 데이터베이스 3 - 테이블의 연관 관계

데이터베이스 3번째 포스트이다. 이번에는 RDB에서의 테이블 간의 연관 관계를 짧게 정리해보겠다.

데이터베이스의 연관 관계란?

데이터베이스에서 테이블 간의 데이터는 서로에게 연관된 정보를 품고 종속될 수 있다. 이러한 테이블 간의 관계를 릴레이션(Relation)이라고 하고, 연관 관계, 관계, 연관 등 다양하게 표현할 수 있다.

데이터베이스의 연관 관계는 크게 세가지로 분류된다.

1. 1:1
2. 1:N
3. N:1
4. N:M

하나씩 살펴보자.

1. 1:1 관계

1:1 관계는 가장 간단한 관계이다. 하나의 레코드가 다른 테이블의 하나의 레코드와 연관 관계를 갖는다는 것을 의미한다.

쉽게 예시를 보면서 이해해보자.

 

[책] 테이블

제목	저자
채식주의자	한강
해리포터	J.K 롤링
그리고 아무도 없었다	애거서 크리스티

[저자] 테이블

저자	국적
한강	대한민국
J.K 롤링	영국
애거서 크리스티	영국

간단한 도서 데이터베이스 내부의 두 테이블이라고 생각하자. [책] 테이블과 [저자] 테이블에는 공통적으로 (저자) 속성을 연관 관계의 외래키로 사용하고 있다. 이 때 각 테이블에서 (저자)라는 속성을 어떻게 보유하는지 살펴보자.

• [책] 테이블 - 책 한 권에 고유한 저자 1명
• [저자] 테이블 - 저자 한 명에 고유한 국적 1개

이렇게 한 테이블 별로 하나의 (저자)에 대해서 1개의 관계를 갖게 되면 1:1 관계이다.

눈치 빠른 사람들은 여기서 하나의 함정이 있다는 것을 알아차릴 것이다. 왜냐하면 1명의 저자가 1권의 책만 출판한다는 가정이 없기 때문이다. 여기에 이어서 개념을 확장해보겠다.

2. 1:N, N:1 관계

1:N과 N:1은 묶어서 설명하도록 하겠다. 결국 어떤 테이블을 기준으로 보느냐에 따른 '관점의 차이'이기 때문에, 하나의 개념만 확실히 알면 된다.

위의 도서 데이터베이스 예제를 이어서 살펴보자.

[책] 테이블

제목	저자
채식주의자	한강
해리포터	J.K 롤링
그리고 아무도 없었다	애거서 크리스티
오리엔트 특급 살인	애거서 크리스티

[저자] 테이블

저자	국적
한강	대한민국
J.K 롤링	영국
애거서 크리스티	영국

이번에는 [책] 테이블에 애거서 크리스티의 책(오리엔트 특급 살인)이 한 권 더 추가되었다. 이제 단순한 1:1 매칭이 아니라, 외래키(저자)를 기준으로 테이블 간에 1:N(또는 N:1) 관계가 성립한다.

두 테이블의 관계를 관점별로 풀어서 해석해 보면 다음과 같다.

• [저자] 테이블 관점 (1 : N)
  • 한 명의 저자가 여러 권의 다른 책(N)들을 가질 수 있다.
  • 예시: '애거서 크리스티'라는 한 명의 데이터가 [책] 테이블의 레코드 2개와 매칭됨.
• [책] 테이블 관점 (N : 1)
  • [책] 테이블에 있는 여러 권의 책(N)들은 각각 한 명의 고유한 저자(1)에게 종속된다.

결국 1:N과 N:1은 외래키를 기준으로 어떤 테이블을 중심으로 생각하느냐에 따라 이름만 바뀔 뿐 본질은 같다. 실제 관계형 데이터베이스(RDB)를 설계할 때 가장 많이 쓰이는 형태이므로 반드시 숙지해두어야 한다.

3. N:M

마지막으로 N:M 관계이다. N:M 관계는 조금 특별하다. 일반적인 테이블 2개로는 성립할 수 없고, 중간 다리 역할을 하는 연관 테이블 (Relation Table/Entity)이 필요하기 때문이다. 이번에도 도서 테이블을 예시로 들어보겠다.

 

[책] 테이블

제목	저자
채식주의자	한강
해리포터	J.K 롤링
그리고 아무도 없었다	애거서 크리스티
오리엔트 특급 살인	애거서 크리스티

 

[유저] 테이블

이름	성별
코디	남
엘리	여

 

[대여] 연관 테이블

이름	제목	대여일	반납일
코디	해리포터	06월 15일	06월 17일
코디	그리고 아무도 없었다	06월 15일	NULL
엘리	채식주의자	05월 19일	05월 24일
엘리	그리고 아무도 없었다	05월 25일	06월 01일

이번에는 [유저] 테이블과 [대여] 테이블이 추가되었다. 여태 했던거랑 비슷하게 관점 별로 분석해보겠다.

우선 큰 로직부터 생각해보아야 한다. [유저]는 여러 권의 [책]을 대여할 수 있고, 여러 권의 [책]도 여러 [유저]에게 대여될 수 있다.

• [유저] 테이블 - 한 유저는 여러 책을 대여할 수 있다.
• [책] 테이블 - 한 책은 여러 유저에게 대여할 수 있다.

음... 여기까지 봤을 때는 연관 테이블의 필요성을 느끼지 않을 수도 있다. 하지만 연관 테이블 없이는 관계형 데이터베이스의 중요한 요소 중 하나인 제 1정규형(1NF)을 위배하게 된다. 정규화에 대해서는 나중에 살펴보도록 하겠지만, 여기에서는 제 1정규형의 개념만 살펴보도록 하겠다. 만약 [책] 테이블이 이렇게 되어있다고 가정해보자.

제목	저자	빌린 사람
채식주의자	한강	NULL
해리포터	J.K 롤링	코디
그리고 아무도 없었다	애거서 크리스티	코디, 엘리
오리엔트 특급 살인	애거서 크리스티	NULL

위 테이블은 (빌린 사람)이라는 요소에 여러 개의 값 (Value)들이 들어있다. 그러나 이러한 형태의 레코드는 바람직하지 않다. 책이 대여될 때마다 빌린 사람이 바뀌어야 하고, 비즈니스 로직상 대여할 때마다, 반납할 때마다 값이 존재할 수도 없을 수도 있다. 이처럼 하나의 속성의 여러 값이 들어있으면, 제1정규형을 어기게 된다. 데이터 무결성이 깨지는 로직이므로 중간다리 역할을 할 연관 테이블이 필요하다.

연관 테이블은 각각의 테이블의 외래키 역할을 하는 속성을 들고, 부가적인 속성을 추가하여 정보를 더할 수 있다. 위의 예시에서는 (제목), (이름)을 [책]과 [유저] 테이블에서 가져오고, 대여일과 반납일을 추가로 기록할 수 있다. 데이터 무결성을 지키면서도 효과적으로 유저의 활동을 관리할 수 있다.

 

마무리

관계형 데이터베이스의 연관 관계는 데이터를 효율적으로 처리하고 무결성을 지키는 데에 필수적이다. 따라서 데이터베이스를 설계하는 단계에서부터 서비스의 비즈니스 로직을 반영할 수 있도록 논리적으로 잘 맞물릴 수 있도록 주의해야 한다. 의외로 프로젝트를 진행하다보면 잘못 설계된 데이터베이스로 인해 데이터베이스 수정 작업을 해야 할 일이 생긴다. 그런 상황이 발생하면 수정해야 하는 코드도 많아지고, 인프라 전반적인 로직 베이스가 흔들릴 수도 있으므로 데이터베이스를 다룰 때 가장 많이 신경써야 하는 부분이 바로 설계 작업이다. 내일은 데이터베이스의 설계 단계를 알아보도록 하겠다.