1 사례1

2 사례2

3 결론

예전에 커뮤니티에 다음과 같은 질문이 올라왔다.

고객이 테이블이 있는데 사업자등록번호 고객번호가 바뀌어서 들어갔습니다. 손으로 일일이 고치기는 양이 너무 많습니다. SQL로 고칠 수 있을 것 같은데 저는 도저히 모르겠습니다. 도와주세요.

사업자등록번호와 고객번호가 뒤바뀌어 입력되었다는 것이다. 그것도 사람이 직접 고치기에는 그 양이 너무 많다는 만큼... 컴퓨터세계의 일이 아니라 현실세계에서 고객에게 보내는 문서에 사업자등록번호와 고객번호를 바꾸어서 공문을 보냈다면 어떻겠는가? 아마도 이런 실수로 몇 천, 몇 만 군데가 될 것이다. 한 두 군데라면 죄송하고 하고 다시 보내면 되겠지만, 이건 진짜 ‘아니올시다’ 이다.
위 문제는 쿼리로 해결한다고 해도 근본적인 문제는 개선되는 것이 아니다. 이것은 컴퓨터세계와 현실세계가 일치하지 않아서 생긴 문제다. 문제가 발생했을 당시의 현실은 불변이므로 컴퓨터 세계의 개혁이 필요한 것은 당연하다. (물론 현실이 변화하면 종속적인 컴퓨터 세계도 같이 변화해야 한다.) 고객번호 자리에 사업자등록번호가 들어가지 못하게 하고, 그 반대의 경우도 마찬가지이다. 이것은 근본적인 설계의 문제라고 할 수 있다.

커뮤니티에 가보면 다음과 같은 질문을 심심치 않게 볼 수 있다.

사원 테이블에 사원번호가 중복되게 들어가 있다. 중복된 로우가 없게 가져오고 싶다. 어떻게 해야 하는가?

Group By, Distinct 를 쓰면 되기는 한다. 또한 중복된 것을 삭제하고자 하기도 한다. 중복된 로우를 없애는 방법은 여러 솔루션이 이마 만들어진 상태이다. 그러나 역시 이것은 바로 내 앞에 닥친 문제만을 해결할 뿐이다. 원천적인 문제는 모델링과 설계의 잘못이다.
그렇다면 사원번호가 중복되었다는 것은 무엇을 의하는 것일까? 그것은 그 조직에 나와 똑 같은 사원이 존재한다는 뜻이 된다. 요즘에 인간복제가 이슈가 되는 상황인데 인간복제라도 했단 말인가? 이것이 바로 우리가 데이터베이스론 책에서 보아왔던 ‘개체무결성’ 이 깨진 것이다. 이래도 이론이 필요 없는가? 이론이 바탕이 되지 못한 모델링과 설계로 사원이 복제된 꼴이란 참으로 우습다. 사원번호가 1111 이 중복되어 있다면 그 사원에게 주어진 직무를 50%로 나누어서 시킬 수도 있는 노릇이다. 월급은 어떻게 줄 것인가? 두 사람 모두에게 월급을 줄 것인가? 이런 단순한 잘못 하나로 기업은 엄청난 손해를 입을 수도 있다. Group By, Distinct의 사용으로 중복의 문제를 해결하는 것은 눈 가리기 식의 임시 방편일 뿐이다. 원천적인 잘못은 개체무결성을 생각하지 않은 설계의 문제이다. 그러므로 중복된 데이터를 삭제 후 물리적으로 Primary Key를 설정해주는 것이 당연한 방법이라 하겠다.

예전에 자동차의 주 원료인 휘발유에서 나오는 아황산가스가 문제가 된 적이 있었다. 그래서 정부는 자동차의 주 연료인 휘발유 자체에서 황을 제거함으로써 아황산가스에 대한 문제를 해결했다. 만약 정부가 현상만을 해결하려고 했다면 어떻게 되었을까? 지금의 자동차는 배기구에 황을 제거하는 장치를 모두 달았을 것이다. 또한 휘발유를 사용하는 공장의 굴뚝에도 모두 황을 제거하는 장치를 달아야 했을 것이다. 생각을 해보라. 자동차에 일일이 황을 제거하는 장치를 다는게 비용이 적게 들까? 아니면 휘발유 자체에서 황을 제거하는 것이 비용이 적게 들까?