RDB: [관계형데이터모델링] 시리즈 내용정리

[관계형 데이터 모델링] 내용정리
from Youtube "생활코딩 - 관계형 데이터 모델링" 
uploaded in July 2019 by 이고잉 


1. 모델과 데이터 모델링
  1) 모델: 어떤 목적을 가지고 진짜를 모방한 것. 따라서 목적에 부합하는 모방이 좋은 모델이다.

  2) 데이터 모델링이란 복잡한 현실을 컴퓨터에 담는 방법.	
	‘현실에서 컴퓨터로’ 이사를 하는 이삿짐 센터
	‘업무를 데이터베이스’로 이사시키는 작업


2. 데이터 모델링의 순서도
  	순서:  업무파악 -> 개념적 데이터 모델링 -> 논리적 데이터 모델링 -> 물리적 데이터 모델링


  1) 업무파악 (w/ 기획서)
       	우리가 하려는 그 ‘일’ 에 대한 파악. 기획서 개입.

  2) 개념적 데이터 모델링 (w/ ERD)
	현실의 업무에서 개념 찾아내는 것. 
	하려는 일에 어떠한 개념이 있고, 각각의 개념은 어떻게 상호작용 하는가 심사숙고 하는 것.

  3) 논리적 데이터 모델링 (w/ 표)
	개념들을  관계형 DB에 맞게 구성하는 것.관계형 데이터 DB에 맞게 구성. 개념을 표로 전환하는 작업.

  4) 물리적 데이터 모델링 (w/ sql 코드)
	DB 제품을 선택하고 그에 최적화된 코드를 작성하여 실제 표로 만드는 것. 
	한마디로 데이터 모델링이란, 문제를 현실로부터 뜯어내서 고도의 추상화를 거쳐 컴퓨터라는 새로운 현실로 옮겨담는 작업. 


3. 말의 힘을 불신하라
	익숙해진 client로부터 필요한 정보를 끌어내는 것은 노하우와 노력이 필요하다.
	전문지식과 인간관계가 동시에 필요.
	UI를 client와 함께 그려보는 것을 통해 원하는 것을 분명히하고 생각일치시켜 나가는 작업
	“말의 힘을 불신하라” : 말의 기능을 불신하라는 것. 말을 불신할수록 말의 신뢰성은 높아지는 역설.
	기획서는 그 테크닉의 산물.


4. 개념적 모델링
	  - 현실에서 개념을 추출하는 필터를 제공함
	  - 개념에 대해서 다른 사람들과 대화하게 해주는 언어
	  - 이러한 목적을 이루게 해주는 하나의 도구가 ERD(Entity Relationship Diagram)
	  - 현실을 3개의 관점으로 볼 수 있는 파인더
		1) 정보 : 정보를 발견하고 다른 사람에게 표현할 수 있게 도와줌
		2) 그룹: 서로 연관된 정보를 그룹핑해서 인식, 이것을 표현할 수 있게 도와줌
		3) 관계: 정보, 그룹 사이의 관계를 인식하고 이것을 표현할 수 있게 도와줌.
	  - 즉, ERD는 현실로부터 개념을 인식하는 도구이면서 다른 사람도 알아볼 수 있게 표현하는 도구.
	  - 또한, 매우 쉽게 표로 전환 가능.


5. RDB다운 개념의 구조
   1) 거대 단일 테이블의 문제점
	 - 중복이 발생한다.
	 - 컴퓨터 자원의 낭비
   2) 평면적 RDB의 특성
	 - 내포관계를 허용하지 않는다
	 - 주제에 따라 속성들, 데이터를 그루핑할 수 있다.
	 - 컴퓨터의 자원을 아낄 수 있다.
	 - JOIN 등의 매커니즘으로 필요한 정보 합성할 수 있다. 


6. ERD의 구성요소 (예시로 설명)
	 - Entity : ‘댓글’, ‘글’, ‘저자’. (후에 table이 된다)
	 - Attribute 속성 : ‘제목’, ‘생성일’, ‘본문’ 등의 실제 데이터. 글이라는 entity는 실제 데이터가 아님. 
	   제목, 생성일, 본문이라는 실제 데이터. 즉, 속성들을 그루핑한 것이 글이라는 entity. (후에 표의 column이 된다)

   	   * entity를 디렉토리, attribute를 파일에 비유하면, entity는 파일만 담을 수 있고 디렉토리는 담을 수 없는 제한적인 디렉토리다. 
	     다른 디렉토리를 품을 수 없는 평면적인 디렉토리. 
	     
	 - Relation 관계 : entity간의 연관성. (후에 PK, FK이 된다) 
	 - Turple 행 : (후에 row 가 된다)


