논리적 데이터 모델링과 물리적 데이터 모델링

www.youtube.com/watch?v=1d38YZKCM88&list=PLuHgQVnccGMDF6rHsY9qMuJMd295Yk4sa

이 글은 생활코딩님의 '관계형 데이터 모델링' 유튜브 재생목록 영상들을 바탕으로 작성되었습니다.

 

논리적 데이터 모델링이란

 

논리적 데이터 모델링은 뽑아낸 ERD를 관계형 데이터베이스 모델에 어울리게 잘 정돈하는 것이다.

 

이때 핵심적으로 활용하는 것이 Mapping Rule 이다. ERD를 관계형 데이터베이스로 전환할 때 사용하는 방법론이다. 이를 통해 철저하게 전환을 처리할 수 있기에 필요하다.

 

개체 -> 테이블

속성 -> Column

관계 -> PK, FK

 

단순히 테이블의 이름, Column, key들을 명시하는 것뿐만 아니라 들어가는 데이터들의 길이, 타입 등을 정의하고, 제한하는 것까지를 포함한다.

 

그게 끝나면 이제 관계를 나타내는 작업에 들어가는데, 가장 중요한 것은 Cardinality를 처리하는 것이다.

 

 

Cardinality 처리

 

일대일(1:1) 관계의 경우

 

Mandatory 테이블(의존하고 있지 않은 테이블 - 부모 테이블)에  PK를, 그렇지 않은 테이블(자식 테이블)에 FK를 주면 된다. 이렇게 하면 이 두 테이블이 연결된다.

 

일대다(1:N) 관계의 경우

 

까치발이 향하고 있는 쪽, 그러니까 여러개의 테이블과 연결되는 테이블 쪽이 FK를 가지도록 설계한다.

 

다대다(N:M) 관계의 경우

 

단순히 한쪽에 FK를 주는 것만 처리하면, 하나의 행이 특정 FK 속성값을 여러 개 가지게 되는 문제가 생긴다. 이러면 JOIN 도, SELECT도, 모두 제대로 이루어지지 못하게 된다.

 

그래서 둘을 중개해주는 테이블이 필요하다. 이를 Mapping Table 혹은 그냥 연결 테이블이라고 부른다.

 

그 테이블의 이름은 관계의 이름으로 짓는다.

이 테이블을 두개의 테이블을 중재하며, 각 테이블 모두에게 FK를 전달 받는다. 이 FK 는 연결 테이블 안에서는 중복될 수 있다. 이 두개의 FK가 행마다 결합되어서, 고유한 키가 된다.

 

 

 

 

 

정규화

에드거 커드 박사가 만든 '정규화(Normalization'는 정말 평범한 사람도, 모든 필요한 원칙이 모두 지켜진, 양질의 테이블을 제작할 수 있는 방법론을 뜻한다. 이 방법론은 구체적으로 설명하자면, 정제되지 않은 현실의 데이터를, 관계형 데이터베이스 형성에 걸맞는 형식의 테이블로 정리해주는 방법론이라고 할 수 있다.

 

방법론이라고 해서 어떤 일련의 과정을 의미하는 것이 아니다. 여러가지 '이상적인 테이블'을 위한 조건들이 있고, 그 조건들을 어느 정도나 만족하고 있느냐에 따라 비정규화 테이블, 1,2,3 정규화 테이블로 나뉜다.

 

 

제 1 정규화

• 원칙 : Atomic Columns

각 셀의 값들 하나하나가 모두 '원자적'이어야 한다. 즉, 어떤 셀이든 간에 셀 하나에 두개 이상의 값이 들어가 있어서는 안된다. 이러면 JOIN, SELECT 문도 이 셀을 지닌 행에 대해서 동작하지 못할 것이다.

 

• 해결책 : 이러한 셀이 있을 경우, 그 셀을 분리하기 위해 별도의 행 혹은 열을 하나 이상 만들 수 있다. 하지만 이는 해당 테이블의 중복 혹은 비효율성을 낳는다. 따라서 이러한 경우에는 테이블을 쪼갠 후, 둘의 관계에 따라 FK를 주던가, 연결 테이블을 생성해서 연결시키도록 한다.

 

제 2 정규화

• 원칙 : No Partial Dependencies

테이블은 '부분 종속성'이 없어야 한다. 즉, 테이블에 '중복키'가 존재해서는 안된다. 중복키의 존재는 다른 데이터들의 중복 또한 일으킬 수 있다. 테이블 상에서는 기본키 혹은 다른 후보키가 같더라도 특정 열의 데이터가 서로 다르기 때문에 서로 구분될 수 있는 행이 테이블 안에 공존할 수 있지만, 그 두 행이 서로 동일하게 지닌 중복키에 맞추어 집어넣어진 여러 데이터들은 그 중복키에 의존성을 가지고 있으므로 데이터 중복이 쉽게 일어나게 되는 것이다.

 

