본문 바로가기

Data Architecture

[책리뷰] 프로젝트 성패를 결정짓는 데이터 모델링 이야기

 ------- 작성중 --------

09.24일 밤 11시 경비실에 책을 받아들고 1시간 반정도 쭉 빠른 속도로 읽어보았다. 

우선은 목차를 쭉 보면서 주요한 주제들은 놓치지 않으면서 확인해 나가는 형태로 보기로 했다.                 

             


모델링 책, 1년 좀 짧은 시간 아닐까 쓰기에는

두께와 살짝 넘겨본 페이지는 약간의 기대를 내려놓게 만들어 주었다



p.7

책의 내용은 전반적으로 DBMS의 종류와는 무관합니다. <- , 는 . 로 교정 필요

그렇지만 일부에서는 RDBMS 의 테이블 구조를 전제하고 설명했습니다.


p.30

[주문]과 [주문상품]의 관계는 훨씬 더 강력한 관계이다. 

일반적으로 주문한 상품이 없는 주문은 존재하지 않기 때문이다. 



p.35

데이터 모델링의 본질을 읽어 모델링하다


p.37 

엔터티명 "설문지" 는 합당한가 ? 

설문인가 설문지인가 ?  "지" 는 종이만의 의미를 지니는가 ? 


[회원설문참여] 없이 [설문응답] 이 존재할 수 있는가 ? 

[설문응답] 의  #설문응답내용 (*TEXT 라면 PK 로 다룰 필요가 있는가라는 질문에 맞닥뜨리게 된다.)

"내용" 속성의 특질상 PK 일 필요가 없으며 (내용을 여러개 적는 것도 아니고), 

 PK 로도 적합하지 않다 


 - 설문응답은 회원설문참여와 관계가 있지는 (자식엔터티로서) 않은지 검토가 필요하다.

  

p.39 

[설문질문] 의 속성 *객관식여부는 새로운 엔터티의 도출을 요구하게 된다. 

ERD 에 변경(추가를 포함하여)이 가해져야 한다는 것이다. 





p.50 

범주화에 대한 흥미로운 실험


p.53

고대 그리스 철학자들이 세상을 이해하는 방식

1. 사물의 속성 자체에 주의를 기울이고

2. 그 속성에 근거하여 범주화하고

3. 그 범주들을 사용해서 규칙을 만들고

4. 사물의 특성과 움직임을 그 규칙으로 설명한다


*비즈니스 맥락에서 본질이 되는 개체를 명확히 떼어내는 방법




p.57

범주화와 추상화




범주화 : 유사한 것들을 일정하게 묶는 프로세스

추상화 : 문제 영역에서 가장 핵심적인 특성만을 추리는 과정이다. 


서울대 교육학용어사전

추상화는 구체적 사물들의 공통된 특징,즉 추상적 특징을 파악하여 인식의 대상으로 삼는 행위다. 

추상화가 가능한 개체들은 그것들이 소유하고 있는 특성의 이름으로 하나의 집합을 이룬다. 

그러므로 추상화한다는 것은 여러 개체를 집합으로 파악하는 것과 동일하다.


사전적 정의를 조금 쉽게 풀어내면

'어떤 관점을 기준으로 관심없고 복잡한 특성은 걷어내고 핵심만을 간추리는 행위, 

 그 과정에서 유사한 것들은 하나의 집합으로 파악하는 것' 으로 다시 정의해 볼 수 있다. 



생략을 통해 대상의 본질과 특징을 드러내어(추상화)

업무에 필요한 데이터를 성격이 유사한 것끼리 모아놓는 과정(범주화)이다. 



속성의 제 위치(엔터티)를 찾아낼 수 있다. 


p.72

[카드사용가능금액]  엔터티명으로 적절한가

혹시 카드사용금액한도 의미인가 ? 

*현금서비스사용가능금 은 "액" 이 붙어야겠지

모델도

[카드원장] "원장" 의 의미는 무엇인가 ? 

[카드원장]과 [카드주소지]의 관계를 1:1 로 풀었는데 자택전화번호와 직장전화번호의 반복적인 속성을 넣어두니 고민이 필요해 


보인다. 

[카드주소지] 엔터티명은 고민이 더 필요해 보인다. 

[카드사용가능금액] 은 과연 엔터티명에 '금액' 이외에 다른 명칭 선택이 더 낫지 않았을까 라는 생각을 한다. 


결국 모델링은 ERD 로 의견을 주고 받게 되고, 먼저 ERD 한번 봐 봅시다 라고 이야기가 나오게 된다. 



p.77

[사원]

#사원번호

*사원성명

*사원주민등록번호 


과연 '사원' 을 모두 붙이는 것이 좋을까 어떨까 라는 고민을 해보게 된다. 


p.79

[주문] 의 o고객번호는 Nullable 이 아닌 Not Null 속성이어야, 업무적으로 분리가 가능함

들어올 때도 있고 안들어 올 때도 있다면 현 상태의 테이블 구조를 변경하지 못하는 것이 일반적임



p.82