7. entity 정의
	 - application 하나의 건물에 비유하면, UI는 옥상, DB는 지하.
	 - 이 둘의 관계는 인과관계. 정보입력하는 UI가 원인이 되어서 DB 정보 변경하고, 동시에 DB라는 원인에 의해서 UI 내용이 표시되는 결과. 
	   이 두가지 인과관계를 쌍방에서 순차적으로 점검해야 좋은 모델링.
	 - 기획자와 구현자가 다르다면 데이터 모델링까지는 협업해야 한다.
	 - 데이터 모델링은 기획에, 기획은 데이터모델링에게, 놓치면 안되는 중요한 틈을 보여주는 역할.
	 - 기획서에서 entity 찾아내기!!


8. 속성정의
   글 (entity 1)  
   속성1 제목
   속성2 본문
   속성3 작성일

   저자 (entity 2)
   속성1 이름
   속성 2 자기소개
   속성3 가입일

   댓글 (entity 3)
   속성1 본문
   속성2 작성일


9. 식별자 지정
   식별자(identity) 원하는 대상을 정확히 타겟팅하기 위함.
   따라서 누구도 같은 값을 가져서는 안된다. 

   <예시> user_id, email, national_id, name, city 
	이중 식별자로서 사용가능한 것은 user_id : 후보키(candidate key)
	이중 우리가 user_id를 식별자로 결정했다면: 기본키(primary key)
	나머지 email, national_id는 대체키(alternative key)
	그 외에 중복키(composite key)도 존재: 예) 직원번호(emp_no) +부서번호(dept_no)

        위의 책의 예시에서는 자연스럽게 기본키가 될 수 있는 속성이 없기에, 
        인조/대리키(such as 글 아이디, 댓글 아이디, 저자 아이디) 만듦


10. Relation(Entity간의 연결)
    RDB는 기본키와 외래키(foreign key)가 연결되는 것을 통해서 실제로 구현된다.


11. Cardinality(기수)
    담임-반의 관계: “각선생님은 한반만을 담임한다”, “각반에 담임은 하나다” =>  1:1
    저자-댓글의 관계: “저자에게 댓글은 여러개다”, “각 댓글은 하나의 저자만 존재” => 1:N
    저자-글의 관계: “저자에게 글은 여러개다”, “각 글은 여러 저자가 존재” => N:M 


12. Optionality(서수)
    저자-댓글의 관계 : 
    “저자는 댓글을 작성하지 않을 수도 있다” (저자에게 댓글은 옵션) optional
    “각 댓글은 반드시 저자가 있다” (댓글에게 저자는 필수) mandatory
    따라서 저자와 댓글의 관계에는 cardinality, optionality 두개가 모두 존재
    * 헤깔릴 때에는 Entity Relational Diagram Helper (erd.yah.ac) 참조하라!!


13. 논리적 데이터 모델링
    RDB 패러다임에 어울리는 가장 이상적인 모습으로 개념을 정리하는 것이 포인트
    Mapping Rule (ERD를 통해 표현한 내용을 RDB에 맞는 모습으로 전환할 때 사용할 수 있는 방법론)
    entity -> table
    attribute -> column
    relation -> pk, fk

    ERD -> RDB 로 전환     
    ER master(ermaster.souceforge.net), 구글스프레드, 엑셀 등 사용

    entity -> table 만들기(foreign key가 없는 entity부터 만드는게 수월)
    attribute- > column 추가. primary key부터(auto-increment, int 등 제약조건 설정, 즉 도메인 설정) 
    relationship-> pk, fk 연결. cardinality 중요.

    저자(휴면저자가 누군지 몰라도 됨)와 휴면저자(저자에게 의존. 저자가 누군지 알아야 함)의 관계
    부모 테이블(혼자서도 잘 지낼 수 있는)과 자식 테이블 (혼자서는 잘 지낼 수 없는 의존하는)의 관계
    부모에 primary key, 자식에 foreign key 설정


14. N:M 처리 (Youtube 5.5.2 다시보기) 
    mapping table


