[생활코딩] 관계형 데이터 모델링 (22-25강의 : 정규화)

22.정규화 소개

• 관계형 데이터 베이스의 부모인 에드가 프랑크 커드 박사는 평범한 사람도 그가 제안하는 방법을 적용하기만 하면 천재적인 표를 만들수있는 레시피를 개발함. 이 레시피를 한국어로는 정규화, 영어로는 normalization이라고 함. normalization이라는 것은 정제되지 않은 데이터를 다시 말해서 표를 관계형 데이터 베이스에 어울리는 표로 만들어주는 레시피 이다.
  

• 위키피디아에서 가져온 표

• Unfortunately, 1nf, 2nf이런거 이중 unf는 un normalize form이라고 해서 정규화가 적용되어있지 않은 형태의 표를 의미 그리고 1nf라는 것은 first normal form이라고 해서 제1 정규형이라고 부름.

• 이 두가지 사이의 차이점은 atimic columns라고 하는 정규화 되어있지 않은 표에서 첫번째로 정규화된 표의 차이점은 각가의 컬럼이 아토믹해야된다. 즉 컬럼들이 하나하나가 아토믹하는 것은 제1 정규형을 만족시킨다고 할수있다.

• No partical dependencies라고하는 어떤 특성을 만족하면 제2정규형을 만족시킨다고하는 것임. 여기 있는 각각의 항목을 만족시킬 때마다 우리가 갖고 있는 표들은 이 정규형들을 만족시켜 가장 마지막 6nf를 만족시키면 그게 가장 이상적인 표가 된다는 것임

• 산업적으로 많이 사용되는것은 제 3정규형까지고 그뒤는 학술적으로 많이 사용됨 그래서 우리 수업에서는 제3 정규형까지 만드는걸 배울 것임.
  

• 상단 예시 표

• 위 표는 전혀 정규화되어있지 않은 폼임. 이 표는 타이틀과 타입이라는 두개의 컬럼을 묶어서 중복키로 또 프라이머리키로 지정해놓음. 이 각각의 행들은 이 두개의 컬럼을 통해서 식별된다.

• 그리고 색깔을 표시한 친구들은 미심쩍은 친구들, 하늘색으로 표시된건 하나의 컬럼에 여러개의 값이 있는 뭔가 좋지않은 냄새가 나는 친구들.

• 그리고 빨간 색은 계속 중복되는 애들… 바로 이러한 것을 관계형 데이터 베이스에 잘 어울리지않는 표라고 해서 un normalize form이라고 한다. 이것을 어차피 첫번째 정규형으로 바꾸고 그것이 끝나고 두번째 정규형으로 바꾸고 그다음 3번째 정규형으로 바꿔나가면서 관계형 데이터 베이스에 걸맞는 것으로 만들어 나갈것임

• 정규형에서는 한번에 원하는것을 선택적으로하는게 아니라 단계적으로 일종의 공정처럼 진행되는 방식이다.

• 23.제1 정규화

• 제 1정규화의 원칙은 atomic colums이다. 각 행에 또 각 컬럼에 값들이 하나하나가 원자적이어야한다….
  

• 영상이 끝나면 상단에 있는 first nirmal form 표를 만들게 될것임. 저건 이 강의의 결과물.

• 제 1정규화 원칙이 atomik colums 즉 각각의 컬럼의 값들이 값을 1개만 가져라라는 뜻이다. 그럼 행을 놓고 봤을 때 아토믹하지 않는것은 tag임. tag는 값을 2개를 가지고 있음. 그러면 여러분이 원하는 값 자체가 여러개의 값을 가지고 있는것 자체가 하나의 값이면서 더이상 쪼갤 필요가 없는 값이라면 문제가 없다. 그러나 이러한 연산을 하고싶으면 이 tag 컬럼은 문제가 있다.

• SELECTFROM topic WHERE tag = ‘free’ 하는 값을 가지고 있는 행을 원한다면 애는 사용할 수 없다. 그리고 마찬가지로 SELECTFROM topic ORDER BY tag 라고 했을때 우리가 첫글자를 중심으로 정렬을 하는거면 별 문제 없지만 free도 엄연한 값이라면 우리가 free를 기준으로 해서 정렬을 하고싶을수도 있는데 그렇게 할수없고 join과 같은 것들을 사용해서 다른 테이블과 join할때도 값이 저렇게 하나의 컬럼 안에 여러개 값이 들어가 있다면 조인을 하는 것이 어렵거나 불가능할것..