원장의 사전적 뜻과 업무적 쓰임의 의미는 무엇인가 ? 


원장 (元帳)[원짱]  

[명사] <경제> 

자산이나 부채, 자본의 상태를 표시하는 모든 계정계좌를 설정하여 분개장에서 "분개한 거래를 전부 기록"하는 장부.


등록원장이라면 등록 """내역""" 의 의미가 된다. 



[지점등록원장] 의 *지점등록일자 와

[지점] 의 *지점등록일자는 다른 의미를 갖게된다. 


[지점등록원장] 의 *지점등록일자 는 "등록자가 지점을 등록한 일자" 이며

[지점] 의 *지점등록일자는 지점의 "최초등록일자" 이거나 "최종등록일자" 라는 의미를 가지게 될 것이다. 


이렇게 된다면 [지점등록원장] 에서 동일지점코드를 읽어 최종 지점등록일자를 읽어서 최대값으로 가져와야 한다. 

하지만 현 모델은 PK 가 등록자ID 이다. 

만약 동일인이 동일지점에 대해 지점명을 바꾸는 경우가 발생한다면, (M&A 등) PK 중복을 피하기 어렵게 된다. 

내역의 발생이니 일련번호가 붙어야 하는 상황이다. 


p.83

그림7-9 의 [주소] 의 PK 는 고객번호 + 주소유형코드가 되어야 하겠다. 

동시에 관계선도 실수가 있다. 




%%본질과 소유  IS VS HAS VS DO

주소는 고객인가 고객은 주소륵 가지는가

나이는 고객인가 

이름은 고객인가

주문은 고객인가 고객은 주문을 하는가

생년월일은 고객인가 고객은 생년월일을 가지는(?)것인가 ? 원래의 특성인 것인가? 

당신은 조현기 인가? 조현기는 무엇인가? 눈 둘 코하나 입하나는 조현기인가? 아니면 조현기가 가지고 있는것인가 ? 

조현기가 가지고 있는 것이라면, 이를 가지고 있는 조현기는 도대체 무엇인가 ? 

이름인가 ? 그냥 존재함을 의미하는 것인가 ? 존재인가 ? 



이것이 엔터티와 속성에 대한 이야기이고 전부라고 할 수 있다. 


%%하나의 모델로 책 한권을 써버릴 수도 있겠다. 

  심오하고 디테일하게 실제 하는 모델러의 고민을 담아서 



%%데이터 모델링은 기본 요구사항을 주고

계속 변화를 주고 꺽고 비틀고 추가하고 없애고 외부와의 Interaction 을 일으키면서 

변화되는 과정을 거치면서 '어떤 모델이 나와야 하는지' 에 대한 고민과 기준이 정립된다. 



p.88

엔터티 정의, 철학이 필요한 시간




p.89

그림 8-2 잘못된 관점이 반영된 정보자산관리 모델

[임차정보자산] PK 인 #임차정보자산관리번호가 있고 

하위 엔터티들은 PK가 복합속성이면 1:N 이어야 함 그리고 ARC EXCLUSIVE 를 표현해 주는 것이 좋을 듯


하나의 임차정보자산관리번호가 특정 노트북 한대를 찍어서 의미하는 것이라면 



%%정규화는 Before 와 After 가 관리하고자 하는 정보가 일치해야 한다. (다만 방식의 문제라고 보는 것이 더 현명하지 않을까)



p.95

[교육과목] 그냥 과목은 안되나 ? 

[교육과정] 

[개설교육과정] 엔터티명, "교육과정개설" 은 어떤가 ? 

개설과 시작일자는 서로 매치가 될 수 있는가 ?

개설이라는 말에는 이미 '시작' 의 의미가 담겨있다. 

개설을 하는데 시간이 걸리는것 (지속시간)을 의미하지는 않을 듯 하다. 


'강의시작일자' '교육시작일자' 가 맞지 않을까? 

[개설교육과정]에서 부득이하게 강의실이 바뀌면 이는 다른 개설교육과정인가 ? (PK변경)



%%관계를 PK 로 일반속성(FK) 로 가져오는 경우의 본질적인 차이를 심층적으로 따져줄 것



개설(開設)[명사]

설비나 제도 따위를 새로 마련하고 그에 관한 일을 시작함. 

  


p126

소프트웨어 개발에 대한 단상과 모델링 전략



p.131

분류


%%분류 종류  로 나눈것 *분 ==> 부분집합을 의미 >>> 전체를 부분으로 나누었고 이를 모으면 원(전체)집합이 됨

cf. 분기 기간으로 나눈것



p.132

[등급이력]?

[공급자평가내역]  평가부여자ID  ? , 그냥 평가자ID 가 낫지 않나 

                  뭔가 어색한 속성명으로 보임



p.133

[온라인회원]  #최원번호 --> #회원번호



p.141

[Neighbor] 

관계선 - - - - --------<  로 되어야

ParentNeighborID 는 NotNull 이 아닌 Optional 로 되어야




p.160

[사원] - - - ------< [사원가족사항]

