🧐

관계형 데이터베이스 좀 더 이해하기

Created

2021/03/20 09:18

최적화 이전에 알아야 할 것들

우리가 결국 원하는 것은 DB가 고장나지 않고 빠르게 동작하는 것이다. 이를 위해서 인덱싱, 파티셔닝, 캐싱등의 기법들을 이용하고 SQL을 튜닝(최적화)한다.

하지만 그 이전에 이런 기술들이 어떤 원리로 동작하는지 기반이 되는 지식들이 있다. 이러한 이론을 살펴보자.

1. 관계형 모델

관계형 모델은 수학의 집합론에 근거하여 실제 세계의 데이터를 관계라는 개념을 사용해 표현한 데이터 모델이다.

그리고 관계형 데이터베이스는 관계형 모델이라는 논리적인 컨셉으로 만들어졌다. 이 말이 어렵게 느껴질 것만 같지만 비유하자면 자동차를 응용 프로그램으로 구현한 것과 같다. 자동차는 엑셀을 밟으면 속도가 증가하고 시간에 따라 가속 한다. 응용 프로그램에서 이를 프로그램으로 구현할 수 있다.

마찬가지로 관계형 데이터베이스는 관계형 모델이라는 현실의 개념에서 착안하여 만든 응용프로그램이라고 볼 수 있다.

이 때, 중요한 포인트는 관계형 데이터베이스는 관계형 모델이 아니라는 것이다. 어디까지나 최대한 비슷하게 만들었지만 응용 프로그램은 모든 예외에 대처할 수 없다. 이 때문에 우리는 관계형 데이터베이스를 사용함에도 불구하고 관계형 모델이라는 강력한 데이터 모델을 사용하지 못하는 경우가 발생한다. 이는 곧 성능을 떨어뜨거나 정합성을 잃어버리는 등 RDB의 장점들을 놓치기 쉽게 만든다.

- 집합론

수학에서, 집합(集合, 영어: set)은 특정한 조건에 맞는 원소들의 모임이며, 명확한 기준에 의하여 주어진 서로 다른 대상들이 모여 이루는 새로운 대상이다. 어떤 대상이 집합에 속하는지 여부는 명확해야 하며, 집합 위에는 순서나 연산 따위의 구조가 주어지지 않는다. - 위키백과 -

관계형 모델은 집합론을 기초로 만들어진 개념이다. 그렇기 때문에 집합을 아는 것이 곧 관계형 모델을 이해하는 것과 다름이 없다.

위의 정의를 다시 한번 정리해보자.

•

특정한 조건에 맞는 원소들의 모임

•

명확한 기준에 의하여 주어진 서로 다른 대상들이 모여 이루는 새로운 대상

•

어떤 대상이 집합에 속하는지 여부는 명확

•

집합 위에는 순서나 연산 따위의 구조가 주어지지 않는다

특정한 조건에 맞는 원소들의 모임이나 명확한 기준에 의하여 주어진 서로 다른 대상들이 모여 이루는 새로운 대상와 같은 문장은 당연하게 여겨진다. 실제로 where API를 이용하여 특정한 조건을 검색하며 이를 통해 기존의 테이블에서 새로운 테이블을 생성해낸다.

반면 네 번째 정의는 order by 나 count(*) 등의 조회 API를 완전히 부정한다.

그리고 마지막 남은 세 번째 정의는 조금 모호하다.

- 어떤 대상이 집합에 속하는지 여부는 명확해야 한다.

어떤 대상이 집합에 속하는지 여부가 명확하다는 것은 모른다라는 답이 없다는 것을 의미한다.

예를 들면 1반에서 키가 큰 남자를 조회해야 한다고 가정하자. 이는 명확한 기준이 없는 명제일 뿐만 아니라, 그 결과를 알 수 없다. SQL에서도 역시 이러한 값을 조회하는 것은 불가능하다. 명확하게 170이상 혹은 180이하 라는 기준이 필요하다.

나는 위의 예제가 당연하게 느껴졌다. 모른다는 것이 얼마나 이상한 요청이며, 그 결과가 유해한 것인지도 말이다.

그런데 지금까지 나도 모르는 사이에 유해한 것처럼 보이는 모르는 값을 데이터베이스에 마구 축적하고 있었다.

- NULL의 오해

데이터베이스의 NULL은 값이 아니고 요소가 무엇인지 모르는 즉, 알 수 없는 표시이다.

사용하는 어떤 RDB라도 좋다. 결과가 존재하지 않는 count와 avg 쿼리를 각각 실행해보자.

