💡 핵심 인사이트
갱신 이상은 뚱뚱한 비정규화 테이블에서 데이터가 수십 번 낭비되며 '중복' 저장되어 있을 때 발생합니다.
중복된 데이터 중 일부의 값만 수정하고 나머지는 실수로 고치지 못해, DB 내에 "어떤 것이 진짜 팩트인지 알 수 없는 모순(데이터 불일치, Inconsistency)"이 발생하는 치명적 뇌정지 상태를 뜻합니다.

Ⅰ. 갱신 이상을 유발하는 중복 데이터의 함정

다시 그 문제의 뚱뚱한 짬뽕 테이블을 소환해 보겠습니다.

[ 수강 테이블 ] - 기본키: {학번, 과목코드}

김철수가 학구열이 불타서 전공을 3개나 듣고 있습니다. 이 때문에 테이블에는 "김철수는 컴퓨터 학과다"라는 정보가 무려 **3번이나 중복(Redundancy)**되어 저장되어 있습니다. 이 낭비된 중복 데이터가 바로 갱신 이상의 도화선이 됩니다.

Ⅱ. 갱신 이상의 발생 (모순의 탄생)

상황: 김철수 학생이 2학년 2학기에 적성에 안 맞는다며 '컴퓨터' 학과에서 '수학과'로 전과를 싹 했습니다. 학사팀 직원이 DB에 접속해서 UPDATE 쿼리를 날립니다.

재앙의 발생: 직원이 WHERE 과목코드 = 'DB'라는 조건을 잘못 거는 바람에, 첫 번째 행의 학과만 '수학과'로 수정되고, 밑에 있는 OS와 NW를 듣는 2줄의 학과 정보는 옛날 정보인 '컴퓨터'로 그대로 남아버렸습니다.

• 1번째 줄 ➔ 김철수 : 수학과
• 2, 3번째 줄 ➔ 김철수 : 컴퓨터 학과

다음 날 장학금 산정을 위해 DB에 쿼리를 던집니다. "101번 김철수 학생의 학과는 어디입니까?" DB는 멘탈이 붕괴됩니다. **하나의 테이블 안에서 똑같은 김철수가 수학과이기도 하고 컴퓨터 학과이기도 한 끔찍한 논리적 모순(데이터 불일치)**이 발생한 것입니다. DB의 신뢰도는 0%로 추락합니다.

Ⅲ. 원인 분석과 해결책

• 원인: '학과'라는 속성이 학생(학번)에게만 종속되어야 하는데, 과목 정보와 섞여 들어가 여러 번 흩어져 저장되었기 때문입니다. 데이터는 무조건 한 곳(단일 진실 공급원)에만 있어야 수정할 때 실수가 없습니다.
• 해결책 (정규화): 테이블을 찢어버립니다. [학생 테이블]에 (학번, 이름, 학과)를 단 한 번, 1줄만 적어둡니다. 나중에 철수가 전과하면, 오직 이 [학생 테이블]에 있는 단 1칸의 '컴퓨터'를 '수학'으로 한 번만 딱 고치면 됩니다. 나머지 [수강 테이블]은 학번(FK)만 들고 있으므로 전과 사실을 신경 쓸 필요도 없이 무결성이 완벽히 유지됩니다.

📢 섹션 요약 비유: 갱신 이상은 회사 직원의 이메일 주소를 인사팀 엑셀, 영업팀 엑셀, 총무팀 엑셀에 각각 3번 따로 복사해서 관리하는 아날로그식 행정의 비극입니다. 직원이 이메일을 바꿨을 때 총무팀 엑셀만 깜빡하고 수정을 안 하면, 나중에 "이 직원 진짜 이메일이 뭐야?"라며 세 부서가 멱살을 잡고 싸우게 되는 끔찍한 모순(불일치) 상태입니다.