이상현상이란?
DB에서 이상현상이란 테이블 설계를 적절하게 하지 못한 경우 야기할 수 있는 문제들을 의미합니다.
관계형 데이터베이스는 릴레이션 간 관계를 설정함으로써 데이터의 무결성을 지키고 중복된 데이터들이 나오지 않도록 합니다. 하지만 어떤 서비스를 만들기 위해서 DB 설계 도중 잘못된 설계를 하여 이러한 부분이 깨지게 될 경우 3가지 정도 부분에서 문제가 일어나게 됩니다.
1. 데이터 삽입 시 문제가 발생하는 삽입 이상 (Insertion Anomaly)
2. 데이터 수정 시 문제가 발생하는 갱신 이상 (Update Anomaly)
3. 데이터 삭제 시 문제가 발생하는 삭제 이상 (Deletion Anomaly)
이제 차례대로 해당 이상현상들에 대해서 살펴보겠습니다.
우선, 이해를 빠르게 하기 위하여 예시 테이블을 하나 만들겠습니다.
해당 테이블은 사원 정보와 부서 정보를 함께 담고 있는 테이블 (이하 A) 입니다.
우선 삽입 이상부터 알아봅시다 !
삽입 이상 (Insertion Anomaly)
삽입 이상은 데이터 삽입 시 데이터 중복, 불필요한 데이터를 추가해야 하는 현상을 말합니다.
방금 보여드린 A 테이블에 새로운 사원정보를 추가해보겠습니다.
MESSI와 동일한 부서에 새로운 사원이 들어왔습니다.
해당 부서의 id는 1번이고 name은 DEV, 해당 부서의 리더는 MESSI 이므로 leader id는 1번입니다.
여기서 문제는 부서 정보입니다. 해당 부분을 보면 동일한 데이터가 중복으로 들어가 있습니다. 지금은 두 건 뿐이지만 데이터가 많아질경우 저장공간을 낭비한다는 단점이 있습니다.
만약 아직 부서가 배치되지 않은 사원이 추가될 경우는 어떻게 저장해야 할까요? 남은 부분을 null로 전부 처리해야 할껍니다.
JENNY 사원이 추가 됐습니다.
하지만 부서가 아직 배치되지 않았기 때문에 부서 정보 부분은 전부 null 처리가 되어있는걸 볼 수 있습니다.
null 값이 많아지면 왜 안좋을까요? 그 부분은 뒤에서 좀 더 살펴보겠습니다.
결국 삽입 이상은 데이터가 삽입 될 때, 중복된 데이터가 발생하고 불필요한 값을 넣어야지만 데이터를 생성할 수 있는 현상을 말합니다.
갱신 이상 (Update Anomaly)
갱신 이상은 데이터 수정 시 데이터 불일치가 발생해 데이터의 무결성이 깨지는 문제를 말합니다.
이번에는 사원을 좀 더 추가해서 살펴보겠습니다.
이번에는 개발, QA 총 2개의 부서가 있습니다.
개발 인원이 부족해 QA 부서가 폐지 되고 전부 DEV 부서로 합쳐졌다고 가정해봅시다. 그렇다면 QA 부서였던 직원들의 부서 정보를 전부 바꿔줘야 합니다.
하지만 사람이라면 실수를 하기 마련인데 만약 오타가 나거나 잘못된 정보로 수정을 하면 어떻게 될까요?
빨간색으로 표시된 부분이 잘못 수정된 곳 입니다.
수정자가 착각을 하여 DEV라고 수정해야 하는 것을 DEVELOP 이라고 수정을 하게 되면 데이터가 불일치하게 되는 모순이 생기게 됩니다.
이는 데이터 무결성을 깨트리게 됩니다.
이러한 데이터 불일치가 발생하는 현상을 갱신 이상 이라고 합니다.
삭제 이상 (Deletion Anomaly)
삭제 이상은 데이터 삭제 시 필요한 데이터까지 함께 삭제되는 현상을 말합니다.
이번에는 QA 부서에 한명만 있다고 가정하겠습니다.
QA 부서에 YUJIN 혼자 있습니다.
YUJIN이 이직을 하여 퇴사를 하게 되어 DB에서 데이터를 삭제를 했습니다.
다음번에 들어올 후임을 위해서 기존에 있던 QA 부서 정보를 확인하려니 YUJIN의 데이터를 삭제할 때 같이 날아갔습니다.
QA 부서 정보를 여차저차해서 기존 로그를 통해 알아냈다고 합시다.
아직 새로운 사원이 입사하지 않았지만 어쨌든 QA 정보를 사용해야 하기 때문에 사원 정보를 제외하고 QA 정보만 입력합니다.
이 때 다시 불필요한 null 값이 들어가게 됩니다.
보시다시피 부서 정보만을 위해서 다른 애트리뷰트의 값들을 null로 전부 채우면서 부서 정보를 추가했습니다.
이처럼 필요한 정보까지 같이 삭제되어 발생하는 이상 현상을 삭제 이상이라고 합니다.
그렇다면 아까 언급한 null 값이 많으면 안좋은 이유는 무엇일까요?
null 값이 많으면 좋지 않은 이유
만약 null 값이 존재하는 컬럼으로 JOIN을 하는 경우 예상과 다른 결과가 발생할 수 있습니다.
또한 null 값이 있는 컬럼에 aggregate function (ex. count, avg)을 사용하는 경우 null 값을 무시하기 때문에 전체 데이터 대상으로 한 계산결과가 실제와 다를 수 있습니다.
그리고 불필요한 storage 낭비가 생길 수 있습니다.
해결 방법
그럼 이상 현상이 발생하게 되는 설계에서 어떻게 해야 문제를 해결할 수 있을까요?
해결 키워드는 '정규화' 입니다. 다음 게시글 에서는 정규화의 개념과 해결방법에 대해 살펴보겠습니다.
참고
DB 테이블 설계 잘못하면 어떤 문제가 생길 수 있을까요? (youtube.com)
'Dev > DB' 카테고리의 다른 글
| 트랜잭션과 격리수준 (1) | 2024.02.08 |
|---|---|
| 디스크 읽기 방식과 쿼리 성능 개선 (1) | 2024.01.25 |
| SQL 처리 과정 (0) | 2024.01.18 |
