태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

저는 속성을 아래와 같이 분류합니다.

 

- 기초(Basic) 속성

- 관계(Relationship) 속성

- 추출(Derived) 속성

- 시스템(System) 속성

 

이는 실제 엔터티에 존재하는 속성을 분류한 것입니다. 즉 순수하게 업무에서 필요한 논리적인 구분이 아니라 물리적인 구분입니다.

 

기초 속성(Basic Attribute)부터 차례로 설명하겠습니다.

 

엔터티의 본질을 설명하는 속성이 기초 속성입니다. 이 기초 속성을 보면 엔터티의 정의를 알 수 있습니다. 엔터티에 반드시 존재해야 하는 업무 식별자와 후보 식별자, 엔터티의 특성을 설명하는 속성 등이 이에 해당합니다.

 

[그림1] 주문 엔터티의 주문번호·고객번호·주문일자·배송요청일자·배송지주소 속성이 기초 속성입니다.

 

 

[그림1]

 

기초 속성은 오너십(Ownership)과 연관있습니다. 오너십 중에 엔터티가 어느 주제 영역(ERD)에 속해야 하는지에 대한 오너십이 모델 오너십(Model Ownership)인데요. 모델 오너십을 정하는 기준이 기초 속성입니다.

 

관계·추출·시스템 속성으로는 해당 엔터티의 성격을 알 수 없기 때문에 당연히 기초 속성이 기준이 돼야 합니다. 기초 속성의 값은 주로 데이터베이스를 사용하는 사용자(User)의 입력이라는 행위에 의해서 생성됩니다. 기초 속성의 값을 생성하는 영역에서 모델 오너십을 가져야 합니다.

 

바람직하지 않지만 만약 데이터 오너십(Data Ownership)을 관리한다면 마찬가지로 기초 속성의 값을 생성하는 조직(파트)에서 가져야 할 것입니다.

 

기초 속성은 주로 논리 모델링 초반에 도출됩니다. 일부 핵심적인 기초 속성은 개념 모델링 단계에서 도출되고요. 가장 먼저 도출해야 하는 속성이 기초 속성입니다.

 

속성이 도출되는 순서는 아래와 같습니다. 모델링할 때 이 순서로 속성을 추가하면 됩니다.

 

기초 속성 => 관계 속성 => 추출 속성 => 시스템 속성

 

엔터티에서 중복·추출 속성을 제외하면 가장 많은 속성이 기초 속성입니다. 또한 기초 속성을 전부 삭제하면 나머지 속성만으로는 그 엔터티가 무슨 데이터를 관리하는지 알 수 없게 됩니다. 그만큼 엔터티 본질과 연관되는 중요한 속성이 기초 속성입니다.

 

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

모델링의 3요소는 엔터티, 속성, 관계입니다.

엔터티 정의는 중요하기 때문에 어려운 반면, 속성 정의는 많은 개수 때문에 어려움을 겪습니다. 엔터티나 관계에 비해 압도적으로 많죠
.

속성은 엔터티의 성격을 상세하게 기술하는 요소입니다. 속성을 모두 도출(정의)하면 해당 엔터티가 관리하는 데이터가 무엇인지 알기 쉽습니다.

속성은 데이터의 값을 저장하는 저장소입니다. 데이터를 저장하는 가장 작은, 독립된 저장 단위죠. 이렇게 저장된 데이터가 엔터티를 자세하게 묘사합니다.

 

속성을 모두 도출해야 엔터티가 온전해집니다. 속성이 채워지지 않는 한 모델링은 끝난 것이 아닙니다. 결국 속성을 상세하게 분석하는 시간이 많을수록 데이터 모델의 완성도는 높아집니다.

 

이를 역으로 표현하면 모델링 시간이 충분히 주어질수록 속성을 상세하게 분석할 수 있어 모델의 완성도가 높아지게 됩니다. 결국 모델링 시간이 충분하지 않으면 속성과 관련된 작업이 부실해지게 됩니다.

 