1. [사원가족] 엔터티명이 더 나은 선택일 듯 '사항' 이 굳이 필요한가

2. 1:N 의 관계임





속성명을 결정할 때 

엔터티의 명칭이 꽤 많은 의미를 담고 있다면(이미) 

굳이 속성명에 동일한 의미(엔터티명에서 표현된 의미)를 담을 것인가에 대한 고민이 든다. 




p.162

[관계자관계]

PK에는 관계유형코드 가 포함되어야 함

없는 경우 A 와 B 사이에는 반드시 하나의 관계만 존재할 수 있다는 업무규칙이 명시되어야 함.


[은행전사관계자] 의 데이터샘플값이 이상함  왜 이영희가 여러번 나타나는지 이해할 수 없음.(통합이라는뎅)




p.168

데이터 표준화의 목표는 결국 이음동의어와 동음이의어를 관리하는 것 ? 



%%표준화   원흥역 갈 때 나타나는 기괴한 "신호판" - 좌회전 은 표준화 된 걸까 ? ????




p.176

속성명 정의의 어려움과 표준용어 구체화 수준에 대해


p.179

ERD에서 관계선이 의미하는 것



#########################################################################

모델링을 실전적 실습적으로 다룰 수 있는 책이 필요함

표준화를 상세하게 적용하고 실천할 수 있는 Best Practce 를 기준으로 제시할 수 있는 것

#########################################################################

p174

고품질의 표준 데이터를 관리하려면 명확하고 구체적인 데이터 표준화 지침이 있어야 한다. 그 뿐만 아니라 그 지침을 바탕으로 개발자, 표준화 담당자, 메타데이터 관리시스템,,,

강조하고 싶은 점은 표준화는 열대어가 사는 어항과 같아서 잉크 한 방울만으로도 순식간에 오염되어 회복이 불가능하다는 사실이다. 따라서 이해관계자, 특히 표준화 담당자는 표준을 사수하려는 사명감을 가지고 끊임없이 노력해야 한다. 덧붙여 방대한 표준을 사람이 눈으로 일일이 확인하고 통제하는 것은 사실상 불가능하다.

메타데이터 관리시스템은 단순 자료 관리를 위한 시스템에 머물러서는 안 된다. 그 대신 표준 준수를 위한 다양한 정보를 제공하여 데이터 거버넌스의 중심이 되는 통제형 시스템이 되어야 한다. .... 문제가 있는 데이터는 신청단계에서 이미 표준 진입자체가 되지 않도록(규칙이 명확한 표준지침의 경우) 해주는 다양한 검사 로직이 탑재되어야 한다.

표준 등록 후 사후 처리 과정을 통해 정제하려면

 영향도 때문에 어려움을 겪는 경우가 많기 때문이다.”

 

p176

속성명 정의의 어려움과 표준 용어 구체화 수준에 대해

데이터 표준화를 담당하게 되면

표준 용어를 어느 정도까지 구체적으로 명명해야 하는가라는 질문을 자주 받는다.

내용, 서술내용, 고객서술내용, 고객서술특이내용 중 무엇이 최적인지 애매하기만 하다.,,,,,,

표준 용어 이름 칫기는 가능하면 구체적이되 간결하게 표현하는 것이 바람직하다.

구체적간결하게라는 표현이 상충한다고 느껴질 수도 있으나, 핵심 단어를 선별해서 조합하면 목표에 접근할 수 있다.

이와 더불어 정보 항목의 특성과 업무중요도에 따라 구체화 수준을 차등 관리하는 방법도 고려해볼 만하다.

구체화 수준의 정의와 예 :   0 / 1 / 2 / 3 / 4 / 5

속성 유형별 적절한 구체화 수준 :   0 / 1 / 2 / 3 / 4 / 5

%%메타시스템에 등록하는 표준화의 예를 (GOOD / BAD) 들어서 설명해 주면 실질적인 도움이 될 듯 함

-       일련번호, ^^ 번호

-       반려 처리사유에 대한 내용을 확인해 볼 필요가 있음.

 

 

Story14 : 관계선 긋기의 진정한 의미 p179

ERD 에서 관계선이 의미하는 것

관계는 물리적 실체가 존재하는 개념

-       관계가 있는데 표현하지 않거나,

-       반대로 관계가 없는데도 뭔가 있을 것 같아 선을 그어놓는 경우 모두 문제이다.

*구체적으로 어떤 경우에 대한 예시를 통해서 풀이해 주면 도움이 될 것 같음.

관계는 엔터티 사이에 존재하는 연관성으로,

모델에서는 관계선으로 표현되며 상위 엔터티의 주 식별자가 하위 엔터티의 속성으로 관리됨.

관계 : 결국 부모의 식별자가 전달된 속성으로 남는다.

       참조무결성관계가 있을 때만 관게선을 긋는다.

(그럼 Nullable 속성은, 여러 엔터ㅌ로부터 관계된 속성을 통합된 형태로 사용한다면

 

p193

[공통코드] [공통코드값] 엔터티간의 관계는 식별자관계이다. (PK 로 상속되었음) 관계수정필요