[DB] 엑셀에서 SQL까지: 데이터베이스 입문 가이드
🗄️ 엑셀에서 SQL까지: 데이터베이스 입문 가이드
우리는 매일 수많은 데이터 속에서 살아가고 있습니다. 친구들의 생일 목록부터 영화관의 상영 시간표, 거대한 쇼핑몰의 주문 내역까지. 이 수많은 데이터는 어떻게 관리하는 것이 가장 좋을까요? 처음 데이터베이스를 접하는 분들을 위해 가장 기초적인 개념부터 차근차근 정리해 보았습니다. —
1. 시작은 가볍게: 플랫 파일(Flat File)과 스프레드시트
데이터의 양이 아주 적고 구조가 단순할 때는 메모장이나 엑셀(스프레드시트) 같은 플랫 파일 데이터베이스(Flat File Database)만으로도 충분합니다.
- 실용적인 예시: 친구들의 생일 목록, 동아리 참가자 명단
- 장점: 한 화면에 모든 데이터가 들어오기 때문에 한눈에 파악하기 쉽고, 혹시 오타가 나거나 잘못된 정보가 있어도 그 자리에서 바로 발견하고 고치면 됩니다.
하지만 데이터의 양이 수천, 수만 건으로 늘어나고 구조가 복잡해지면 치명적인 문제가 발생합니다. 바로 데이터 불일치(Inconsistency)와 중복(Redundancy)입니다.
❓ 영화관 시간표의 딜레마 하나의 거대한 표에 영화 시간표를 기록한다고 가정해 봅시다.
주만지라는 영화를 10번 상영한다면, 영화의 관람 등급(PG)도 10번 반복해서 적어야 합니다. 그런데 직원의 실수로 9곳에는PG로 적고, 1곳에는U라고 적었다면 어떻게 될까요? 시스템과 관객 모두 어떤 정보가 진짜인지 확신할 수 없게 됩니다. —
2. 해결사로 등장한 ‘관계형 데이터베이스(Relational)’
이러한 문제를 해결하기 위해 1960년대 후반, IBM의 컴퓨터 과학자 에드거 “테드” 커드(Edgar “Ted” Codd) 박사는 혁신적인 아이디어를 제안합니다. 데이터를 하나의 표에 몰아넣지 말고, 현실 세계의 객체인 엔티티(Entity) 단위로 쪼개어 저장하자는 것이었죠. (그는 이 공로로 1981년 컴퓨터 과학계의 노벨상인 ‘튜링상’을 받습니다.) 영화관 데이터를 예로 들면 다음과 같이 3개의 독립된 테이블로 분리합니다.
① 영화 테이블 (Films)
영화 자체에 대한 고유한 정보만 보관합니다.
- 기본키(PK): 영화 ID
| 영화 ID (PK) | 제목 (Title) | 관람 등급 (Rating) | 상영 시간 (Duration) |
|---|---|---|---|
| F01 | Minions | U | 91 |
| F02 | Jumanji | PG | 104 |
| F03 | Thor | 12A | 114 |
② 상영관 테이블 (Screens)
상영관의 고유 정보만 보관합니다.
- 기본키(PK): 상영관 ID
| 상영관 ID (PK) | 상영관 이름 (Screen Name) |
|---|---|
| S01 | Blue Room |
| S02 | Grand Theatre A |
| S03 | Green Room |
| S04 | Grand Theatre B |
③ 상영 일정 테이블 (Showings)
어떤 영화가, 언제, 어느 상영관에서 상영되는지 실제 일정을 기록합니다. 앞선 두 테이블의 기본키를 외래키(FK)로 가져와 관계를 맺습니다.
- 기본키(PK): 상영 ID
- 외래키(FK): 영화 ID, 상영관 ID
| 상영 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를 통해 연결되어 있으므로, 데이터가 꼬이거나 불일치가 일어날 확률이 원천 차단됩니다.
3. 볼 때는 하나로: 데이터베이스 표준 언어 SQL
“데이터를 다 쪼개 놓으면 상영 시간표를 한눈에 볼 때는 불편하지 않나요?”라는 의문이 들 수 있습니다. 걱정할 필요 없습니다. 저장할 때는 따로 안전하게 저장하지만, 우리가 꺼내 볼 때는 데이터베이스 표준 언어인 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 명령어를 사용하면 데이터베이스가 내부적으로 테이블을 결합하여, 사용자에게는 다시 보기 편한 하나의 완성된 시간표로 가공해서 보여줍니다.
4. 오해와 진실: 데이터베이스는 무조건 공간을 아낀다?
흔히 데이터 중복을 줄여주니까 데이터베이스를 쓰면 디스크 용량(저장 공간)이 절약될 것이라고 생각하기 쉽습니다. 하지만 이는 반은 맞고 반은 틀린 생각입니다. 데이터베이스는 데이터를 빠르고 효율적으로 찾기 위해 내부적으로 인덱스(Indexes)나 포인터(Pointers) 같은 복잡한 데이터 구조를 추가로 생성합니다. 데이터의 구조를 설명하는 메타데이터(Metadata)도 저장하죠. 따라서 단순히 “공간 절약”을 목적으로 데이터베이스를 선택하는 것은 올바른 접근이 아닙니다. 대신 다음과 같은 확실한 장점들을 보고 사용해야 합니다.
- 데이터 무결성(Integrity) 향상: 데이터의 정확성과 신뢰성 유지
- 최신화의 용이성: 단 한 곳만 수정하면 전체 시스템에 실시간 반영
- 다양한 정보 창출: 데이터를 여러 방식으로 결합하여 유용한 인사이트 추출
5. 이 모든 것을 총괄하는 비서: DBMS
우리가 직접 하드웨어 디스크를 뒤져가며 이 복잡한 테이블과 인덱스를 관리할 수는 없습니다. 그래서 사용하는 소프트웨어가 바로 DBMS(Database Management System, 데이터베이스 관리 시스템)입니다. 대부분의 DBMS는 관리자가 편리하게 작업할 수 있도록 그래픽 화면(GUI)을 제공하며, 구조 변경, 인덱스 생성, 쿼리 테스트 등의 기능을 지원합니다.
- MySQL: 전 세계적으로 가장 인기 있는 오픈 소스 RDBMS (주로 웹 서비스에 사용)
- SQLite: 서버가 필요 없고 가벼워 모바일 앱이나 임베디드 시스템에 내장되어 사용되는 RDBMS (관리 툴: DB Browser for SQLite)
📝 핵심 요약
- 데이터가 작고 단순할 때는 스프레드시트가 빠르고 훌륭한 대안이 됩니다.
- 데이터가 늘어나고 무결성이 중요해지면 테이블을 쪼개어 연결하는 관계형 데이터베이스와 이를 관리해 주는 DBMS 도입이 필수적입니다.
- 분리된 데이터는 SQL을 통해 언제든 자유롭게 결합하여 유용한 정보로 가공할 수 있습니다.
댓글 남기기