관계형 데이터베이스

동네 서점의 주문 장부를 떠올려 볼게요. 손님이 책을 살 때마다 장부에 이름, 전화번호, 집 주소, 책 제목, 가격을 전부 적는다면 어떻게 될까요? 한 손님이 책을 백 번 사면 똑같은 이름과 주소를 백 번이나 반복해서 써야 해요. 도중에 손님이 이사를 가서 주소를 바꾸려면 백 개를 일일이 찾아 고쳐야 하죠. 이 과정에서 글씨를 잘못 쓰거나 몇 개를 빼먹는 실수가 생기기 마련이에요.

관계형 데이터베이스는 이 문제를 표를 나누어서 해결해요. '손님 명부 표'에는 손님 번호와 이름, 주소만 딱 한 번 적어둡니다. 그리고 '주문 내역 표'에는 긴 주소 대신 손님 번호와 산 책의 이름만 가볍게 기록해요.

이렇게 정보를 성격에 맞게 쪼개어 정리하면 불필요한 데이터 중복을 없애고 저장 공간을 아낄 수 있어요. 나중에 손님이 주소를 바꾸더라도 손님 명부의 딱 한 줄만 고치면 모든 주문 내역에 저절로 반영돼요.

쪼개진 표들은 어떻게 서로를 알아보고 짝을 맞출까요? 비결은 표의 각 줄(행)마다, 그 표 안에서 겹치지 않는 고유한 값을 붙여 주는 데 있어요. 주민등록번호나 학생 번호처럼 그 표 안에서 단 하나뿐인 값을 붙여주는 식이에요. 이를 '기본키(Primary Key)'라고 불러요.

손님 명부 표에 '손님 번호'라는 기본키가 있다면, 주문 표에서는 이 번호를 그대로 가져와서 가리켜요. 다른 표의 기본키를 참조하는 이 통로를 '외래키(Foreign Key)'라고 부르죠. 마치 자물쇠(기본키)에 꼭 맞는 열쇠(외래키)를 꽂아 두 표를 단단히 묶어주는 셈이에요.

우리가 인터넷 쇼핑몰에서 '내 주문 목록'을 누르는 순간, 시스템은 이 열쇠들을 맞춰봐요. 외래키를 따라 여러 표를 순식간에 연결해서 내 이름, 배송지 주소, 결제한 상품 이름이 한눈에 보이는 하나의 완성된 결과 화면을 척척 만들어내요.

여기서 말하는 '관계(Relation)'는 표와 표 사이의 연결고리만을 뜻하는 것이 아니에요. 수학에서 릴레이션은 여러 값을 짝지은 묶음(튜플)들의 집합을 뜻해요. 1970년 E. F. Codd가 이 개념을 데이터에 적용하면서, 표 하나를 하나의 릴레이션으로 본 데서 이름이 유래했어요. 즉 데이터를 엄격한 규칙을 가진 표 형태로 규격화해 다룬다는 뜻이 담겨 있죠.

엄격한 스키마와 제약조건, 그리고 트랜잭션(ACID) 기능 덕분에 관계형 데이터베이스는 높은 일관성과 정확성을 보장하도록 설계되어 있어요. 은행 계좌 이체처럼 단 1원의 오차도 용납되지 않는 서비스에서 오랫동안 널리 쓰여 온 이유예요.

물론 단점도 있어요. 형식이 제각각이거나 자주 바뀌는 데이터는 정해진 표 규격(스키마)에 맞추기 번거롭고, 데이터와 요청이 폭증할 때 여러 서버로 나누어 확장하기가 상대적으로 어려워요. 그래서 오늘날에는 정해진 형식 없이 자유롭게 담는 '비관계형 데이터베이스(NoSQL)'와 함께 상황에 맞춰 나누어 써요.