튜링상 관련 업적

데이터베이스 관리 시스템의 이론 및 실제에서 근본적이면서 지속적으로 기여했다. 데이터베이스의 관계형 모델을 처음 만든 사람으로서 관계 대수, 관계 논리, 관계의 정규화 등에도 중요한 기여를 했다.

1981년 튜링상 선정 이유​1​

에드거 커드는 데이터베이스에 관심이 있는 컴퓨터 전문가라면 알고 있을 이름이다. 실제로는 ‘테드’라는 별칭으로 더 잘 알려져 있는 그는, 데이터베이스 분야에서 가지는 위상에 비하여 대중들에게 별로 노출되지 않았다. 그가 했던 인터뷰는 찾기 힘들며 그나마 남아 있는 것들도 데이터베이스에 대한 전문적인 의견들이어서 개인적인 감회나 일화 같은 것은 알기 어렵다. 오늘날 엄청난 규모의 비즈니스로 성장한 관계형 데이터베이스 시장을 생각한다면 아쉬운 일이다.

관계형 모델

데이터베이스의 관계형 모델relational model은 기존의 데이터베이스에 대한 대안으로 등장했다. 따라서 기존의 데이터베이스가 어떤 문제를 가지고 있었는지 살펴볼 필요가 있다.

데이터베이스의 시작은 1960년대 초로 거슬러 올라간다. GE에 근무하고 있던 찰스 바크먼​6​은 생산 시스템을 효율적으로 관리하기 위한 응용프로그램을 만드는 과정에서 정보를 디스크에 효과적으로 저장하고 접근하기 위한 하부 시스템을 개발했다. 바크먼은 처음에 이 하부 시스템을 데이터 저장소data store라고 칭했지만 후에 데이터베이스라고 부르게 된다.

바크먼은 생산 시스템에서 다루는 정보들을 체계적으로 다루기 위해서 레코드record라는 형태로 데이터를 조직했다. 예를 들면, 부품의 정보를 저장하기 위해서 부품 번호, 부품 이름, 부품에 대한 설명, 재고량 등을 한 묶음 즉 하나의 레코드로 관리한다. 사용자 혹은 프로그래머는 부품에 관한 정보를 얻기 위해서 키값key value이라는 것을 사용하는데 앞에서 예로 든 부품의 경우는 부품 번호가 거기에 해당하겠다.​†​

그런데 생산 시스템에서 다루는 정보들은 간단치가 않다. 부품은 결국 어떤 제품을 만드는 데 사용될 터인데 이 제품에 대한 정보도 저장해야 하고, 부품 공급처에 대한 정보도 저장해야 하고, 제품 주문처에 대한 정보도 저장해야 한다. 그렇다면 제품에 대한 정보는 어떤 형태의 레코드를 가져야 할까? 제품 번호, 제품 이름, 제품에 대한 설명 등이 포함될 수 있다. 만약 제품에 대한 정보 레코드 내에 관련된 부품 정보를 모두 포함하면 어떻게 될까? 그렇다면 부품 레코드는 필요 없어질지 몰라도 제품 레코드의 크기가 엄청나게 커질 수 있다. 뿐만 아니라 어떤 부품은 여러 제품에 사용될 수 있을 텐데 부품의 재고량이 바뀔 때마다 관련된 모든 제품 레코드들을 수정해야 하므로 관리가 어려워진다.

이런 상황을 해결하기 위한 방법이 단 한 가지만 있는 것은 아니다. 데이터베이스에 저장될 데이터를 어떻게 조직화할 것인가는 상황에 따라 달라질 수 있다. 아래의 그림은 제품 정보와 부품 정보를 데이터베이스에 저장하는 방식 두 가지를 보여주고 있다. 두 방식은 쌍둥이처럼 보이지만 서로 다르다. 첫 번째 것은 부품 레코드가 우선이고 두 번째 것은 제품 레코드가 우선이다. 어느 방법을 선택할지는 주어진 상황에 어느 것이 가장 적합한가에 달려 있다.

방법 1
방법 2

바크먼이 사용한 이런 방식을 흔히 네트워크형 모델network model혹은 계층형 모델이라고 부른다. 이는 직관적으로 이해하기 쉬운 장점이 있다. 하지만 문제가 있다. 바크먼은 이를 구현하는 과정에서 위의 개념적 구조를 그대로 적용했다. 각 레코드는 디스크에서 각각 개별적으로 저장되며 물리적 저장 위치가 직접적으로 사용된다. 사용자는 데이터베이스에 대해서 생성, 변경, 삭제 등의 작업을 하려면, 레코드들의 세부 구조와 연결 네트워크를 이해하고 있어야 한다. 단순하게 하나의 네트워크만 있다면 다행이지만 실제 현장 응용에서는 복수 개의 네트워크들이 존재하며 이들이 얼기설기 엮어져 있다. 아울러, 뭔가 사정이 생겨서 레코드의 저장 위치가 바뀐다거나 레코드 사이의 관계를 바꿔야 할 상황이 발생하면 전체 시스템을 다시 재구성해야 하는 어려움이 있다.