아래의 예시는 100억원보다 비싼 상품을 집계하여 조회하는 쿼리이다. 그런 경우도 물론 있겠지만, 우리 예시에는 그런 비싼 물건은 유감스럽게도 판매하지 않는다.

select count(price) from product
where price > 10000000000
select avg(price) from product
where price > 10000000000
SQL

위의 결과는 count에는 0 , avg에는 null을 각각 반환한다.

100억원 이상인 상품은 0개임이 분명하다. 하지만 0개의 상품의 평균은 0이 아니다. 수학에서 역시 0으로 나눌 수 없다. RDB에서는 조회할 대상이 없기 때문에 그 답을 알 수 없다. 라는 평가를 한다.

그렇기 때문에 NULL을 반환한다.

제약 API (where)에서 NULL은 IS 혹은 IS NOT등을 사용하는 것 역시 NULL이라는 특수한 표시를 별개로 처리해야 하기 때문이다.

나는 NULL을 없다의 의미로 자주 사용했었다. 예를 들면 price의 값으로 null을 넣는 것이 그러하다.

하지만 이는 상품의 가격이 없다. 가 아닌 상품의 가격을 모른다. 로 해석되어야 맞다.

- order by, count(*), NULL 은 모두 관계형 모델에 적합하지 않다.

우리가 관계형 모델의 장점을 100% 얻기 위해서 위와 같은 키워드들은 사실 모두 적합하지 않다. 그렇다고 해서 이러한 키워드들을 모두 사용하지 않을 수는 없다. 다만 이러한 것들이 관계형 모델을 무너뜨린다는 사실을 안다면, 적재적소에 사용할 수 있는 힘을 기를 수 있다. 우리는 가능한 관계형 모델을 지키며, 필요한 순간에는 이를 벗어나서 기능의 편리함과 성능을 필요한 만큼 얻어 갈 수 있어야 한다.

2. 정규화

데이터베이스의 정규화에 대해선 많이들 들어봤을 것이다.

데이터베이스에서 정규화가 필요한 이유는 다음과 같다.

•

불필요한 데이터(data redundancy)를 제거해 불필요한 중복을 최소화한다.

•

삽입/갱신/삭제 시 발생할 수 있는 각종 이상 현상(Anomaly) 을 방지하기 위해서, 테이블의 구성을 논리적이고 직관적으로 한다.

정규화를 해야 하는 이유는 충분해 보인다.

불필요한 데이터를 제거한다면 디스크의 용량을 줄일 수 있다. 또한 조회시에 스캔해야 할 데이터가 줄어들기 때문에 더 빠를 것임을 예측할 수 있다.

이상 현상을 방지 하는 것 역시 당연해 보인다. 믿을 수 없는 데이터라면 무슨 의미가 있을까.

정규화의 기계적인 방법을 위해서 NF(Normal Form), 정규형이라는 개념을 도입한다.

정규형은 1NF부터 6NF까지 종류가 있는데, 중요한 특징 중 하나는 높은 단계의 정규형은 자동으로 그 이전의 정규형 조건을 만족한다는 것이다.

1NF

제 1정규형의 요건은 릴레이션이어야 할 것 이다.

릴레이션이란 관계형 모델에서의 개념이다. RDB에선 Table과 매치되는 개념으로 개체를 표현하기 위한 데이터 구조로써 2차원 테이블로 표현하며, heading(스키마)와 body(본체)로 구성된다.

여기서 릴레이션의 개념보다는 릴레이션이 관계형 모델에서 왔다는 점이 중요하다. 이는 곧 집합이라는 개념에 부합해야 한다는 의미이기 때문이다.

테이블이 1NF가 되기 위한 요건은 다음과 같다.

행이 위에서 아래로 정렬되어 있지 않다.

열이 왼쪽에서 오른쪽으로 정렬되어 있지 않다.

중복되는 행이 존재하지 않는다.

값은 원자성을 가진다.

모든 열의 값은 정의된 것이어야 하고 각 행은 항상 존재한다. ( NULL인 값이 존재해서는 안된다. )

1. 테이블의 정렬되어 있지 않아야 한다.

테이블의 행과 열은 이미 정렬이 존재한다. 1번과 2번의 조건은 DB 테이블 구조로는 이미 만족할 수 없다.

하지만 이 점은 문제가 되지 않게 할 수 있다. 행과 열을 조회할 때, 순서에 의존하지 않는다면 말이다.

SELECT * FROM PRODUCTS -- 열의 순서에 의존하는 쿼리. *는 등록된 컬럼 순으로 값을 반환하기 때문
SQL

