태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

 

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

 

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



[그림 1]

 

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


 

[그림 주문정규화]

 

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

 

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


 

[그림 3]

 

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


 

[그림 4]

 

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


 

[그림 5]

 

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

 

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

 

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

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

엔터티 간의 관계에서 생기는 관계 속성은 한 엔터티에 여러 개가 있을 수 있으며, 그 관계 속성 중에는 유사한 성격의 속성이 있을 수 있다. 이때 유사한 관계 속성이 두 개 이상이며, 추가될 가능성이 조금이라고 있다면 별도의 관계 엔터티로 설계한다.

 

[그림1] 보험계약 엔터티에는 세 개의 관계 속성이 존재한다.

 


[그림1]

 

보험을 계약한 고객과 보험의 피보험자 고객, 보험의 연대보증 고객이 누구인지를 관리하는 속성이 관계 속성이다. 따라서 계약고객번호/피보험고객번호/연대보증고객번호 속성은 관계 속성이며, 관계선이 세 개이므로 관계 속성과 마찬가지로 관계 명에도 역할(Role) 이름을 사용한 모델이다.

 

이미 세 개의 관계 속성이 존재하지만 연대 보증인의 경우에는 여러 명을 관리할 수도 있어서 관계 속성이 더 늘어날 가능성이 있다. 이렇게 관계 속성이 늘어날 가능성이 있을 때는 아래 모델처럼 별도의 엔터티에서 관계를 관리한다.

 

[그림2]

 

보험계약당사자 엔터티는 관계(역할) 엔터티(Relationship Entity). [그림1] 보험계약 엔터티에 있던 관계 속성을 관리하는 엔터티다.

 

이와 같이 엔터티에서 관계를 관리하면 관계가 늘어나더라도 보험계약당사자 엔터티의 인스턴스만 늘어나므로 모델에는 영향을 미치지 않는다. 계약자/피보험자/연대보증인 이외의 다른 유형이 생겨도 당사자유형코드에 인스턴스만 추가하면 된다.

 

[그림2] 모델은 매우 유연한 모델이다. 업무 자체가 변경되지 않는 경우를 제외하면 관계 엔터티와 같은 정규형 엔터티를 사용해야 한다.

 

만약 관계 속성의 수가 완전히 고정적이라면 [그림1] 모델과 같이 관계 속성으로 관리할 수 있다. 업무가 변하지 않아서 계약자/피보험자/연대보증인 고객이 각각 한 명이고, 다른 유형의 고객은 생길 수 없다면 관계 속성으로 관리하는 게 바람직하다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 최상운 2017.03.22 01:12  댓글주소  수정/삭제  댓글쓰기

    머라고 불러야 하나...김이사는 좀 그렇고...그냥 이름 부를게 기창!!

    1년만에 소속을 듣네...뉴질랜드에 갔군...

    우리 나이가 되면 '내가 잘 살고 있나?' 라고 한 번쯤은 생각을 하지...삶에 터닝 포인트를 만들고 싶지만 운신의 폭은 그리 넓지 않지...가진건 별로 없지만 그나마 있는 것이라도 지키고 싶어서...

    자네의 결정이 좋을 결정이 되길 바래. 돌아 오는 날까지 자네와 집 사람 그리고 아이들 건강하고

    난 여전히 회사에 있어...나에게도 좀 작은 변화를 주려고 노력 하고 있고...시간되면 연락줘 이메일이 좋겠군 samuelc@empal.com

주 식별자(Primary Identifier)는 엔터티에 하나만 존재하는 대표 식별자입니다. 업무 식별자나 후보 식별자와 달리 물리적인 개념이 강해 PK(Primary Key)라고 생각해도 될 거 같습니다.

 

주 식별자 역할은 두 가지 관점으로 생각할 수 있습니다. 하나는 자신의 엔터티를 바라보는 관점이고요. 다른 하나는 다른 엔터티에서 바라보는 관점입니다.

 

전자는 자신의 엔터티 내에서 인스턴스를 식별하는 PK 역할이고요. 후자는 다른 엔터티에서 바라볼 때 그 엔터티와의 관계를 식별하는 FK(Foreign Key) 역할입니다.

 

주 식별자는 물리적으로 인스턴스를 대표하는 역할을 하기 때문에 인스턴스를 조회할 때 사용하고요. 또한 다른 엔터티와 조인(Join)할 때도 주 식별자를 사용합니다.

 

주 식별자를 선정하는 방법은 두 가지가 있습니다. 하나 또는 여러 개의 후보 식별자 중에서 대표로 지정할 수가 있고요. 적당한 후보가 없다면 인조 식별자를 만들어 주 식별자로 사용할 수도 있습니다. 주 식별자를 선정하는 방법은 이후에 자세히 설명하겠습니다.

 

주 식별자는 몇 가지 특성이 있습니다.

 

가장 기본적인 특성은 엔터티에 주 식별자가 반드시 존재해야 한다는 것입니다. 더 정확히 표현하면 엔터티에는 물리적인 주 키(Primary Key)가 반드시 존재해야 합니다. 간혹 PK가 없는 엔터티를 볼 수 있는데요. 이는 엔터티 무결성을 지키지 않은, 기본이 지켜지지 않은 모델입니다.

 

그리고 주 식별자는 하나만 존재해야 합니다. 이것이 또한 물리적으로 PK가 존재해야 하는 이유이기도 합니다. 하나만을 지정해야 다른 엔터티와의 조인(Join)이 가능합니다.

 

또한 주 식별자 속성은 당연히 널(Null) 값을 허용하지 않습니다.

 

주 식별자는 정규화의 기준이 되는 속성입니다. 정규화라는 행위가 먼저이고 그 결과에 따라 주 식별자가 정해지는지, 아니면 주 식별자가 정해지고 정규화가 진행되는지 애매한 점은 있지만, 최소한 정규형이 맞는지를 검증할 때는 주 식별자가 명확한 기준이 됩니다.

 

주 식별자(PK)는 외래 식별자(FK)와 함께 많이 알려진 식별자입니다. 실제로 많이 사용하는 식별자라 개념을 이해하는 것은 어렵지 않습니다. 어떤 속성을 주 식별자로 선택할지가 어려운 부분인데요. 주 식별자 선정 원칙은 별도로 설명하겠습니다.

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

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

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

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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




블로그 이미지

블루퍼필

댓글을 달아 주세요