💡 핵심 인사이트
데이터베이스 정규화에서 뚱뚱한 릴레이션(테이블)을 여러 개로 찢을 때 지켜야 할 두 번째 법칙입니다.
쪼개기 전 원본 테이블에 존재했던 "학번이 학과를 결정한다($X \rightarrow Y$)" 같은 중요한 업무적 규칙(함수적 종속성)들이, 테이블이 쪼개진 후에도 공중분해 되지 않고 쪼개진 파편(새 테이블)들 중 적어도 하나 안에는 온전히 살아남아 유지되어야 한다는 제약입니다.

Ⅰ. 종속성 보존의 의미 (규칙의 소실 방지)

어떤 테이블 $R(A, B, C)$가 있고, 비즈니스 룰상 $A \rightarrow B$ (A를 알면 B를 안다)와 $B \rightarrow C$ (B를 알면 C를 안다)라는 함수적 종속성(FD)이 존재한다고 칩시다.

이 테이블이 너무 뚱뚱해서 찢기로 했습니다.

• [ 나쁜 찢기 ]: $R_1(A, B)$ 와 $R_2(A, C)$ 로 찢었습니다.

  • $R_1$ 안에는 $A \rightarrow B$ 라는 룰을 검사할 수 있는 A와 B 컬럼이 같이 붙어있으니 규칙이 보존되었습니다.
  • 그런데 $R_2$ 에는 A와 C만 있습니다. 원래 있던 그 중요한 **$B \rightarrow C$ 라는 룰은 $R_1$에도 없고 $R_2$에도 없어 완전히 허공으로 증발(소실)**해 버렸습니다!
  • 나중에 누군가 B와 C의 관계를 어기는 쓰레기 데이터를 INSERT 하려 해도, 이 룰을 검사해 줄 테이블이 찢어져 날아갔기 때문에 DB가 에러를 뿜지 못하고 쓰레기 데이터를 허용해 버립니다.

• [ 좋은 찢기 (종속성 보존) ]: $R_1(A, B)$ 와 $R_2(B, C)$ 로 찢습니다.

  • $R_1$에서 $A \rightarrow B$ 룰을 감시하고, $R_2$에서 $B \rightarrow C$ 룰을 완벽히 감시할 수 있습니다. 이것이 종속성 보존입니다.

Ⅱ. 무손실 분해와의 관계 (가혹한 현실의 트레이드오프)

앞 장에서 배운 "다시 합치면 100% 찰흙처럼 원본이 되는가?"인 무손실 분해와 이 종속성 보존은 둘 다 100점 만점으로 달성하기가 생각보다 까다롭습니다.

• 제1, 제2, 제3 정규형 (3NF까지): 테이블을 찢을 때, 천재 수학자들이 만든 공식대로만 찢으면 '무손실 분해'와 '종속성 보존' 두 마리 토끼를 100% 무조건 다 잡을 수 있습니다. 그래서 3NF가 실무의 황금 기준입니다.
• BCNF (보이스-코드 정규형): 하지만 3NF보다 더 빡빡한 BCNF 수준으로 찢으려다 보면, 수학적으로 딜레마에 빠집니다. 무손실 분해를 만족시키면서 찢으려니, 어쩔 수 없이 일부 종속성(규칙)이 희생(소실)되는 경우가 간혹 발생합니다.
• 결론 (DB 설계의 철칙): 무손실 분해는 하늘이 두 쪽 나도 "무조건 보장"되어야 하는 0순위 절대 법칙입니다. (데이터가 뻥튀기되면 DB가 멸망함). 반면, 종속성 보존은 "최대한 지키면 좋지만, BCNF 이상에서 어쩔 수 없다면 눈물을 머금고 포기할 수도 있는(선택적)" 1순위 법칙입니다. (소실된 규칙은 나중에 DB 트리거나 애플리케이션 Java 코드단에서 별도로 땜질하여 막습니다.)

📢 섹션 요약 비유: 종속성 보존은 헌법이 쓰인 **'거대한 석판 쪼개기'**입니다. 석판(테이블)에 "1항: 살인 금지, 2항: 도둑질 금지"라는 두 개의 룰(종속성)이 새겨져 있는데, 판이 너무 무거워 두 개로 깨야 합니다. 깰 때 실수로 글자 한가운데를 내리쳐서 "도둑질 금지"라는 글씨가 반으로 갈라져(소실) 읽을 수 없게 되면 아무도 도둑질을 처벌(에러 검출)할 수 없습니다. 글자가 훼손되지 않게 조심해서 조각 안에 온전한 문장이 남도록 자르는 것이 종속성 보존 설계입니다.