• 원소에 즉 각각의 컬러 맵 값이 1 이상이라면 다시 말해서 아토믹하지 않으면 여러 문제를 야기 시킬수있기 때문에 이걸 해소시킨 상태를 제 1정규형을 만족시키는 표다라고 하는것임.
  

• 이건 정보의 손실은 없지만 정보의 중복이 되기 때문에 바람직하지는 않음

• 제 1정규형을 만족시키긴 하지만 바람직하지는 않음. 

  

• 이것도 문제가 있다. 우리가 태그를 추가했다면 테이블의 컬럼 전체를 변경시켜야된다. 컬럼의 구조를 바꿔야된다. 값이 만약에 태그가 하나밖에 없다하면 여기에는 null이 오는 낭비가 되어버림.

• 가장 좋은 방법은 표를 쪼개라
• 그러기 위해서 우리는 토픽이라는 테이블과 토픽안에있었던 태그라고 하는것을 테이블로 쪼갤것인데 토픽과 태그사의 관계를 그려보겠다.
• 토픽에게 태그는 몇개있냐? 하나의 토픽이 여러개의 태그를 가질수있다. 그리고 태그는 몇개의 토픽? 하나의 태그는 여러개의 토픽을 가질수있다. 그래서 topic과 tag는 cardinality가 N:M이라고 할수있다. N:M은 테이블을 쪼개는 것만으로는 안되고 맵핑 테이블을 만들어줘야된다.
• 이 태그는 그글의 제목에만 의존하고 있다. 이 글이 종이책인지 온라인컨텐츠인지랑은 상관없이 그냥 그 제목이 mysql이면 rdb 관계형 데이터베이스 면서 무료다 라는 뜻이잖아요 그러니까 토픽자체는 중복키를 프라이머리키로 가지고 있지만 그중에서 title 만을 키로 가져올거다. 그다음 토픽과 태그를 맵핑하니 태그의 id를 가져옴 그래서 이 두개를 프라이머리키로 만든다. —> topic_tag_relation의 프라이머리키
• 기존의 태그에 있었던 아토믹하지않은 컬럼의 상태를 해소할수있게 됨 즉 제1 정규형을 만족시키게 됨.

24.제2 정규화

• 제 2정규형을 만족시키기 위해서는 테이블 상에 부분종속성이 없어야한다는 조건을 만족시켜야된다. 여러분이 갖고 있는 표의 기본키 중에 중복키인 것이 없다면 다음수업으로 넘어가두된다. 중복키가 있다면 이수업을 살펴봐야됨

• 제 2정규형을 작업하는작업실로 이동!
• 제 2정규형을 만족시키면 상단의 저 토픽 타입이 추가될것임.
  
• 토픽 테이블을 보면 저 붉은색으로 칠한만큼의 중복이 발생함. 중복이 발생하는 이유는 부분 종속성때문임. 색깔로 표시한 행은 mysql 이라는 제목하나에 의존하고 있음. 즉 프라이머리키를 통해 이 행을 얻어낼수있다. 즉 타입이 뭐냐랑은 상관이 없다는 말. 즉 disription부터 author_profile까지의 이 컬럼들은 타이틀이라고 하는 컬럼에만 부분적으로 종속되고 있다. 이 토픽이라고하는 테이블의 존재의 의의는 무엇이냐?
• 이중에서 바로 이 프라이스 때문이다. 가격은 그 컨텐츠가 페이퍼냐 온라인이냐에 따라 달라진다. 즉 이 토픽이라고하는 저 표는 사실 타이틀 타입 그리고 프라이스를 위한 표이지 여기 있는 붉은색을 위한 컬럼들이랑은 상관이없다.
• 이 문제를 해결하기 위해서는 부분적으로 종속되는 컬럼들만 모으고 전체적으로 종속되고 있는 컬럼을 따로 쪼개면 됨, 그래서 토픽이라는 테이블 하나 만들것이다.
• 토픽이라는 테이블은 부분적으로 종속되는 정보들만 가져올것임. 그래서 타이틀만 카피해서 붙여넣음.
  