속성의 정의 자체는 어렵지 않습니다. 하지만 속성의 진정한 쓰임새를 알려면 속성의 종류를 아는 것이 좋습니다. 속성의 다양한 분류법을 통해 속성이 무엇인지 더욱 상세하게 알 수 있을 것입니다.

 

다음과 같은 다양한 방법으로 속성을 구분할 수 있습니다.

 

-식별자(Key) 속성 & 비식별자(Non-Key) 속성
-
기초(Basic) 속성 & 관계(Relationship) 속성 & 추출(Derived) 속성 & 시스템(System) 속성
-
원본(Raw) 속성 & 추출(Derived) 속성
-
단일 값(Single-Valued) 속성 & 다가(Multivalued) 속성
-
필수(Mandatory) 속성 & 선택(Optional) 속성
-
코드(Code) 속성 & 비코드(Non-Code) 속성

 

위와 같은 방법으로 어떤 속성을 명확히 분류할 수 있다면, 속성이 무엇인지 온전히 안다고 할 수 있습니다.

 

위의 분류를 앞으로 하나씩 상세하게 설명하겠습니다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 금땡이 2012.02.28 14:08  댓글주소  수정/삭제  댓글쓰기

    바쁘신 와중에도 꾸준이 글을 올려 주시니 고맙습니다. 책 내용도 좋아 3번이나 읽었네요.
    프로젝이 다르다 보니 자주 뵙지도 못하고 블로그로 위안을 삼아야겠네요.^^

    • 블루퍼필 2012.02.28 19:45 신고  댓글주소  수정/삭제

      ㅎㅎ 누군가 했어요.

      긴 프로젝트 끝내서 시원섭섭하겠어요.
      재충전할 시간이 있을려나 모르겠네요.

      가끔 들러서 좋은 글 남겨주시고...
      그래도 심심하면 분당으로 놀러와요... ㅎ

이번 글에서는 통합을 고려할 수 있는 다양한 경우를 설명하겠습니다. 다양한 케이스를 소개하지만 결국은 데이터의 본질이 유사하다는 것으로 통하게 됩니다.

 

역할을 관리하는 엔터티는 [그림1]과 같이 통합 모델을 사용할 때가 많습니다.



[그림1]

 

사원은 특정 계좌에 대해 관리사원·유치사원·주문사원 등 여러 가지 역할을 할 수 있습니다. 여러 역할에 따른 엔터티가 개별로 존재하는 것이 아니라 계좌관계사원 엔터티와 같은 통합 엔터티로 존재하는 것이 바람직합니다.

 

[그림2]와 같이 대칭적인 업무를 관리하는 데이터도 통합을 고려할 수 있습니다.



[그림2]

 

이경우 업무 성격은 대칭적이지만 데이터 성격은 유사합니다. [그림2]는 식별자가 같지만 식별자가 다르더라도(매출전표번호와 매입전표번호) 통합할 수 있습니다.

 

매도와 매입, 입고와 출고 등도 대칭적인 업무에 해당하는 데이터입니다.

 

[그림3]은 계층 관계가 존재하는 엔터티입니다. 계층 관계도 통합을 고려해야할 주요 대상입니다.



[그림3]

 

엔터티 통합은 대부분 수평적인 관계의 엔터티가 통합돼 서브타입(Subtypes)이 발생하지만, 계층 관계의 엔터티 통합은 수직적 통합으로 순환(Recursive) 관계가 발생합니다.

 

[그림3]은 계층 때문에 다른 데이터간의 상하 관계처럼 보이지만 결국은 유사한 데이터입니다.

 

[그림4] 엔터티에는 공통 속성이 보이는데, 이때 공통 속성이 별도의 데이터 성격을 지닌다면 통합을 고려할만 합니다.



[그림4]

 

여러 계좌 엔터티에 통보 연락처를 관리하는 속성이 공통으로 존재합니다. 통보 주소·이메일·전화번호는 이전 글의 [그림5]와 유사하게 별도의 엔터티에서 통합할 수 있습니다.

 

아래의 [그림5]는 배타 관계가 발생한 모델인데요. [그림4]까지 모델은 순수하게 엔터티를 통합하는 개념이지만 [그림5]는 관계를 통합하는 개념이 포함돼 있습니다.