SELECT id FROM PRODUCTS ORDER BY 1 -- 행의 순서에 의존하는 쿼리.
SQL

위와 같이 순서에 의존하는 쿼리를 사용하지 않으면 1NF의 조건을 충족한다.

2. 중복되는 행이 존재하지 않는다.

해당 조건은 테이블에 기본키 혹은 유니크키와 같은 고유키가 존재한다면 조건을 만족한다.

3. 값의 원자성

값의 원자성이란 의미가 있는 한 묶음을 값의 한 단위로 취급한다는 의미이다.

예를 들어 상품의 상품명인 "컴퓨터" 는 원자값이다. "컴" "퓨터"로 나누는게 무슨 의미인가!

반면 상품명에 "컴퓨터, 커피"는 원자값이 아니다. "컴퓨터" 와 "커피"는 각각 분리되어야 한다.

위의 예제처럼 하나의 컬럼에 복수의 값들이 들어가지 않는 행의 모임을 가져야 한다.

4. 모든 열의 값은 정의된 것이어야 하고 각 행은 항상 존재한다.

집합론의 정의 중 "어떤 대상이 집합에 속하는지 여부는 명확해야 한다." 에 해당되는 부분이다. 각 행은 NULL과 같은 값이 존재하면 안된다. 모든 열은 이미 데이터베이스 어플리케이션이 제한하는 영역이기 때문에 신경쓸 필요가 없다.

1NF의 조건을 모두 살펴보았다. 그런데 곰곰히 생각해보면, 정규화 과정이 옳은 관계형 모델로 가는 것과 유사하지 않은가? 실제로 정규화는 관계형 모델을 보완하기 위해 나온 개념이라고도 한다!

함수 종속성(FD)

2NF부터 BCNF까지는 종속을 제거하는 정확하게는 릴레이션 내의 함수 종속성을 배제해 나가는 과정이다.

그렇다면 함수 종속이란 무엇일까?

어떤 릴레이션 R에 존재하는 필드들의 부분집합을 각각 X와 Y라고 할 때, X의 한 값이 Y에 속한 오직 하나의 값에만 사상될 경우에 "Y는 X에 함수 종속 (Y is functionally dependent on X)"이라고 하며, X→Y라고 표기한다. - 블로그 참고 -

예를 들어, 테이블에 [생일]과 [나이]라는 필드가 존재할 경우에 [나이] 필드는 [생일] 필드에 함수 종속이다. 즉, 생일을 알고 있다면, 나이에 대한 필드를 참조하지 않거나, 아예 필드를 유지하지 않아도 나이를 결정할 수 있다.

2NF

2NF는 후보키의 진부분집합에서 키가 아닌 속성에 함수 종속성을 제거하는 작업이다.

여기서 진 부분집합이란 부분집합 중에 원래 자신의 집합을 제외한 것을 말한다.

예를 들자면 그림에서 B는 {1,2,3} 일 때, A는 다음과 같은 부분집합이 될 수 있다.

{}, {1}, {2}, {3}, {1, 2}, {1, 3}, {2, 3}, {1, 2, 3}

이 중에서 원래 자기 자신인 {1, 2, 3 } 을 제외한 부분 집합이다.

Default view

커피 구매 목록

이름

나이

구매 커피

김충전

관계형 데이터베이스 좀 더 이해하기

최적화 이전에 알아야 할 것들

1. 관계형 모델

- 집합론

- 어떤 대상이 집합에 속하는지 여부는 명확해야 한다.

- NULL의 오해

- order by, count(*), NULL 은 모두 관계형 모델에 적합하지 않다.

2. 정규화

1NF

1. 테이블의 정렬되어 있지 않아야 한다.

2. 중복되는 행이 존재하지 않는다.

3. 값의 원자성

4. 모든 열의 값은 정의된 것이어야 하고 각 행은 항상 존재한다.

함수 종속성(FD)

2NF

3NF

테스트

1. 행 하나의 얼마만큼의 용량을 차지할까?

2. 인덱스는 INSERT에 영향을 미칠까? 만약 그렇다면 얼마정도일까?

조회 테스트

Q. 기본 로우 수는 조회에 얼마만큼 영향을 미칠까

어? 그렇다면 cpu_tuple_cost와 disk pages read, seq_page_cost를 낮출 수 있다면 성능을 향상 시킬 수 있을까?

Q. where절이 조회에 얼마만큼 영향을 미칠까

like문이라면 어떨까

Like쿼리의 Cacheing

Like쿼리와 Limit