커드는 기존의 데이터베이스가 단점이 많다면서 세 가지 문제점을 지적했다.​5​

먼저 데이터의 물리적 순서에 대한 종속성이다. 위의 예에서 부품 레코드를 저장할 때 부품 번호의 순서대로 디스크에 저장하게 되면 부품 레코드를 쉽게 찾을 수 있지만, 만약 부품 번호가 바뀌거나 중간 번호의 부품이 추가되면 곤란해진다. 두 번째는 색인 문제이다. 레코드를 찾기 위해서는 키값을 사용하게 되는데, 빠르게 레코드를 찾기 위해서 레코드의 키값과 해당 레코드의 디스크 물리적 주소를 저장하는 별도의 색인 정보를 유지하게 된다. 그런데 레코드의 물리적 위치가 바뀌게 되면 이 색인값을 변경해야 하는 부담이 생기며 아울러 색인이란, 본질적으로 필요한 정보가 아니라 부가적인 정보이므로 일종의 오버헤드인 셈이다. 마지막 문제점은 접근 경로에 대한 종속성이다. 이는 위의 그림을 보면 쉽게 이해할 수 있다. 어떤 제품에 사용되는 부품을 알아내야 한다고 했을 때, 왼쪽 그림에서는 모든 부품들의 레코드를 뒤져야 하지만 오른쪽 그림에서는 해당 제품의 레코드만 확인하면 된다. 데이터를 어떤 식으로 구성하느냐에 따라 특정 정보에 접근하기 위한 경로가 달라진다.​‡​

커드는 이런 문제를 극복하기 위한 대안으로 관계relation라는 개념을 제안했다. ‘관계’란 n개의 집합이 주어졌을 때 각 집합의 원소를 하나씩 모아서 구성한 것n-tuple들을 의미한다. 앞의 왼쪽 그림을 관계로 표현한다면 부품 레코드는 (부품번호, 부품이름, 부품 설명, 제품 번호)의 형태가 될 것이고 제품 레코드는 (제품 번호, 제품 이름, 제품 설명)이 될 것이다. 언뜻 보면 ‘관계’라는 개념이 앞의 네트워크형 모델과 별 차이가 없어 보인다. 그렇게 보이는 이유는 레코드의 구조만 따졌기 때문이다. 커드의 ‘관계형 모델’은 ‘관계’라는 데이터 구조에 추가하여 이 구조에 대해 적용되는 연산operation과 제약constraint 등을 포함한다.

관계 대수와 관계 논리

Algebra(대수)는 연산자operator와 피연산자operand를 다루는 수학 분야이다. 대표적인 예가 사칙연산이다. 우리는 숫자라는 피연산자에 대해 덧셈, 뺄셈, 곱셈, 나눗셈과 같은 연산자가 어떻게 적용되는지를 배운다. 그리고 교환법칙, 결합법칙, 배분법칙과 같은 여러 법칙도 함께 따라온다.

Calculus는 흔히 미적분학으로 번역되지만 사실은 좀 더 넓은 의미를 가지고 있다. 변수와 함수로 구성된 수식을 따지는 분야이다. 학창 시절에 우리는 x^2 + 2x + 1 = 0 일 때 x의 값을 구하라는 식의 문제를 많이 접해보았다. 이렇듯 어떤 수식이 조건으로 주어지면 그것을 만족시키는 변수나 함수를 구하는 것이 Calculus이다.

그래서 Algebra는 연산자를 적용하는 방식에 관한 것이고, Calculus는 조건으로 주어진 수식의 답을 찾는 방식에 관한 것이다.

관계 대수relational algebra와 관계 논리relational calculus의 차이도 이와 유사하다. 관계 대수는 ‘관계’라는 피연산자에 대해서 적용되는 여러 가지 연산자들에 관한 것이고, 관계 논리는 ‘관계’에 대한 수식을 푸는 것이다. ‘관계 미적분학’, 또는 ‘관계 계산’이 아니라 ‘관계 논리’라고 번역이 되는 이유는 아마도 그 수식이 ‘술어 논리predicate logic‘로 구성되었기 때문일 듯싶다.

커드의 관계형 모델이 네트워크형 모델과 가장 차별화되는 부분은, 수학적 기반에 있다. 커드는 관계형 모델의 완전함을 보여주기 위해 수학 모델을 도입했다. 그래서 관계 대수와 관계 논리를 만들었다. 관계 대수와 관계 논리는 관계형 데이터베이스 모델에서 ‘질의query‘ 의 기반이 되었다.