15. Normalization (정규화)
    정제되지 않은 데이터(표)를 RDB에 어울리는 표로 만들어주는 레시피
    UNF(unnormalized form 정규화가 적용되지 않은 표)와의 사이에 차이를 만드는 
    1NF(1st formal form 제 1정규형, 첫번째로 정규화된 표)의 특성은
    '각각의 column이 atomic 해야한다 것'.
    
    no partial dependencies 만족시키면 제 2정규형.
    산업적으로 많이 사용되는 것은 제 3정규형까지.
    bit.ly/2wV2SFj


16. 제1 정규화
    중복되는 topic title과 tag의 M : N cardinality 해결하기 위해 mapping table 만들어야 함
    tag를 tag id에 상응하는 name으로 정리해주고,
    topic_title과 tag_id를 상응시키면 atomic한 column 만들수 있다.


17. 제2 정규화
    no partial dependencies

    '종속성이 없어야 한다'는 조건 만족시켜야 함.
    이것을 만족시킨다면 그 다음 단계로 가면 된다.

    예제에서, topic이라는 테이블은 title, type, price를 위한 표이지 나머지 column과는 상관없음.
    부분적으로 종속되는 column들 모으고, 전체적으로 종속되는 column들 따로 쪼개는 방식으로 해결.


18. 제3 정규화
    no transitive dependencies(이행적 종속성이 없어야 한다)는 조건 만족시켜야 함.
    author_id 는 title에 종속돼 있으나, author_name, author_profile은 author_id에 종속돼 있음. 이것이 바로 이행적 종속성. 


19. 물리적 데이터 모델링
    이상적 표를 현실적인 표로 만드는 것. 이 단계에서는 성능이 중요함.
    ‘find slow query’ 등으로 병목을 찾아야 함.
    이때 최후의 보루는 이상적으로 정규화된 이 표의 구조를 쪼개는 것, 즉 역정규화 or 반정규화(denormalization). 
    하지만 혹독한 대가를 치뤄야 하므로 대안을 먼저 찾아보는 것이 바람직.
    대안의 첫번째는 index. 행에 대한 읽기 성능을 비약적으로 향상시키는 반면 쓰기를 희생시킴.
    두번째는 application영역에서 캐쉬(cache) 시도해서, 입력에 따른 실행결과를 저장해 두었다가 
    나중에 동일한 입력이 들어왔을때 사용하는 것을 통해서 DB 부하유지하는 방법.


20. Denormalization(역정규화)
    정규화를 통해 만든 이상적인 표를 성능이나 개발편의성을 위해 조작, 구조바꾸는 것. 
    기본적으로 정규화란, 쓰기의 편리함을 위해 읽기의 성능을 희생하는 것. 
    표들이 여러개로 쪼개지게 되고, 표를 다시 사용할때에는 join을 통해야 하는데, 그 join은 읽기의 성능 하락시킴. 
    이때 여러가지 해보고 역정규화, 즉 표의 구조를 바꾸는 작업 시도해 보아야 한다. 
    일단 정규화를 한다음에 역정규화하는 것이지, 아예 정규화도 하지 않은 표가 좋다고 볼 수 없음. 
    또한 정규화한다고 해서 반드시 성능이 떨어지는 것도 아님. 
    http://bit.ly/2WLMCko
    
    하나의 표 안에서 column바꾸기
    하나의 표를 여러개로 쪼개기
    테이블과 테이블 사이의 관계성 조작해서 일종의 지름길 만드는 것
    역정규화는 엄밀한 규칙이 있는 것이 아님. 기법에 대한 sample만 있을 뿐.


21. 역정규화1 - 칼럼 조작해서 join 줄이기
    중복이 발생하게 됨. 하지만 속도가 빨라짐.
    중복과 같이 정규화하기 전에 가졌던 문제를 갖게됨. 복잡도가 높아지고 프로그램이 고장날 확률도 높아짐. 그럼에도 성능을 위해서 고려할 수 있음.


22. 역정규화2 - 칼럼 조작해서 계산 줄이기
    얻는 것과 잃는 것의 trade-off 발생. 그 둘의 경중 따져서 판단해야 한다.


23. 역정규화3 - 칼럼을 기준으로 테이블을 분리하기

RDB(egoing).txt
Displaying RDB(egoing).txt.