우리는 매일 수많은 데이터 속에서 살아가고 있습니다. 친구들의 생일 목록부터 영화관의 상영 시간표, 거대한 쇼핑몰의 주문 내역까지. 이 수많은 데이터는 어떻게 관리하는 것이 가장 좋을까요? 처음 데이터베이스를 접하는 분들을 위해 가장 기초적인 개념부터 차근차근 정리해 보았습니다. —
데이터의 양이 아주 적고 구조가 단순할 때는 메모장이나 엑셀(스프레드시트) 같은 플랫 파일 데이터베이스(Flat File Database)만으로도 충분합니다.
❓ 영화관 시간표의 딜레마 하나의 거대한 표에 영화 시간표를 기록한다고 가정해 봅시다.
주만지라는 영화를 10번 상영한다면, 영화의 관람 등급(PG)도 10번 반복해서 적어야 합니다. 그런데 직원의 실수로 9곳에는PG로 적고, 1곳에는U라고 적었다면 어떻게 될까요? 시스템과 관객 모두 어떤 정보가 진짜인지 확신할 수 없게 됩니다. —2. 해결사로 등장한 ‘관계형 데이터베이스(Relational)’
이러한 문제를 해결하기 위해 1960년대 후반, IBM의 컴퓨터 과학자 에드거 “테드” 커드(Edgar “Ted” Codd) 박사는 혁신적인 아이디어를 제안합니다. 데이터를 하나의 표에 몰아넣지 말고, 현실 세계의 객체인 엔티티(Entity) 단위로 쪼개어 저장하자는 것이었죠. (그는 이 공로로 1981년 컴퓨터 과학계의 노벨상인 ‘튜링상’을 받습니다.) 영화관 데이터를 예로 들면 다음과 같이 3개의 독립된 테이블로 분리합니다.
① 영화 테이블 (Films)
영화 자체에 대한 고유한 정보만 보관합니다.
| 영화 ID (PK) | 제목 (Title) | 관람 등급 (Rating) | 상영 시간 (Duration) |
|---|---|---|---|
| F01 | Minions | U | 91 |
| F02 | Jumanji | PG | 104 |
| F03 | Thor | 12A | 114 |
상영관의 고유 정보만 보관합니다.
| 상영관 ID (PK) | 상영관 이름 (Screen Name) |
|---|---|
| S01 | Blue Room |
| S02 | Grand Theatre A |
| S03 | Green Room |
| S04 | Grand Theatre B |
어떤 영화가, 언제, 어느 상영관에서 상영되는지 실제 일정을 기록합니다. 앞선 두 테이블의 기본키를 외래키(FK)로 가져와 관계를 맺습니다.
| 상영 ID (PK) | 영화 ID (FK) | 상영관 ID (FK) | 상영 시각 (Time) |
|---|---|---|---|
| 1 | F01 | S01 | 17:45 |
| 2 | F02 | S02 | 18:15 |
| 3 | F01 | S03 | 18:45 |
| 4 | F03 | S04 | 19:30 |
| 5 | F02 | S02 | 20:15 |
| 6 | F03 | S01 | 20:30 |
주만지 영화의 등급을 수정할 때 영화 테이블에서 딱 한 번만 고치면 됩니다. 상영 일정 테이블은 고유한 ID를 통해 연결되어 있으므로, 데이터가 꼬이거나 불일치가 일어날 확률이 원천 차단됩니다.“데이터를 다 쪼개 놓으면 상영 시간표를 한눈에 볼 때는 불편하지 않나요?”라는 의문이 들 수 있습니다. 걱정할 필요 없습니다. 저장할 때는 따로 안전하게 저장하지만, 우리가 꺼내 볼 때는 데이터베이스 표준 언어인 SQL(Structured Query Language)을 사용해 다시 합쳐서 볼 수 있으니까요.
SELECT f.Title, f.Rating, s.ScreenName, sh.Time
FROM Showing sh
JOIN Film f ON sh.FilmId = f.FilmId
JOIN Screen s ON sh.ScreenId = s.ScreenId;
위와 같이 JOIN 명령어를 사용하면 데이터베이스가 내부적으로 테이블을 결합하여, 사용자에게는 다시 보기 편한 하나의 완성된 시간표로 가공해서 보여줍니다.
흔히 데이터 중복을 줄여주니까 데이터베이스를 쓰면 디스크 용량(저장 공간)이 절약될 것이라고 생각하기 쉽습니다. 하지만 이는 반은 맞고 반은 틀린 생각입니다. 데이터베이스는 데이터를 빠르고 효율적으로 찾기 위해 내부적으로 인덱스(Indexes)나 포인터(Pointers) 같은 복잡한 데이터 구조를 추가로 생성합니다. 데이터의 구조를 설명하는 메타데이터(Metadata)도 저장하죠. 따라서 단순히 “공간 절약”을 목적으로 데이터베이스를 선택하는 것은 올바른 접근이 아닙니다. 대신 다음과 같은 확실한 장점들을 보고 사용해야 합니다.
우리가 직접 하드웨어 디스크를 뒤져가며 이 복잡한 테이블과 인덱스를 관리할 수는 없습니다. 그래서 사용하는 소프트웨어가 바로 DBMS(Database Management System, 데이터베이스 관리 시스템)입니다. 대부분의 DBMS는 관리자가 편리하게 작업할 수 있도록 그래픽 화면(GUI)을 제공하며, 구조 변경, 인덱스 생성, 쿼리 테스트 등의 기능을 지원합니다.