• Mysql 두번째 행은 타입이라는게 없어서 완전 중복이기 때문에 삭제
• 그다음 price는 타이틀과 타입에 의존하기 때문에 뒤에 붙인다.
  
• 뒤쪽에 있는 다른 테이블들도 카피해서 붙임.
• 이렇게하면 중복이 사라진다아아앙! 그럼 제 2정규형을 만족시키는 표를 만드는 핵심적인 방법인 부분종속성을 제거하는 방법을 살펴봄


  25.제3 정규화

• 3번째 정규형을 만족시키기 위해서는 no transitive dependencies라고 해서 여기서 트랜지티브는 타동사/다른 대상에게 무엇인가를 이행하다 뭐 이런 뜻을 가지고 있는게 트렌지티브 디펜덴시스 그래서 한국어로는 이행적 종속성이라는 어려운 이름을 가지고 있는단어다. 어떻게 제3종속성을 만족시키는지 보자.
• 제 2정규형까지 마친 상태의 표를 제 3정규형의 경우로 전환하게 되면 topic이라고 있는 하나의 테이블에서 author라고 하는 테이블이 독립해서 분리가 되고 topic 테이블은 author_id를 통해서 autthor의 id에 의존하게 될것임.
• 행은 title이라고하는 기본키에 종속되어있는 것 즉 mysql이 행전체를 대표하는 것 잘 보면 author_id라고 하는 컬럼의 값은 당연히 타이틀에 종속되어있긴 한다. mysql이기 때문에 저자가 1번이 되니까. 근데 잘보면 author_name과 author_profile은 author_id 값에 의존하고 있다. 그러나 author_id는 title에 의존하고 있다. 이런 관계를 이행적 종속성이라고 하는데 이건 뭔가가 잘못되고 있는것 이 두개의 행은 중복되었기 때문!!

• 이 노란색부분인 중복을 만들어낸 부분을 카피해서 author라고 지어줌.
  
• 각각의 행이 어떤 author 테이블의 id인지를 가리키는것도 필요해서 토픽 테이블을 만든다.
  
• 이렇게 되면 author테이블에 있었던 우리가 싫어하는 중복을 이렇게 없앨수있

다. 그럼 둘다 똑같으니까 지운다.

• 저기 토픽의 author_id값이 중복되지만 우리가 프라이머리 키또는 foreign key는 중복이라고 치지않기 때문에 우리는 중복이 제거된 표를 만들게 된것임. 나머지꺼는 그대로 가져와서 붙여넣기 하면 된다. 그럼 우리가 가지고 있는 표들은 제 3정규형까지 만족시키게 됨.

• 그런데 여기서 author_id 라고하는 저 author들을 대표하는 컬럼들은 없을 가능성이 클것임. 그런 경우에는 이행적 종속성이 잘 눈에 보이지 않을수있지만. 이렇게 생각하면 좋을거같다.만약에 author_id가 없었다고 하더라도 여기에 성격이 같은 컬럼들은 내부적 암시적으로 자신의 식별자를 가지고 있을것이다. 그럼우리 눈에는 잘보이지 않겠지만 걔 역시도 이행적 종속성을 가지고 있는 것임. 그럼 그때 분리를 하면서 분리할때 id 값을 구체적으로 줘서 둘사이에 primary key와 foreign key로 이렇게 연결을 시켜주면 된다.
  

• 우리의 무의식이 의식보다 훨씬 똑똑하다. 위 상단의 표처럼… 컬럼의 이름앞에 author가 프리픽스로 컬럼의 접두사로 붙어있다. 우리의 의식은 모르는 상태에서도 우리의 무의식은 자기도 모르게 요 컬럼 3개가 같은 성격의 컬럼이다라는 것을 알고 있는것. 그래서 우리가 무의식적으로 쭉 만든다음 의식적으로 무의식이 한 그 어떤 선택들을 보고 그걸 이용해서 어떻게 쪼개면 될것인가라는 전략을 만들어 낼수도 있다. 프리픽스가 있다라는 것은 무언가를 독립시킬 가능성이 굉장히 크다는 얘기고 얘가 실제로 이렇게 중복을 발생시키면 우리가 아까 살펴봤던 테크닉에 따라 얘를 분리시키면 되지않을까?라는 생각이든다!