• 해결책 : 부분적으로 중복키에 종속되는 열들과 그렇지 않은 열들을 쪼개어 두개의 테이블로 만드는 것이다. 두 테이블 모두 해당 종속키를 가진다.

 

 

제 3 정규화

• 원칙 : No Transitive Dependencies

'Transitive' 는 '이행적'이라는 뜻으로, 이행적 종속성이 없어야 한다는 의미이다. 어렵게 들리겠지만 제 2 정규형 테이블까지 완성했다면 행의 기본키의 값이, 해당 행 전체를 대표하게 된다. 하지만 꼭 그런 것은 아닐 수 있다. 특정 열들의 데이터들은 해당 기본키에 의존하는 것이 아니라, 다른 특정 열의 값에 의존하는 것일 뿐일 수 있다. 예를 들어 책이라는 테이블이 있다면 그 테이블의 행의 저자 이름, 저자 나이 등은 저자 ID 에 의존하고 있지, 책 ID에 의존하는 것은 아닌 것이다. 하지만 그 특정 열의 값이 기본키에 의존성을 가지고 있기 때문에 결국 기본키에 모든 열들이 의존하는 것과 같은 일이 일어나는 것이다. 이러한 관계를 이행적 의존성이라고 한다. 이행적 종속성은 데이터의 중복을 일으킬 수 있기에, 이를 주의해야 한다. 하지만 여기서 문제는, 해당 행이 저자 ID 와 같은 분명하게 보이는 이행적 의존성을 발생시키는 요소를 가지고 있지 않을 수 있다는 것이다. 그럼에도 저자 이름, 저자 나이와 같은 열들은 이행적 의존성을 지니고 있다고 봐야하기에, 만일 행의 특정 열들이 공통적인 속성으로 묶이는 것처럼 보이는 지를 체크하여 이행적 종속성이 있는지를 검사해야 한다.

 

• 해결책 : 이행적 의존성을 발생시키는 후보키와, 그 키에 의존하는 열들을 또 다른 테이블로 분리시킨 후 연결시킨다. 이러면 외래키의 중복은 일어날 수 있지만 이는 중복으로 간주하지 않는다. (이행적 의존성을 발생시키는 후보키가 행 안에 보이지 않는다면 분리 후 생성해야 하고, 외래키로 기존의 테이블에 넣어줘야 한다)

 

물리적 데이터 모델링이란

논리적 모델링까지가 이상적인 테이블을 만드는 것이었다면, 물리적 데이터 모델링은 이제 이렇게 만든 테이블들을 실제 데이터베이스 상에 구현하는 것을 의미한다. 제일 좋은 방법은 그냥 그대로 구현해버리는 것이다. 그리고 그 후에, 어디가 느려지고 어디가 느려지지 않는지를 구분하여 그 병목을 해결하는 것이 바람직한 문제 해결 방향이다.

 

이러한 방법론 중 하나로 'find slow query'라고 불리는 것이 있다.

 

이제 느려지는 지점을 찾았다면 성능을 높이기 위해 여러 방법을 수행해 볼수 있는데, 최후의 방법으로는 이상적으로 구조화된 테이블에 손을 대는 '역정규화(Denormalization) - 혹은 반정규화'를 수행하는 것이 있다.

 

역정규화 이전에 시도해볼만한 방법으로는 'index'를 집어넣는 것이다. 하지만 이는 '읽기' 성능을 빨라지게 할 수는 있어도 '쓰기' 성능을 크게 저하시킬 우려가 있다. 왜냐하면 쓰기가 이루어질 때마다 입력된 정보들의 인덱스를 다시 붙여주는 작업을 해야할 수 있기 때문이다. 인덱스를 붙여야 하기 때문에, 저장 공간을 어느 정도 희생해야 하는 문제점도 있다.

 

그 다음 방법은 클라이언트 사이드에서 'cache'와 같은 방법을 통해 성능을 향상시키는 것이다. 이 모든 방법을 수행한 뒤에도 서비스가 느려지는 부분이 해결되지 않았다면 혹은 개발의 편의를 위해 선택하는 방법이 역정규화이다.

 

 

 

역정규화

기존의 정규화는, '쓰기' 성능을 위해 '읽기' 성능을 희생시키는 방법이라고 말할 수 있다. 왜냐하면 정규화를 통해 표들이 여러개로 쪼개지고, 이를 JOIN하는 처리 시간과, 늘어나는 데이터 때문에 읽기가 더 오래걸리기 때문이다.

 

하지만 일반적으로는 정규화가 그렇게 크게 읽기 성능을 떨어뜨리지 않는다. 또한, 시스템의 효율성을 위해서 정규화를 마친 이후에, 부분적인 역정규화를 수행하는 것이 맞다.

 

역정규화는 정규화와는 다르게 어떤 엄밀한 규칙이 있는 것이 아니라, 여러 기법들이 있을 수 있다. 그러니 어떠한 방법에 절대성을 부여하는 것은 옳지 않다.