[책리뷰] 관계형 데이터 모델링 노트 version.0.1 |

                                                                                                                  작성일시 : 2014.03.20

[책리뷰] 

 관계형 데이터 모델링 노트 version.0.1

 1차 리뷰한 내용인데 의견 있으시면 주세요 ^^

■ 설명이 개인적으로 도움이 되었던 점

2.8 등산과 정규화 " 정규화 과정은 데이터를 완전히 이해하는 과정이다. "  - 118p

     하나의 엔터티에는 서브타입이 하나만 존재할 수 있다  (Subset 을 의미하므로) 

       나머지는 Code 성이라고 보는 것이 맞을 듯 - 동감

 

622p [그림 6.26] 원천 엔터티가 종속관계 모델인 경우의 이력모델

623p [그림 6.27] 원천 엔터티가 종속관계 모델인 경우를 잘못 설계한 이력모델

654p [그림 6.78] 여러 엔터티의 이력 데이터를 관리하는 Vertical(종) 테이블

655p [그림 6.79] 서브타입 모델에 대한 Vertical(종) 테이블 이력 모델

657p [그림 6.82] 이력테이블에서 함께(동시에) 변경된 속성을 알야아 할 때

 

 

■  오타 및 다른 의견

129~132p [그림 2.9~2.15]  *고명명 --> *고객명

268p [그림 3.101] 정규직사원의 월급여, 연차휴가(일수), 그리고 (교육)과정은 1회만 일어나거나 또는 최초/최근 이수한 교육과정만을 의미하고자 하는 것인가?계약직사원의 시급여, 추가수당, 계약기간( 년 또는 월 또는 일자 아님 계약만료일자 ) *서브타입을 설명하고자 하는 것이기 때문에 괜찮은 것인가? 

496p [그림 5.33] 관계 속성이 늘어난 모델, 

         Relationship (피보험자고객2, 연대보증인고객, 연대보증인고객2, 연대보증인고객3)는

498p [그림 5.35], [그림 5.39], [그림 5.41], [그림 5.43], [그림 5.46] 

         Relationship 이 UID BAR 가 함께 있어야 할 듯 합니다.

498p [그림 5.36], [그림 5.38], [그림 5.42], [그림 5.44], [그림 5.45] 도 [그림 5.33] 과 동일한 사항임.

591p [그림 5.164] 요건에 의해 프로세스와 다른 관계선을 표현한 모델

         체결과 결제의 Relationship 은 점선과 실선의 형태가 아닌 전체가 점선의 형태가 되어야 할 듯 합니다.

          ( - - - - - - ------------<- )  ===>  ( - - - - - - - - - - - <- )

658p 2번째단락 첫째줄 오른쪽의, 하지만 이런 요건을 흔치 않기 때문에 --> 이런 요건"은" 흔치 않기 때문에

658p 마지막에서 2번째단락 마지막부분의,

        하지만 변경일자가 존재하는 점이력방법은 "일반적인" 이력 데이터 설계 방법이기 때문에 점이력 방법이란 용어는 사용하지 않을 것이다.  // 점이력은 "일반적" 이어서"점" 을 굳이 언급하지 않아도 이는 점이력이다라는 부분은 동의가 되지 않습니다.

그리고 속성을 정의하는 습관에 있어서 명칭은 혼돈을 주지않을 수 있는 수준으로 정의가 되어야 한다고 생각되어 그냥 점이력 또는 선분이력을 쓰는 것이 더 나은 선택이지 않을까 개인적인 의견입니다.

 

708p [그림 7.22] NULL 이 발생하는 속성을 별도의 엔터티로 분해한 모델

      고객배우자 엔터티와 같이 일대일 관계의 새로운 엔터티로 수직 분할하는 것이 저장공간을 효율적으로 사용하는 것이다 //*저장공간의 효율적인 차원에서는 엔터티로 분해하지 않는 것이 낫지 않을까요 ?

         별도의 엔터티로 두면, 최소한 "고객번호" 가 차지하는 공간만큼이 늘어나게 됩니다.

         고객의 대부분이 고객배우자정보를 가지지 않고 있다면, 대부분의 건수와 비율에 따라 다른 결과가 나올 수도 있겠지만 만약 속성이 NULL 이 아닌 경우가 대부분이고 공간을 차지하면서 거의 조회가 되지 않는 경우라면 조회성능을 위해 엔터티 분리를 Block Contention 과 함께 고민해서 고려해 볼 것 같네요

■ 전반적 관점에서 개선 필요

    Notation 이 왔다 갔다함. 

    일관성있게 한가지로 사용되어으면 함 ( 굳이 Notation 차이를 알리려고 하는 것이 아니라면 )

■ 개인적 고민의 이슈사항 (정련이 좀 더 필요) 

428p 4번째단락에서,

      반면에 영문명은 가능한 짧은 것이 좋기 때문에 단어에 대응하는 영문단축명은 짧게 정하는 것이 좋다.

      간혹 영문 단축명을 보고 단어의 의미를 알게 하려고 길게 정하는데,

      이는 컬럼명(영문명)이 길어지는 대신 효과는 크지 않아 의미가 별로 없다.

  ** 저는 약간은 글과 반대편의 입장에 서 있는 듯 하네요. 알 수 없는 기호, 예측이 불가능한 코드같은 컬럼명을 자주 마주쳐서 일까요, 너무길다면 합리적인 Abbreviation 을 강구해, 단어의 의미가 빨리 익숙해지도록 하는 것도 중요하다고 생각함.

 

같은 페이지 위에서 속성명을 명확하게 표현하려면 구체적으로 표현, 명명해야 한다. . . . . .

속성명이 구체적이지 않거나 여러 의미로 사용될 수 있을 때는 속성이 잘못 쓰일 가능성이 존재하는데 , 결국 실제로 잘못 사용하게된다. 구체적으로 명명해야 하지만 의미가 파악되는 한에서 가능한 짧아야 한다.

의미가 명확하면서 함축적인 속성명을 정하기가 쉽지는 않지만, 각 속성에 대해 고민하여 최적에 근접하도록 정해야 한다.

■ 내가 얻어서 앞으로 반영해 볼 점

- 업무(정의)설명이 먼저 언급되고 모델이 후속으로 나오면서 그려져 가는 방향이 어떨까 ?

 

# 너가 자기의 일에 능숙한 사람을 보았느냐

      이러한 사람은 왕 앞에 설 것이요

        천한 자 앞에 서지 아니하니라 #