정규화와 응집도에 대한 고찰

생짜배기 컴맹이었던 필자가 본의 아니게 IT에 관련된 일을 시작하여 이제는 누가 봐도 IT인이 되었고, 그러면서 이것저것 IT 이론들에 대해서도 주워들은 것도 조금 생기게 되었다. 그래 봤자 High-End 급의 이론들은 아니고, Classic한 것이 대부분이지만 말이다. 하지만 이러한 이론들도 모이고 모이다 보니 그 중 몇몇 개에 대해서는 재미있는 성향을 발견하곤 한다. 그 중에 하나를 오늘 소개해 드릴까 하는데, 바로 정규화(Normalization)와 응집도(Cohesion)에 대한 이야기이다.

'정규화'는 데이터베이스 모델링 이론 중 가장 기초적인 이론! '응집도' 역시 소프트웨어 공학 내용 중 거의 앞부분에 나오는 고전적인 이론이다. 사실 정규화와 응집도에 대한 이론을 잘 알고 계신 분들은 공감하시겠지만, 이 두 가지 이론을 얘기하다 보면 사용하는 단어만 달랐지, 그 내용은 거의 동일하다는 느낌을 받게 된다. 그럼 먼저 Novice 단계의 분들을 위해 두 이론을 되짚어 보며, 공통점을 찾아 보도록 하자.

1. 정규화

정규화(Normalization)란 관계형 데이터베이스의 설계에서 데이터의 중복을 최소화하도록 데이터를 구조화하는 프로세스를 말한다(위키백과 참조). 이렇게 얘기하면 잘 와닿지 않는 부분도 있으니 예를 한 번 들어 보겠다.



이런 식으로 DB 테이블을 만든다면 아래와 같은 상황이 생긴다.

1) '홍길동' 학생이 이번에 DAP 자격증을취득하였다면 해당 테이블에 DAP 관련된 정보(자격증, 자격증번호, 취득일)외에도 '홍길동' 학생의 정보(이름, 주소, 핸드폰번호)를 불필요하게 같이 넣어줘야 한다 (삽입이상 : Insertion Anomaly).

2) '강감찬' 학생의 OCP 자격증 정보가 잘못 입력되어서 자격증 정보를 삭제해야 한다면 자격증 정보뿐만 아니라 '강감찬' 학생 정보도 같이 같이 삭제된다(삭제이상 : Deletion Anomaly).

어찌 보면 독립적으로 다뤄져야 할 정보들(학생, 자격증)을 한 테이블에 섞어 놓았을 때 생기는 현상인데, 이 문제를 해결하기 위해선 다음과 같이 테이블을 나눠야 한다.



이런 식으로 데이터의 삽입, 삭제, 변경 시 이상(Anomaly)현상을 해결해서 데이터의 중복을 배제하고 정합성을 지키자는 것이 정규화 이론의 목표라 할 수 있겠다(샘플 참조: http://force44.blog.me/130100972038).

2. 응집도

응집도 (cohesion)란 프로그램의 한 모듈이 해당 기능을 수행하기 위해 얼마만큼의 연관된 책임과 아이디어가 뭉쳐있는지를 나타내는 정도이다(정의 참조 : http://lazineer.tistory.com/93). 예를 들면 평균을 계산하는 프로그램 모듈을 만들었으면,그 내용이 평균을 내기 위한 코딩 내용으로 채워져 있어야 하는 것은 당연한 것이고, 표준 편차나 분산(Varience)을 구하는 코딩 내용이 섞여져 있으면 응집도가 떨어진다는 내용이다. 즉, 한 프로그램 모듈 내에 이것 저것 비즈니스 기능들이 섞여져 있다면 해당 모듈은 이해하기 힘들고 재사용 및유지·보수가 어려워지게 되며, 관련된 다른 모듈의 변화에 민감할 수 밖에 없다는 이론이다.

자, 이렇게 두 가지 이론을 함께 두고 보니 어디선가 공통점이 느껴지지 않는가 독립할 수 있는 정보(학생↔자격증,평균↔표준 편차)는 독립적으로 다뤄져야 하며, 그 둘 간의 관계는 최소한의 인터페이스(릴레이션)만을 필요에 따라 가져야 한다는 것이 필자가 이해하는 두 이론의 공통된 내용이다.

물론 더 상세한 내용들과 각 이론의 분류 방식{정규화(1NF,2NF)↔ 응집도(기능적 응집도, 순차적 응집도)}등은 다르지만 궁극적으로 목표하고자 하는 바는 비슷하다.

그럼 이렇게 태생이 틀린( From DB, From SW)두 이론이 어째서 비슷한 내용을 가지게된걸까 궁극(窮極)의 도(道)는 서로 통해서 일까 필자가 생각하기에는 두 이론 모두 정보 기술(IT)의 공통된 현실적 문제를 해결하기 위해 만들어졌기 때문이라고 생각한다. 다시 말해, 두 이론 모두 우리가 살고 있는 현실을 모티브로 해서 나온 이론들이다. 현실 즉. 정보 기술을 구현하는데서 생긴 공통된 난점들을 극복하기 위해 노력한 산물이 이러한 이론을 만들었다고 생각한다는 것이다. 그게 다만 분야가 달라서각 분야의 언어와 방식대로 풀이되어 마치 다른 내용인것처럼 보이는 것이게 아닐까 생각해 본다.

정리하면,현실이 먼저이고 이론은 그 다음 내지는 그 현실을 해결하고 난 뒤 그 방법을 정리한부산물 정도로 봐도 되지 않을까

그런데 요즘은 이것이 역전(逆轉)된 경우를 많이 본다.어디선가 새로운 이론이나 방법론이 나오면, 현실이 방법론을 따라가야 하는 것처럼 행동하는 사람들 말이다(필자는 이러한 것을 대형 서점의 IT Section에 나와있는 똑같은 타이틀로 도배되는 책들을 보며 많이 느꼈다).

필자 또한새로운 개념과 방법론(예: EJB, CORBA, SOA, WEB SERVICE, HTML5, RIA, Spring)등이 나올때 마다 내가 지금 하고있는 현실의 일을 팽개치고 새로운 것을 해야 쓸모있는 사람이 될 수 있지 않을까 하는 생각을 했었다.

그러나 가만히 생각해 보면 내게 닥쳐진 현실적인 문제(IT문제)를 해결하기 위해서 이리 구르고 저리 구르다 보니 새로운 이론 및 방법론에 알게 모르게 연결되어 있는내 자신의 모습을 보기도 한다. 그리고 사회 전체적으로 그러한 이론들이 팽배해 있을때, 누구라도 '난 그런 이론과 별개로 살고 있습니다' 라고 말하기는 어려울 것이다. 왜냐하면 알게 모르게 그것들이 내가 지금 하고 있는 일들과 엮여져 있으니까 말이다.

어떠한 완벽한 이론도 자신이 처해 있는 현실적인 문제를 해결하는데 도움을 주지 못한다면 적어도 나에게만큼은 완벽하다고 할 수 없을 것이다. 그러니 새로운 이론과 개념이 나왔을 때 조바심을 내는 건 어리석은 일이다.새로운 이론과 개념을 대면하면그것을 무작정 따라 가기 보다 나와 어떻게 연결이 되어 있는지세심하게 살펴 보고,내 현실적인 문제를 어떻게 해결해 줄 수 있나 조곤조곤히 따져보며, 현실로방법론을가져오는 것이현명한 처사가 아닐까현실이 무작정 방법론을 따라가는 것과는 매우 다르게 말이다.