태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'정규형'에 해당되는 글 2건

엔터티에 반복되는 속성은 정규화를 하는 것이 원칙이며, 특히 속성이 묶음으로 반복된다면 정규화를 한다.

 

단독 속성이 반복되면, 추가되지 않고 고정적인지를 고려해서 정규화를 하지 않을 수 있지만 묶음 속성이 반복되면 정규화를 하는 것이 원칙이다.

 

[그림 1] 모델은 주문상품에 대한 속성(상품번호/상품가격/상품수량)이 반복된 비정규형 모델이다.



[그림 1]

 

주문상품에 대한 속성인 상품번호, 상품가격, 상품수량 속성이 묶여서 세 번 반복됐기 때문에 비정규형 모델이다. 이 모델은 세 개의 속성이 묶여서 반복됐기 때문에 정규화를 해야 한다. [그림 2] 모델이 [그림 1] 모델에 대한 정규형 모델이다.


 

[그림 주문정규화]

 

정규화를 한 주문상품 엔터티는 주문과는 다른 의미를 나타내는 별도의 엔터티다. 즉 엔터티의 성격에 맞도록 엔터티가 도출된 것이다.

 

[그림 3] 년간상품주문집계 엔터티는 주문수량과 그에 대한 주문금액을 1월부터 12월까지 관리하는 엔터티다.


 

[그림 3]

 

위 모델도 수량과 금액이 묶음으로 반복됐기 때문에 [그림 4] 모델과 유사한 정규형 모델로 설계해야 한다.


 

[그림 4]

 

위와 같이 묶음으로 속성이 반복될 때는 [그림 1] 모델처럼 함께 관리되는 속성이 묶음이 되도록 표현하는 게 좋다. 아래 모델처럼 관리하면 가독성이 많이 떨어진다.


 

[그림 5]

 

위의 모델은 함께 관리되는 속성이 무엇인지 명확하지 않다. 예를 들어 상품번호 속성이 주문수량 속성과 별개로 반복되는 것으로 잘못 이해될 수도 있다. 같이 관리되는 속성은 같이 위치하도록 해야 가독성도 좋아지고 정규화하기도 좋다.

 

묶음 속성이 반복되면 반복 속성이 많아지는 것도 문제지만, 묶음 속성 값이 정확하게 관리되지 않을 가능성이 커지기 때문에 정규화하는 것이 원칙이다. 만약 [그림 1] 주문 엔터티의 상품번호 속성 값과 상품가격 속성 값이 쌍을 이루지 않는다면 데이터가 훼손된 것이다. 묶음 번호를 잘못 사용하거나, 묶음 속성이 떨어져 있거나 하는 이유로 잘못 사용할 가능성이 있다. 모델이 복잡해서 가독성이 떨어지는 것은 당연하다. 묶음을 이룬 속성의 개수가 많다면 이런 문제는 더욱 증폭된다.

 

기본적으로 속성이 묶음으로 관리된다는 것은 다른 성격의 데이터임을 의미한다. 원천 엔터티와 다른 성격의 데이터인데 종속 관계의 데이터라서 한 엔터티에서 관리해도 무난하게 보이는 것일 뿐이다. 묶음 속성이 반복되는 것은 바람직하지 않으므로 정규화를 해야 한다.

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

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

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

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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




블로그 이미지

블루퍼필

댓글을 달아 주세요