[그림5]

 

[그림5]의 거래내역 엔터티에 많은 관계가 배타 관계로 존재합니다. 배타 관계는 모델의 구조를 복잡하게 만들고, 자연히 복잡한 조인(Join)이 발생해 바람직하지 않은 관계입니다. 이에 대해서는 후에 자세하게 설명하겠습니다.

 

어쨌든 거래내역 엔터티에 배타 관계를 발생시킨 엔터티(주식종목·채권종목·선물옵션종목·수익증권종목)를 통합하면 거래내역 엔터티에는 배타 관계가 발생하지 않습니다.

 

그리고 통합해야 좋은 대표적인 엔터티는 집계 엔터티입니다. 집계 엔터티는 집계하려는 기준에 따라 디멘젼이 달라집니다. 디멘젼이 다르면 식별자가 달라지는데요. 디멘젼이 유사하거나 포함 관계가 있다면 통합하는 것이 좋습니다(물론 집계하려는 내용이 같아야죠).

 

[그림6] 모델은 디멘젼이 다르긴 하지만 유사하고, 집계하려는 내용은 매출 총액으로 같습니다.



[그림6]

 

[그림6]의 디멘젼에는 포함 관계가 있습니다. 즉 월이 모여서 분기가 됩니다. 따라서 월에 대한 총액만 있어도 분기는 합쳐서 구할 수 있습니다.

 

상품별월매출 엔터티에서 2030 1월부터 3월까지 매출 총액을 더하면 분기의 총액이 됩니다. 굳이 상품별분기매출 엔터티를 만들어 위에서 더한 값과 2030 1분기 매출 총액이 달라지는 것을 걱정할 필요가 없습니다(간혹 성능 때문에 중간 단계의 엔터티를 만드는데 반드시 필요한지 숙고해야 합니다).

 

(화면)가 달라서 데이터를 별도로 보관하는 것은 무결성 차원에서 바람직하지 않습니다. 정정 데이터에 대한 처리 문제와 성능 문제 등으로 데이터를 별도로 저장해서 관리해야 할 때가 있지만 여느 엔터티와 마찬가지로 유사한 집계 엔터티는 통합하는 것이 좋습니다

 

[그림7]은 집계하려는 내용까지 약간 다릅니다. [그림6]에서 조금 더 달라진 모델이죠.



[그림7]

 

월별 데이터는 매출 총액과 반품 총액을 관리하고 분기별 데이터는 매출 총액과 배송료 총액, 수수료 총액을 관리합니다.

 

비록 관리하는 속성이 약간 다르지만 데이터를 생성할 때 조금만 신경 쓰면 굳이 두 개의 엔터티를 관리하지 않아도 될 모델입니다.

 

[그림8]은 이전 모델보다는 디멘젼이 많이 다릅니다. 디멘젼 사이에 포함 관계도 없고요.



[그림8]

 

상품코드와 부서코드라는 전혀 다른 성격의 기준(Dimension)으로 집계를 했지만 집계하려는 내용은 같습니다. 이 경우도 엔터티 생성을 남발하는 것보다는 상품코드와 부서코드를 기준으로 매출액을 집계하면 하나의 엔터티에서 관리할 수 있습니다. 물론 이때는 기준이 달라져서 인스턴스가 더욱 많이 발생합니다.

 

인스턴스가 지나치게 증가하거나 집계 기준이 지나치게 복잡해질 때는 최종적으로 통합이 적합하지 않을 수도 있지만, 최소한 통합을 고려해보는 것은 의미가 있습니다.

 

이처럼 집계 엔터티는 집계하려는 내용(데이터 성격)과 집계하려는 기준(Dimension)을 고려하여 통합을 고민해 보는 것이 좋습니다. 사실 이걸 고민하는 것이 집계 데이터에 대한 요건을 만드는 것입니다.

 

생성이 다소 번거롭더라도 데이터 정합성에 문제가 발생하지 않아야 하는 것은 집계 엔터티에도 마찬가지로 적용하는 기본 원칙입니다.

 

