정규화에 대한 주절거림

블로그에 서브타입에 대한 글을 쓰고 있는데요.

변화를 위해 다양한 주제의 글을 올리겠습니다.

 

나이를 먹을수록 확실히 체력의 부담을 느낍니다.

일주일에 하나씩은 올리려는 생각이 한 달에 두 개로 줄고... 실제는 하나만 올라가기도 하고요.

 

최근에 정규화에 대해 다시 생각하고 있습니다.

 

지나치게 사적인 얘기지만 저는 모델링이 자신 있는데요. 남들이 뭐라하든... ㅎㅎ

오래 전부터 해 오던 훈련 때문입니다.

 

속성의 종속 관계를 파악해서 엔터티를 도출하는 훈련인데요. 쉽게 말해 속성이 엔터티에 속하는 게 옳은지를 판단하는 것입니다. 이 훈련의 핵심은 식별자와 종속성입니다.

 

엔터티를 대표하는 속성(업무 식별자)을 찾아야 하고요. 그 속성을 기준으로 대상 속성이 종속됐는지 여부를 판단합니다. 종속성이 없다면 다른 엔터티를 찾고요.

 

이 훈련을 거듭하면 전문 모델러가 될 수 있습니다. 정규화를 제대로 아는 전문 모델러가요.

 

정규화를 꼭 해야 하는지 묻는 사람들이 많습니다. 원론적인 얘기들은 이후에 많이 하겠지만 모델러라면 정규화를 꼭 해야 한다고 단언합니다.

 

정규화를 별로 고려치 않으면서 모델링하는 사람을 보는데요. 결과와 무관하게 전문 모델러로 여기지 않습니다.

 

사실 정규화를 모르고 화면 위주로 설계해도 대강은 맞게 돼 있습니다. 어떤 화면이라도 본질적으로 유사한 정보(종속성으로 묶인 정보)와 참고로 보여주는 정보(다른 화면에도 존재하는 중복 정보)를 한 화면에 보여주니까요.

 

하지만 이렇게 설계하면 뭔가를 변경하고 추가할 때 문제가 발생합니다. 그 문제가 그때그때 견딜만 해서 버텼던 것인데요. 이젠 전문가 집단이 생기고, 더 이상 주먹구구식으로 설계해선 안 되겠다는 인식이 생겨 마냥 버틸 수는 없게 됐습니다.

 

제대로 설계하기 위한 근본적인 해결책은 정규화입니다. 시스템에 따라 정규화가 필요 없을 수 있지만 그건 필요에 따른 선택일 뿐입니다. 이마저도 원칙에 바탕을 둔 선택입니다. 주(主)와 객(客)을 혼돈하면 안 됩니다.

 

정규화는 엔터티 정의 자체이기 때문에, 즉 근본적인 것이기 때문에 아무리 강조해도 부족함이 없습니다. 선택 사항이 아니라는 사실을 염두에 둬야 합니다.

 

정규화에는 여러 종류가 있는데요. 정규화 이론에 대한 이견은 크지 않습니다. 학문으로 연구하는 사람은 약간씩 다른 주장을 하지만 모델러에게 큰 영향은 없을 거 같습니다.

 

일반적으로 정규화는 순서대로 수행하지 않습니다. 상향식이면 속성을 제거하면서 정규화가 수행되고, 하향식이면 생각하는 과정을 거쳐 이미 3~4정규화가 수행됩니다. 제가 초보일 때를 생각해봐도 순서대로 수행하지 않았던 거 같습니다.

 

물론 1정규화부터 차례대로 수행해도 됩니다. 현실적이진 않지만 더 체계적일 수는 있습니다. 2정규형이면 1정규화도 만족해야 되니까요.

 

RDB의 핵심은 조인(Join)입니다. 모든 속성은 주인이 되는 하나의 엔터티에만 속하고, PK만이 다른 엔터티에 존재할 수 있습니다. 다른 엔터티에 있는 속성이 필요하면 PK를 통해 조인을 해서 얻는 것이 RDB 개념 자체입니다.

 

속성의 주인(엔터티)을 찾는 과정이 정규화입니다.