RDBMS의 테이블을 생성하고, 각 테이블마다 관계를 설정해 줄 때 일반적으로 외래 키를 사용하곤 합니다. 외래 키를 통해 다른 테이블과 같은 키를 공유하고 이를 이용하여 조인하여 관계를 이용하는 방식을 사용합니다. 외래 키를 사용하여 테이블 간 관계를 정립해 줄 때 사용하는 전략은 크게 식별 관계, 비식별 관계 전략이 있습니다.
식별 관계
식별 관계란, 부모 테이블의 기본키 또는 유니크 키를 자식 테이블이 자신의 기본키로 사용하는 관계입니다. 부모 테이블의 키가 자신의 기본키에 포함되기 때문에 반드시 부모 테이블에 데이터가 존재해야 자식 테이블에 데이터를 입력할 수 있습니다. 즉, 부모 데이터가 없다면 자식 데이터는 생길 수 없습니다.
식별관계는 ERD상에서 실선으로 표시합니다. 자식 테이블에 데이터가 존재한다면 부모 데이터가 반드시 존재하는 상태가 됩니다. 바퀴는 자동차 테이블에 데이터가 존재해야 생성할 수 있습니다. 즉, 부모 테이블에 자식 테이블이 종속됩니다.
비식별 관계
비 식별 관계란 부모 테이블의 기본키 또는 유니크 키를 자신의 기본키로 사용하지 않고, 외래 키로 사용하는 관계입니다. 자식 데이터는 부모 데이터가 없어도 독립적으로 생성될 수 있습니다. 부모와의 의존성을 줄일 수 있기 때문에 조금 더 자유로운 데이터 생성과 수정이 가능합니다.
각각의 전략으로 테이블을 구성할 경우
식별관계의 경우 자식 데이터를 넣기 전, 부모 테이블에 필수적으로 데이터가 존재해야 합니다. 또한 기본키를 여러 복합 자연 키로 처리하기 때문에 입력할 수 있는 데이터에 제한을 걸 수 있습니다.
예를 들어, 4륜 자동차를 생성하려고 한다면 식별 관계에서는 다음과 같이 데이터를 넣을 수 있습니다.
우선 만들고자 하는 자동차의 데이터를 입력합니다.
| 자동차_아이디(PK) | 이름 | 가격 |
| 12345 | 4륜차 | 10000 |
바퀴의 데이터를 다음과 같이 입력할 수 있겠네요. 바퀴 데이터는 아래 3개의 키가 묶여 복합 기본키를 가집니다.
| 자동차_아이디(PK, FK) | 바퀴_위치(PK) |
| 12345 | "FRONT_LEFT" |
| 12345 | "FRONT_RIGHT" |
| 12345 | "BACK_LEFT" |
| 12345 | "BACK_RIGHT" |
개발자가 왼쪽 앞바퀴를 추가적으로 입력하려고 하면 어떻게 될까요? PK는 중복해서 존재할 수 없습니다. 그렇기 때문에 개발자의 실수로 데이터를 DB에 입력하려 해도 데이터 입력 자체가 불가능해집니다. 즉 데이터 정합성을 DB에서도 체크할 수 있게 됩니다.
식별 관계는 요구사항이 변하지 않을 때 강력한 데이터 정합성을 보장할 수 있습니다. 반대로, 요구사항이 변경되었을 때는 개발자의 발목을 끝없이 잡을 수 있습니다. 예를 들어, 말도 안 되는 일이지만 앞쪽, 왼쪽 바퀴를 1개가 아닌 3개 이상을 허용해야 한다고 요구사항이 변경된다면 어떻게 될까요?
이미 FRONT_LEFT 위치에는 데이터가 입력되어있습니다. 이곳에 데이터를 넣기 위해서는 바퀴 위치 공통 코드를 변경하거나 테이블의 데이터와 구조를 모두 변경해야 하는 불상사가 발생합니다. 데이터 정합성을 지키기 위해 진행한 식별 관계는 유동적인 요구사항을 수용하기 어렵게 만들기도 합니다.
그렇기 때문에 테이블 설계 시 비식별 관계로 테이블을 설계하는 것을 권장합니다. 비 식별 관계로 테이블을 설계한다면 아래와 같이 데이터를 입력할 수 있습니다.
| 바퀴_아이디 (PK) | 자동차_아이디 (FK) | 바퀴_위치 |
| 11111 | 12345 | "FRONT_LEFT" |
| 11112 | 12345 | "FRONT_LEFT" |
| 11113 | 12345 | "FRONT_LEFT" |
| 11114 | 12345 | "FRONT_RIGHT" |
비식별 관계에서는 자동차를 만들기 전, 바퀴 데이터를 먼저 입력해야 한다고 요구사항이 변경되었을 때도 수용이 가능합니다. 자신만이 가지고 있는 인조 키인 "바퀴_아이디"를 가지고 있기 때문에 부모 테이블과 종속적인 관계없이 독립적으로 존재할 수 있기 때문입니다.
| 바퀴_아이디 | 자동차_아이디 (FK) | 바퀴_위치 |
| 11115 | null | null |
| 11116 | null | null |
이후 바퀴가 달릴 자동차가 정해진다면 데이터를 업데이트시키기만 하면 됩니다.
장단점
식별 관계의 장점
- 데이터의 정합성 유지를 DB에서 한번 더 할 수 있다
- 자식 테이블에 데이터가 존재한다면 부모 데이터도 반드시 존재한다고 보장할 수 있다
식별 관계의 단점
- 요구사항이 변경되었을 경우 구조 변경이 어렵다
비식별 관계의 장점
- 변경되는 요구사항을 유동적으로 수용할 수 있다
- 부모 데이터와 독립적인 자식 데이터를 생성할 수 있다
비식별 관계의 단점
- 데이터 정합성을 지키기 위해서는 별도의 비즈니스 로직이 필요하다.
- 자식 데이터가 존재해도 부모 데이터가 존재하지 않을 수 있다
- 즉, 데이터 무결성을 보장하지 않는다
'Database' 카테고리의 다른 글
| [DB] 분산 시스템을 선택하는 삼각형, CAP 이론 (0) | 2020.03.19 |
|---|---|
| [MySQL] 트랜잭션의 격리 수준(isolation level) (0) | 2020.03.01 |
댓글