커드가 처음 관계 대수를 제안할 때 고려한 연산자로는 Permutation, Projection, Join, Composition, Restriction 등이 있다. 예를 들어 Projection은 \pi 기호를 사용하는데 피연산자로 온 ‘관계’에서 특정 열column만 뽑아내는 일을 한다. 만약 \pi_{13}(R)과 같은 표현이 있다면 이것은 R이라는 ‘관계’에서 1번과 3번 열만 뽑아낸 후에 중복되는 것을 없앤 것을 말한다. 관계 대수의 피연산자는 ‘관계’이며 연산자를 적용한 결과값도 ‘관계’이다.​§​

Join은 아마도 가장 중요한 연산자일 것이다. 이것은 두 개의 관계를 합치는 방법에 관한 것이다. 두 개의 관계가 주어졌을 때 공통 도메인을 가지는 열에 대해 Join 연산을 적용하게 되는데, 그 열에 해당하는 값이 같은 것을 양쪽 관계에서 찾아서 하나의 행으로 만들어 준다. 모든 가능한 경우를 다 따져서 Join을 할 경우 Natural join이라고 불렀다. 아래에 예를 들었다.​5​

R (공급자  부품)          S (부품   제품)
    1     1                1     1
    2     1                1     2
    2     2                2     1

위와 같이 R과 S라는 관계가 만들어져 있다고 가정해보자. 이에 대한 Natural join은 아래와 같다.

R*S (공급자  부품  제품)
       1    1    1
       1    1    2
       2    1    1
       2    1    2
       2    2    1

위에서 언급한 Natural join은 수식으로 표현할 수 있다. R과 S라는 관계가 있고 둘 다 두 개의 열을 가지고 있으며 R의 두 번째 열과 S의 첫 번째 열이 같은 도메인에 해당한다고 하면 Natural join은 다음과 같이 표현된다.​5​

R * S = {(a, b, c): R(a,b) \land S(b,c)}

이것은 연산자의 동작을 직접 묘사하지 않고도 같은 결과값을 유도할 수 있다. 이렇게 수식을 조건으로 사용하여 결과를 표현하는 것이 관계 논리이다.

관계의 정규화

정규화normalization는 말 그대로 뭔가를 normal하게 만든다는 의미이다. 그렇다면 normal하다는 것은 무엇을 의미하는가? 그것은 어느 분야에서 쓰이느냐에 따라 다르다. 관계형 모델에서의 정규화에 대해 커드는 이렇게 설명했다.

정규화는 정보의 의미semantics을 형식적 방법formal way으로 아주 조금 잡아내려는 시도입니다. 다시 말하자면 하나의 레코드 내에 어떤 필드들이 들어가야 하는지에 대한 규칙을 정하려는 노력입니다.​4​

앞에서 들었던 부품과 제품에 관한 사례를 보면 우리는 하나의 레코드 내에 들어가야 할 정보를 정하는 유일한 정답은 없음을 알 수 있다. 정보들 사이의 관계는 복잡하게 얽혀 있기 때문에, 어떻게 쪼개고 어떻게 연관시킬지는 상황과 관점에 따라 달라질 수 있다. 하지만 그래도 관리가 용이하고 오류의 가능성을 없앨 수 있는 방식이 바람직하다.

하나의 레코드 내에 어떤 필드들이 들어가야 할지 처음부터 답이 정해져 있지는 않았다. 그래서 이른바 ‘normal’한 레코드에 대한 정의도 시간이 지나면서 계속 변해왔다. 1970년에 커드가 처음 관계형 모델에 관한 논문을 발표했을 때 그가 생각했던 ‘normal’한 레코드는, 각 필드가 단일한 값을 가지는 형태였다. 최초에 그가 생각한 관계형 모델에서는 필드의 값이 다른 관계를 가리킬 수 있었다. 위의 부품, 제품 사례의 방법 1을 보면 부품 레코드 내에서 연관된 제품 레코드들을 가리키고 있다. 커드는 이런 방식이 복잡도를 증가시키고 관계 대수를 적용하기 어렵게 만든다고 보았다. 그래서 아래와 같은 형태로 변형할 것을 제안했다.

이제 부품 레코드는 제품 레코드를 직접 가리키지 않는다. 대신에 제품 레코드에 ‘부품번호’라는 필드가 추가되었다. 부품번호가 주어졌을 때 이 부품을 사용하는 제품 레코드를 찾는 것이 한 번에 가능해졌다.

커드가 제안한 이 첫 번째 정규화를 1세대 정규화라고 부른다. 1세대 정규화는, 관계형 데이터베이스의 레코드에서 어떤 필드가 관계를 값으로 가질 수 있다면 이를 변형하여 모든 필드의 값이 단일한 값을 가지도록 만드는 과정이다.

‘Normal’한 레코드에 대한 정의가 계속 진화하면서 그에 맞춰 2세대, 3세대 정규화가 계속 발표되었다. 현재는 6세대 정규화까지 나와 있는 상태이다.

1 2 3 4