마지막으로 엔터티 합체와 관련된 내용인데요. 엔터티 합체에도 데이터 통합 개념이 적용됩니다.

 

[그림9]와 같이 일대일 관계가 발생한 엔터티는 통합할 수 있습니다. 물론 이는 여러 번 언급했듯이 엄밀히는 엔터티 합체입니다.




[그림9]

 

첫 번째 모델은 성능을 고려해 덜 사용하는 속성을 분리한 것이고요(하지만 데이터 본질은 동일합니다). 두 번째 모델은 프로세스 흐름을 엔터티로 표현한 것입니다.

 

기본적으로 바람직하지 않지만 프로세스대로 엔터티를 분리하는 게 명확할 때도 있습니다. 이때 주의할 점은 결과(계약승인)를 여러 번에 걸쳐 입력할 수 있는지입니다. 즉 일대다 관계가 될 수 있는지 주의해야 합니다. 현재는 아니라도 미래에 그럴 수 있는지를요.

 

만약 일대다 관계일 수 있는데 합쳐 놓으면 일대다 관계로의 검토 자체가 불가능해집니다. 분리하려 해도 쉽지 않고요. 일대다 관계가 될 가능성이 있다면 반드시 [그림9]와 같이 엔터티를 분리해야 합니다.

 

비정규화를 하면서 엔터티가 통합될 수도 있습니다. [그림10]과 같은 정규형 모델에 성능 문제가 발생하면 엔터티를 합칠 수 있습니다. 즉 이 경우도 엔터티 합체에 가깝습니다.


 

[그림10]

 

주문의 기본 데이터를 관리하는 주문 엔터티와 주문 상품을 관리하는 주문내역 엔터티는 마스터(Master), 상세(Detail) 관계이면서 일대다(1:M) 관계의 모델인데요.

 

만약 주문한 상품을 빠르게 조회해야 하는 최우선의 요건이 있다면 주문내역 엔터티를 기준으로 마스터 성격의 데이터인 주문 엔터티를 합체하는 것이 유리합니다. 즉 주문내역 엔터티의 속성은 그대로 두고 주문 엔터티의 속성을 포함해 중복 관리합니다.

 

2정규형이나 3정규형 등의 모델도 하나의 엔터티로 합체할 수 있습니다.

 

이상으로 여러 가지 통합 대상 엔터티를 설명했는데요. 통합하거나 통합하지 않았다는 결과보다는 과정이 중요합니다. 과정은 깊게 고민해야 합니다.

 

통합하는 기준을 다시 간략하게 정리하면요. 아래 기준 중에 하나라도 만족되면 일단 통합을 고려하는 것이 좋습니다. 일반화의 정도에 따라 다르겠지만 아마 웬만하면 첫 번째 기준에 해당될 것입니다.

 

● 데이터의 본질(성격)이 유사하다

● 식별자가 동일하면서 유사한 속성이 존재한다

● 식별자는 다르지만 기초 속성이 유사하다

 

통합할 때는 아래와 같은 문제도 고민해야 합니다.

 

● 통합해도 성능 문제를 일으키지 않는다

● 현행 데이터를 마이그레이션하는 데 문제가 없다

 

통합 시 주의할 점에 대한 글도 참고하세요.

 

통합이 대세인가? 통합 시 주의할 점

 

이상으로 통합을 고려할 엔터티에 대해 설명했습니다. 통합(Generalization)은 정규화(Normalization)와 함께 중요한 부분입니다. 많이 고민하여 기준을 세우는 것이 좋습니다.






블로그 이미지

블루퍼필

댓글을 달아 주세요

지난 번에 설명한 데이터 성격이 유사하다는 것이 데이터 통합을 고려할 가장 중요한 요소입니다.

 

- 데이터의 성격(본질)이 유사할 때, 즉 집합의 정의가 유사할 때

 

[그림1]고객이 요청한 알림 서비스를 관리하는 엔터티입니다.



[그림1]

 

