Anomaly를 직역하면 '변칙'이라는 뜻을 갖는다.
데이터베이스에서 Anomaly는 데이터의 modification
이 이루어 질 때 데이터베이스를 설계하거나 사용하는 사람의 의도대로 동작이 이루어지지 않는 것으로 이해했다. (컴파일러 개념의 semantic error
와 같은 것,,,!)
데이터베이스는 그 규모가 방대할 수록 이러한 Anomaly가 발생하지 않도록 데이터베이스를 설계하는 것이 중요하다. (한 번 잘못 퍼져나간 변경사항은 되돌리기 어렵기 때문에)
이러한 Anomaly는 데이터에 변경 사항이 없는 READ 과정에서는 발생하지 않는다.
데이터가 삽입(INSERT), 수정(UPDATE), 삭제(DELETE)되는 경우에만 발생할 수 있는데, 각 경우에 따라 생기는 Anomaly는 다음과 같다.
EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours)
위와 같은 구조의 릴레이션(테이블)이 있다고 하자.
EMP_PROJ는 회사에서 일하는 직원과, 그 직원이 참여하는 프로젝트를 나타내는 릴레이션일 것이다.
그런데 만약 회사에서 새로운 프로젝트를 개설하고, 그 프로젝트에 참여할 직원은 나중에 정하는 상황에는 어떻게 해야할까?
이렇게 하나의 릴레이션에 정보를 추가할 때 속성 간의 종속 관계로 인해 삽입에 제한이 생기는 것을 Insert Anomaly
라고 한다.
EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours)
위 릴레이션에 아래와 같은 데이터가 저장되어 있다고 하자.
(1, 1, Koh, PL, 15)
(2, 1, Kim, PL, 11)
(3, 2, Choi, Cloud, 8)
이 때 프로젝트 PL이 CDT로 이름만 변경되었다고 하자.
그런데 변경 사항에 대한 데이터 갱신 전략이 제대로 이루어지지 않아 아래와 같이 1행과 2행 중 1행의 프로젝트 이름만 변경되었다고 하자.
(1, 1, Koh, CDT, 15)
(2, 1, Kim, PL, 11)
(3, 2, Choi, Cloud, 8)
위 데이터들을 보고 Koh와 Kim이 참여하는 프로젝트가 같은 프로젝트인지, 다른 프로젝트인지 알 수 없게 된다. 뿐만 아니라 Proj#가 Pname을 결정하는 종속 관계까지 깨지게 된다.
이처럼 같은 테이블에서 발생하는 Update Anomaly 뿐만 아니라, 다른 테이블에서 데이터 갱신에 따른 제약을 확실히 하지 않으면 데이터의 가치가 훼손될 수 있다. 이렇게 update, modification으로 발생하는 Anomaly를 Update Anomaly
라고 한다.
EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours)
위와 같은 릴레이션에서, 어떤 프로젝트가 마무리되어 더이상 진행되지 않는다고 하자. 그렇다고 해당 프로젝트에 대한 데이터를 모두 지우면, 프로젝트에 참여하던 모든 직원들의 정보도 함께 사라지게 된다.
반대로 혼자 프로젝트에 참여하던 사람이 더이상 회사에서 일하지 않게 되었을 때, 해당 데이터를 지운다면 그 프로젝트도 함께 사라지게 된다.
이렇게 종속 관계에 있는 데이터의 일부를 삭제했을 때 연관된 데이터가 함께 삭제되는 것을 Cascading
이라고 하며, 위와 같은 경우는 의도치 않은, semantic error를 일으키는 캐스캐이딩이므로 Unexpected Cascading
이라고 한다.
[Cascading]
외래키를 통한 참조 관계에 있는 두 테이블에 대하여 특정 테이블의 데이터가 삭제됨에 따라 연관되어 있는 데이터를 함께 삭제하여 데이터 무결성(Data Integrity)을 유지하는 제약 조건이다.
삭제의 경우 Delete Constraint를 cascade로 설정하면 여노간된 데이터를 함께 삭제하는 방법으로 데이터 무결성을 유지한다.
[결론]
이러한 Anomaly를 피하기 위해, 릴레이션을 설계할 때 준수해야 하는 여러가지 정규형들이 정의되어 있다. 정규형은 함수 종속성을 적절히 분해함으로써 이루어진다. 다음 포스트는 함수 종속성과 정규형에 대해 다룬다.