💡 핵심 인사이트
삭제 이상은 데이터베이스의 테이블(릴레이션)을 뚱뚱하게 잘못 설계했을 때 발생하는 치명적인 에러로, **"내가 지우고 싶은 데이터 한 줄을 지웠을 뿐인데, 테이블 구조의 결함 때문에 '전혀 지울 의도가 없었던 핵심 정보'까지 연쇄적으로 허공으로 날아가 버리는 데이터 유실 현상"**을 말합니다.

Ⅰ. 삭제 이상이 발생하는 뚱뚱한 테이블 (비정규화 상태)

하나의 테이블 안에 두 가지 완전히 다른 주제(예: 학생 정보와 수강 정보)를 짬뽕시켜 놓았을 때 발생합니다.

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

Ⅱ. 삭제 이상의 폭발 (사건의 재구성)

상황: '경영학과' 소속의 102번 이영희 학생이 '회계학(ACC)' 과목이 너무 어려워서 수강 철회(Drop)를 요청했습니다. DB 관리자는 "알겠습니다, 수강 내역 지워드릴게요"라며 테이블에서 102번 행(Row) 하나를 가차 없이 DELETE 합니다.

재앙의 발생: 관리자는 단지 '회계학 수강 사실'이라는 연결 고리만 지우고 싶었습니다. 하지만 행 단위로 지워지는 관계형 DB의 특성상, 그 한 줄이 통째로 날아가면서 "102번 학생의 이름은 이영희이고, 경영학과 소속이다"라는 이영희의 학교 '기본 신상 정보'마저 세상에서 영구적으로 소멸되어 버립니다. 다음 날 교무처에서 경영학과 학생 명단을 뽑아보면 이영희는 흔적도 없이 사라진 유령 학생이 되어버립니다.

Ⅲ. 원인 분석과 해결책 (정규화)

• 원인: 본질적으로 다른 성격의 데이터인 '학생 개체(학번, 이름, 학과)'와 '수강 행위(학번, 과목코드)'가 하나의 묶음(테이블)으로 억지로 묶여 있었기 때문입니다. 이들을 지탱하는 밧줄을 하나 끊었더니 엉뚱한 사람까지 낭떠러지로 같이 추락한 것입니다.
• 해결책 (무손실 분해): 외과 수술(정규화)을 통해 두 개의 테이블로 깔끔하게 찢어놓아야 합니다.
  1. 학생 테이블: (학번, 이름, 학과) ➔ 이영희의 신상 정보가 안전하게 영구 보관됨.
  2. 수강 테이블: (학번, 과목코드) ➔ 여기서 이영희(102)의 회계학(ACC) 행을 지워도, 1번 학생 테이블의 이영희 정보는 전혀 타격받지 않고 무사히 살아남습니다.

📢 섹션 요약 비유: 삭제 이상은 도서관의 '대출 장부'에 손님의 '집 주소와 전화번호'를 같이 적어놓는 멍청한 관리법입니다. 손님이 책을 반납해서 장부에서 그 대출 기록 한 줄을 화이트로 지워버리는 순간, 애먼 손님의 소중한 연락처(회원 정보)까지 영영 지워져 버려 다음번에 그 손님이 오면 처음부터 다시 회원가입을 받아야 하는 바보 같은 상황입니다. 회원 장부와 대출 장부(정규화)는 반드시 따로 분리해야 합니다.