목차
데이터 베이스에서 데이터의 중복으로 인해 릴레이션에 대한 삽입, 갱신, 삭제시 발생하는 비합리적인 현상인 Anomaly 즉 이상현상에 대해 알아보겠습니다.
Anomaly는 정규화가 제대로 구현된 DB에서는 발생하지 않습니다. 가장 흔하게 발생하는 이유는 여러 종류의 릴레이션을 하나의 DB에 표현하려다 발생합니다. 이런 Anomaly 현상이 발생하면 정규화를 실행해야 합니다. 그럼 예시를 통해 알아보도록 하겠습니다.
사번 | 부서코드 | 부서명 |
100 | A10 | 기획부 |
200 | A20 | 인사부 |
300 | A30 | 영업부 |
400 | A10 | 기획부 |
다음과 같은 부서 DB가 있습니다. 각각의 사원에 대해서 사번과 해당 사원의 부서에 대한 정보가 DB에 저장되어 있습니다. 그럼 이 데이터베이스에 삽입, 갱신, 삭제시 발생하는 Anomaly에 대해 알아보겠습니다.
삽입 이상(Insertion Anomaly)
삽입이상은 DB에 데이터를 삽입해야 하는데 원하지 않는 불필요한 정보까지도 삽입해야 하는 경우 발생합니다. 위에 그림에서 신입사원을 삽입해야 합니다. 이 때 아직 부서가 정해지지 않아서 부서코드와 부서명을 추가할 필요가 없는데도 이 정보를 추가해야 하는 경우 발생합니다.
사번 | 부서코드 | 부서명 |
500 | Null | Null |
이렇게 500번의 신입사원을 추가하면서 부서코드, 부서명이 아직 정해지지 않아 부득이 Null로 추가해야 하는 이상현상이 발생하고, 만약 이 두 필드가 PK라면 Null값을 넣을 수 없어 잘못된 정보를 추가해야 합니다.
갱신 이상(Update Anomaly)
갱신 이상은 중복 저장된 속성을 바꿀 때 하나만 갱신하고 나머지는 갱신하지 않아서 발생합니다. 위의 표에서 100번과 400번의 부서가 기획부로 같습니다. 이 때 100번 사원의 부서명인 기획부를 미래 기획부로 변경 하기로 하였습니다. 100번 뿐만 아니라 모든 부서코드 A10의 부서명을 미래 기획부로 변경해야 하는데 미처 400번을 바꾸지 않았을 때 발생합니다.
사번 | 부서코드 | 부서명 |
100 | A10 | 미래 기획부 |
400 | A10 | 기획부 |
이와 같이 100번의 부서명을 변경하였는데 부서코드에 대한 부서명의 불일치가 발생하면서 모순이 발생하는 것을 갱신 이상이라고 합니다.
삭제 이상(Deletion Anomaly)
삭제이상은 특정 필드를 삭제할 경우 원하지 않는 정보까지 삭제되는 현상을 말합니다. 위 표에서 300번의 사원이 퇴사하여 해당 사원의 정보를 삭제해야 합니다. 이 때 300의 부서코드 A30인 영업부의 정보도 사라지는 경우를 말합니다.
사번 | 부서코드 | 부서명 |
Anomaly 해결방안
위와 같은 이상현상이 발생하였을 때 정규화를 통해 문제를 해결할 수 있습니다. 사원 정보와 부서정보를 따로 나누면 문제가 해결 됩니다. 이렇게 중복 속성을 분리하는 것을 1차 정규화라고 하며 정규화에 대해서는 따로 다루도록 하겠습니다.
사원 테이블
사번 | 부서코드 |
100 | A10 |
200 | A20 |
300 | A30 |
400 | A10 |
부서 테이블
부서코드 | 부서명 |
A10 | 기획부 |
A20 | 인사부 |
A30 | 영업부 |
이렇게 사원과 부서정보를 따로 나누면 사원 정보를 삽입 하더라도 불핑요한 부서명을 추가적으로 넣을 필요가 없습니다. 또한 사원이 부서를 옮기거나, 부서명이 변경되어도 불일치가 발생하지 않습니다. 마지막으로 사원이 퇴사하여 사원에서 삭제되더라도 부서 정보에 영향을 주지 않습니다.
'IT 지식 > 데이터베이스' 카테고리의 다른 글
CAP 이론 (0) | 2023.12.14 |
---|---|
NoSQL(Not Only SQL) (0) | 2023.12.13 |
LOD(Linked Open Data) (0) | 2023.12.12 |
데이터베이스 정규화 (0) | 2023.12.10 |
데이터 베이스의 고립화 단계(Isolation Level) (0) | 2023.12.06 |