고객알림서비스 엔터티는 고객별 알림 서비스를 관리하는 엔터티이고, 계좌알림서비스 엔터티는 계좌별 알림 서비스를 관리하는 엔터티입니다. 어떤 종류의 알림 서비스를 원하는지와 어떻게 알림 서비스를 받는지, 서비스 신청 일자와 알림을 몇 번 반복하는지 등의 데이터 성격은 두 엔터티가 동일합니다.

 

단지 고객을 지정해 서비스를 하는지, 계좌를 지정해 서비스를 하는지가 달라 주 식별자가 달라졌습니다. 그래서 엔터티가 통합되지 못한 예제인데 통합 대상입니다(주 식별자가 다른 여러 엔터티를 통합하는 방법은 별도로 설명하겠습니다).

 
사실 데이터의 본질이 유사한지 따지는 것 자체가 어려운 일입니다. 지금 몇 장에 걸쳐 설명하고있는 내용이기도 하고요.

 

엔터티에서 관리하는 데이터의 본질은 속성으로 나타납니다. 따라서 속성이 유사하면 본질이 유사할 가능성이 높습니다. 더욱이 기초 속성1)이 유사하면 통합을 고려할 수 있습니다.

 

[그림2]는 속성이 유사한 예제이고요. 이전 글의 계좌 엔터티나 고객 엔터티와 마찬가지로 대표적인 통합 대상 엔터티입니다.



[그림2]

 

[그림3]은 속성은 다소 다르지만 기초 속성이 유사한 통합 대상 엔터티입니다.


[그림3]

 

모두 결국 데이터의 본질이 유사하다고 볼 수 있습니다.

 

[그림4]는 이제까지의 예제와 달리 데이터 본질 측면에서는 유사성이 가장 떨어집니다.


[그림4]

 

하지만 역시 몇몇 기초 속성이 유사해 통합 대상인데요. 데이터 성격이 다소 달라서, 고객이 약정한 서비스를 함께 보여주지 않는다면 통합을 숙고해야 합니다. 즉 데이터를 같이 본다는 측면이 통합을 하는 명분이 됩니다.

 

사실 성격이 완전히 다른 데이터를 같이 볼 이유는 없죠. 비슷하니까 같이 보게 됩니다. 데이터를 같은 방법으로 사용한다면 유사한 데이터일 가능성이 높습니다.

 

일반적으로 [그림4]와 같은 엔터티를 부가서비스라는 상위 개념으로 일반화하는 건 좋은 생각입니다. 한번 더 일반화를 한다면 서비스라는 개념이 되겠고요.

 

아래 [그림5]도 일반화를 한 예제입니다.



[그림5]

 

고객의 집주소·회사주소 등은 매우 유사해서 고객우편주소 엔터티로의 일반화가 자연스럽고요. 고객의 개인이메일·회사이메일·홈페이지·메신저 등도 유사한 편이라 고객전자주소 엔터티로 일반화가 됩니다. 집전화·회사전화·휴대전화·팩스도 마찬가지로 고객전화번호 엔터티로 일반화됩니다.

 

이를 한 번 더 일반화한 게 고객연락처 엔터티입니다.

 

엄격히 보면 집 주소와 이메일 주소는 유사한 데이터가 아닙니다. 전화번호는 더욱 그렇고요. 하지만 고객한테 연락할 곳이라는 개념에서는 유사성이 있습니다.

 

[그림4]와 마찬가지로 여러 연락처를 함께 볼(사용) 가능성도 높습니다.

 

데이터를 일반화(Generalization)하면 엔터티가 통합됩니다.

일반화 강도에 대한 고민은 항상 하지만 기본적으로 일반화하는 것을 검토합니다.

 

이번에는 주로 데이터 성격이 유사한 경우를 설명드렸습니다.

통합을 고려해야 할 다양한 경우를 이어서 설명하겠습니다.

 

 

1) 기초 속성(Basic Attributes): 엔터티의 본질을 설명하는 속성으로 업무 식별자와 후보 식별자, 엔터티의 성격을 대표할 수 있는 핵심 속성, 업무를 정의하는 코드 속성 등이 기초 속성에 포함된다.


블로그 이미지

블루퍼필

댓글을 달아 주세요