1970년, IBM 연구소의 수학자 에드거 프랭크 코드(E. F. Codd)는 한 편의 논문을 발표했습니다.
이 논문은 단순한 기술 제안이 아니라 데이터 세계의 철학을 완전히 바꾼 선언문이었죠.
그가 제안한 “관계형 데이터 모델(Relational Model)”은 오늘날 우리가 사용하는 SQL, MySQL, PostgreSQL, Oracle 같은 데이터베이스의 근본적인 원리입니다.
당시 데이터베이스는 복잡했습니다. 데이터를 저장하려면 구조(트리나 네트워크)를 직접 알아야 했고,
구조가 조금만 바뀌어도 모든 프로그램이 고장 났습니다.
Codd는 이런 문제를 해결하기 위해 “데이터의 의미(논리)”와 “저장 방식(물리)”을 분리해야 한다고 주장했습니다.
즉, 데이터는 관계(Relation)로 표현되어야 한다는 것이 그의 핵심 주장이었죠.
1970년 이전의 데이터베이스는 대부분 계층형(hierarchical) 또는 네트워크형(network) 구조를 사용했습니다.
계층형 모델 (Hierarchical Model)
마치 폴더 구조처럼 “부모-자식 관계”로 데이터를 연결합니다.
예: 한 회사 → 여러 부서 → 각 부서의 직원
네트워크형 모델 (Network Model)
데이터가 여러 경로로 연결될 수 있는 좀 더 유연한 구조입니다.
예: 프로젝트 ↔ 직원 ↔ 부서
문제는 이런 구조들이 프로그램 코드에 종속적이었다는 겁니다.
데이터를 읽거나 수정하려면 프로그램이 트리 구조를 따라가야 했고,
데이터 구조가 조금이라도 바뀌면 모든 프로그램을 다시 짜야 했습니다.
즉, 데이터 독립성(Data Independence)이 없었습니다.
Codd는 “데이터를 ‘저장 방식’이 아니라 ‘의미’로 표현하자”고 주장했습니다.
그가 제안한 관계형 모델(Relational Model)은 데이터를 수학적 집합 이론에 기반해 표현합니다.
데이터는 사용자가 이해하는 의미적 구조만 가져야 한다.
하드웨어나 저장 포맷에 종속되면 안 된다.
즉, 사용자는 데이터의 “논리적 구조”만 알면 되고,
그 데이터가 실제로 어떻게 저장되어 있는지는 신경 쓸 필요가 없다는 것입니다.
관계형 데이터 모델의 모든 것은 ‘관계(Relation)’라는 개념에서 출발합니다.
이 Relation은 단순히 “테이블(table)”이라고 이해하면 됩니다.
Codd는 “관계”를 수학적으로 다음과 같이 정의했습니다.
Relation은 n개의 도메인(domain)에 대해 정의된 n-튜플(tuple)의 집합이다.
조금 어렵게 들리지만, 쉽게 말하면 이렇습니다:
도메인(domain): 특정 속성이 가질 수 있는 값의 집합
예: “성별” 도메인은 {남, 여}, “국가” 도메인은 {한국, 미국, 일본}
튜플(tuple): 하나의 데이터 행(row)
예: (홍길동, 29, 서울, 남)
관계(relation): 같은 구조를 가진 튜플들의 집합
즉, “하나의 테이블”
그래서 “학생(Student)”이라는 관계는 다음과 같이 표현됩니다.
| 학번 | 이름 | 학과 | 학년 |
|---|---|---|---|
| 2025001 | 김지민 | 컴퓨터공학 | 3 |
| 2025002 | 이수현 | 데이터사이언스 | 2 |
이 전체 표가 하나의 Relation이며, 각 행은 Tuple, 각 열은 Domain을 나타냅니다.
Codd는 데이터의 가장 작은 단위를 속성(Attribute)으로 정의했습니다.
예를 들어 “학생” 관계에서 이름, 학과, 학년이 각각 속성입니다.
각 속성의 조합으로 이루어진 하나의 데이터가 튜플이죠.
이 개념은 오늘날 우리가 쓰는 행(Row)과 열(Column) 개념의 기초입니다.
Relation = 속성들의 조합으로 이루어진 튜플들의 집합
Codd는 데이터의 무결성을 위해 “키(Key)” 개념을 도입했습니다.
기본키(Primary Key)
각 행을 유일하게 식별할 수 있는 속성
예: 학번, 주민등록번호 등
외래키(Foreign Key)
다른 테이블의 기본키를 참조하는 속성
예: “수강 테이블”의 학생ID는 “학생 테이블”의 기본키를 참조
이 개념 덕분에 데이터베이스는 중복 없이 여러 테이블 간의 관계를 논리적으로 연결할 수 있게 되었습니다.
이 구조가 바로 Relational(관계형)이라는 이름의 근거이기도 합니다.
관계형 모델의 진정한 가치는 데이터 독립성(Data Independence)을 제공한다는 점입니다.
즉, 데이터가 어떻게 저장되든, 사용자는 그 사실을 몰라도 된다는 것입니다.
Codd는 논문에서 데이터 종속성의 세 가지 유형을 지적했습니다.
| 유형 | 설명 | 문제점 |
|---|---|---|
| Ordering Dependence | 데이터가 저장된 순서에 의존 | 순서 바뀌면 프로그램 오류 |
| Indexing Dependence | 인덱스 존재 여부에 따라 프로그램 달라짐 | 인덱스 제거 시 프로그램 실패 |
| Access Path Dependence | 트리나 네트워크 경로에 의존 | 경로 변경 시 전체 코드 재작성 필요 |
관계형 모델에서는 이러한 의존성을 모두 제거했습니다.
데이터를 ‘관계’로 정의하기 때문에, 순서나 인덱스가 없어도 논리적으로 일관된 결과를 얻을 수 있습니다.
이 혁신적인 아이디어 덕분에, 관계형 데이터베이스에서는
테이블 구조를 변경해도 응용 프로그램이 영향을 받지 않습니다.
예를 들어, 학생 테이블에 “이메일” 속성을 추가해도
기존의 조회 프로그램은 아무런 문제 없이 동작합니다.
이것이 바로 Codd가 강조한 논리적 독립성(Logical Independence)의 실현입니다.
이는 오늘날 SQL의 뷰(View) 개념과도 직결됩니다.
Codd는 또 다른 핵심 개념으로 정규화(Normalization)를 제시했습니다.
그는 데이터 중복이 불필요한 저장 공간 낭비뿐 아니라 일관성(consistency) 문제를 일으킨다고 지적했습니다.
예를 들어, 다음과 같은 직원(Employee) 테이블이 있다고 가정합시다.
| 사번 | 이름 | 부서명 | 부서위치 |
|---|---|---|---|
| 101 | 김철수 | 인사팀 | 서울 |
| 102 | 이영희 | 개발팀 | 부산 |
| 103 | 박민수 | 인사팀 | 서울 |
여기서 “부서명”과 “부서위치” 정보가 중복되어 있습니다.
만약 인사팀의 위치가 “서울”에서 “성남”으로 바뀌면,
모든 인사팀 직원의 행을 일일이 수정해야 하죠.
이게 바로 갱신 이상(Update Anomaly)입니다.
Codd는 이를 해결하기 위해 데이터를 단순하고 독립적인 형태로 분리하자고 제안했습니다.
1️⃣ 제1정규형 (1NF)
모든 속성은 원자값(Atomic Value)만 가진다.
즉, 하나의 칸에는 하나의 값만 들어가야 한다.
2️⃣ 제2정규형 (2NF)
기본키의 일부가 아닌 속성은 전체 기본키에 종속되어야 한다.
즉, 부분 종속을 제거한다.
3️⃣ 제3정규형 (3NF)
비키 속성끼리 서로 종속되면 안 된다.
즉, 이행 종속을 제거한다.
위 예시를 정규화하면 다음과 같습니다:
직원 테이블(Employee)
| 사번 | 이름 | 부서ID |
부서 테이블(Department)
| 부서ID | 부서명 | 부서위치 |
이제 부서 위치를 한 곳만 수정하면 모든 데이터가 자동으로 일관성을 유지합니다.
이 원리가 오늘날의 데이터베이스 설계 표준의 근간이 되었습니다.
Codd의 가장 천재적인 통찰 중 하나는 데이터를 수학적으로 다루는 방법을 제시했다는 것입니다.
그는 데이터베이스를 “정보를 저장하는 상자”가 아닌 “집합을 다루는 수학적 시스템”으로 정의했습니다.
이를 통해 그는 데이터 조작 언어(Data Manipulation Language)의 논리적 기초를 세웠고,
그 위에서 훗날 SQL이 태어나게 됩니다.
Codd가 제시한 Join(조인)은 서로 다른 관계(테이블)를 연결하는 연산입니다.
오늘날 SQL에서 JOIN 구문이 바로 이 개념에서 나온 것이죠.
예를 들어, 다음 두 관계가 있다고 합시다.
학생(Student)
| 학번 | 이름 |
|---|---|
| 101 | 김지민 |
| 102 | 이수현 |
수강(Course_Enrollment)
| 학번 | 과목 |
|---|---|
| 101 | 데이터베이스 |
| 102 | 알고리즘 |
이 두 테이블을 “학번”이라는 공통 속성으로 조인(Join)하면 다음과 같습니다.
| 학번 | 이름 | 과목 |
|---|---|---|
| 101 | 김지민 | 데이터베이스 |
| 102 | 이수현 | 알고리즘 |
즉, 서로 다른 관계를 논리적으로 연결해서
하나의 새로운 관계(결과 테이블)를 만드는 연산이 바로 Join입니다.
Codd는 이 연산을 통해 “데이터 간의 관계를 연결하는 것은
물리적 포인터(pointer)가 아니라 논리적 값(value)로 충분하다”고 증명했습니다.
이는 네트워크형 모델의 가장 큰 한계를 완전히 극복한 결정적인 부분이었습니다.
Codd는 또 두 가지 중요한 연산을 정의했습니다.
이 두 개념은 오늘날 SQL의 SELECT 구문의 논리적 근간이 되었습니다.
SELECT 이름, 학과 FROM 학생;SELECT * FROM 학생 WHERE 학년 = 3;이 두 연산은 데이터베이스에서 정보를 “어떻게 표현하고 필터링할 것인가”를 정의하는 핵심 개념입니다.
즉, Codd의 연산 체계는 단순히 이론이 아니라, 오늘날 우리가 매일 사용하는 SQL의 수학적 기반이 된 셈입니다.
데이터베이스의 목적은 단순히 데이터를 저장하는 것이 아니라,
항상 신뢰할 수 있는 상태(Consistent State)를 유지하는 것입니다.
Codd는 이를 위해 “데이터 일관성(consistency)”과 “무결성(integrity)”이라는 개념을 수학적으로 정의했습니다.
Codd는 논문에서 두 가지 종류의 중복을 설명했습니다.
| 구분 | 설명 | 예시 |
|---|---|---|
| 강한 중복(Strong Redundancy) | 하나의 데이터가 다른 관계에서 완전히 유도 가능한 경우 | ‘부서 이름’이 두 테이블에 중복 |
| 약한 중복(Weak Redundancy) | 완전히 중복은 아니지만 부분적으로 의존 관계가 존재 | 프로젝트-직원-부서 간의 간접 중복 |
강한 중복은 설계 단계에서 제거할 수 있지만,
약한 중복은 현실적으로 완전히 없앨 수 없다고 했습니다.
그래서 Codd는 정규화와 제약조건(Constraints)을 통해
데이터 불일치가 발생하지 않도록 하는 수학적 틀을 만들었습니다.
오늘날 우리가 DB 설계 시 반드시 정의하는 기본키 제약(Primary Key Constraint),
외래키 제약(Foreign Key Constraint), 유일성 제약(Unique Constraint) 등은
모두 Codd가 제시한 무결성 제약(Integity Constraint) 개념에서 출발했습니다.
그는 이렇게 말했습니다:
“데이터베이스의 상태는 제약조건을 위반하지 않는 한에서만 유효하다.”
즉, 시스템은 삽입, 수정, 삭제 등 모든 연산이 수행된 후
논리적으로 일관성(consistency)이 유지되는지 자동으로 확인해야 한다는 것입니다.
이 철학이 오늘날 트랜잭션(Transaction) 개념과 ACID 원칙의 기초가 되었습니다.
Codd는 논문 마지막 부분에서 미래를 내다봤습니다.
그는 “보편적 데이터 하위 언어(Universal Data Sublanguage)”의 필요성을 언급하며
관계형 모델 위에서 모든 데이터 작업을 수행할 수 있는 언어를 상상했습니다.
“모든 데이터는 관계로 표현될 수 있으며,
모든 연산은 논리적 연산으로 수행되어야 한다.” — Codd (1970)
이 아이디어는 1974년 IBM 연구진이 만든 SEQUEL (Structured English Query Language)로 발전했고,
이후 이름이 SQL로 바뀌어 오늘날까지 이어지고 있습니다.
즉, 우리가 지금 쓰는
SELECT name FROM student WHERE major = 'Computer Science';
라는 문장은 Codd가 상상한 보편적 데이터 언어의 실현인 셈입니다.
오늘날 거의 모든 데이터베이스 시스템은
Codd의 관계형 모델을 기반으로 설계되어 있습니다.
즉, Codd의 모델은 단순한 한 가지 설계 철학이 아니라
현대 데이터 저장의 언어적, 논리적 토대가 된 셈입니다.
🔗 참고 및 추가 학습