관계형 데이터 모델

옛날 옛적, 공룡이 엄청 컸던 시절... 아니, 사실 1970년에 에드거 코드라는 사람이 있었어. 이 사람은 데이터의 혼돈이 이제는 창의적인 어질러짐을 넘어서 시간과 자원을 빨아먹는 블랙홀 같다고 생각했지. 에드거는 오래 고민하다가 모든 걸 정리할 방법을 생각해냈고, 동시에 데이터를 깔끔하게 테이블에 정렬하는, 마치 완벽한 도서관 책장처럼 만드는 세계의 기초를 만들었어. 행, 열, 질서 — 그리고 "이 정도면 됐지"나 "뭐, 다 알잖아" 같은 건 이제 안 통함.

관계형 모델은 데이터를 테이블 형태로 표현하는 걸 기본으로 해. 각 테이블은 행과 열로 구성돼. 직관적으로 이해되지? 행은 레코드(데이터 한 줄), 열은 그 레코드의 속성이나 특성이야. 이런 방식 덕분에 데이터 처리랑 조작이 훨씬 쉬워져.

예를 들어, 네가 인터넷 쇼핑몰에서 주문한다고 해보자. 이 주문이 제대로 처리되고 배송되려면, 시스템은 여러 가지를 알아야 해: 네가 누구인지(구매자), 어떤 배송 서비스를 골랐는지, 어디로 보내야 하는지, 그리고 배송 상태는 어떻게 추적할지 등등.

만약 이 모든 정보가 하나의 거대한 테이블에 다 들어있다면, 진짜 난장판이 됐을 거야. 데이터가 중복되고, 업데이트도 힘들고, 필요한 정보를 빨리 찾는 건 더더욱 어렵지. 관계형 방식은 정보를 여러 테이블로 나눠서, 테이블끼리 정보를 주고받게 해서 질서를 잡아줘.

아래 그림은 배송 추적 프로세스에서 데이터가 어떻게 구성되는지 보여주는 예시야:

• 구매자 - 여기엔 각 고객에 대한 정보가 저장돼. 고유한 구매자 번호가 있어.
• 배송 서비스 - 이 테이블엔 배송을 담당할 수 있는 서비스 목록이 들어있고, 각 서비스마다 고유한 서비스 번호가 있어.
• 주문 배송 - 이건 중심이 되는 연결 테이블이야. 각 행이 하나의 배송을 의미해. 배송 번호가 있고, 구매자와 배송 서비스, 특정 주문, 날짜, 현재 상태 등등을 참조해.

화살표는 주문 배송 테이블의 레코드가 구매자랑 배송 서비스 테이블의 레코드와 어떻게 연결되는지 보여줘.

주문 배송 테이블의 예시:

이런 방식의 장점:

• 고객이나 배송 서비스 정보는 한 번만 저장하면 돼서, 각 배송 레코드마다 반복할 필요가 없어.
• 고유 번호(키라고도 해)를 통한 연결 덕분에, 예를 들어 존재하지 않는 고객이나 없는 서비스로 배송이 생기는 걸 막을 수 있어.
• 여러 테이블의 데이터를 쉽게 조합해서 복잡한 리포트나 원하는 결과를 뽑아낼 수 있어.
• 데이터를 한 군데서만 바꾸면, 관련된 모든 작업에 바로 적용돼 (예: 배송 서비스 전화번호 변경).

관계형 데이터베이스 구조

관계형 데이터베이스의 핵심은 테이블이야. 각 테이블은 다음을 가져:

• 이름 (Table Name) — 테이블을 구분할 수 있게 해줘. 예를 들어 customers 같은 거.
• 열(Columns/Attributes) 집합 — 객체의 속성을 정의해.
  • 고유 번호(Primary Key) 역할을 하는 열의 이름은 보통 이름_id 패턴을 써. 여기서 _id는 "identifier"라는 뜻이야. 예를 들어 구매자 번호는 customer_id가 돼.
  • 예를 들어 customers 테이블엔 customer_id, first_name, email 등이 있을 수 있어.
• 행(Row/Record) 데이터 — customers 테이블의 한 행에는 한 명의 구매자 정보가 다 들어있지 (101, Alex Song 등).

예시 테이블 — customers:

테이블 키

각 행을 유일하게 구분하려면 기본 키(Primary Key, PK)가 필요해. 이건 한 열(또는 여러 열)로, 각 행마다 값이 유일하고 비어있을 수 없어. 쉽게 말해, 각 레코드의 고유 번호야. 예를 들어 customers 테이블의 customer_id는 각 구매자를 딱 하나로 구분해.

기본 키는 여권, 아니 여권 번호랑 비슷해. 각 객체마다 유일하지. 그래서 이름이 같은 행이 있어도 문제없어.

테이블 간 연결을 만들 때는 외래 키(Foreign Key, FK)를 써. 이건 한 테이블의 열이 다른 테이블의 기본 키를 참조하는 거야. 외래 키는 테이블 사이의 "다리" 같은 거지. 보통 외래 키 열 이름은 참조하는 기본 키 이름이랑 같아. 예를 들어 deliveries 테이블의 customer_id는 customers 테이블의 customer_id 값을 저장해서, 배송과 구매자를 연결해.

이건 아까 본 구조랑 비슷한데, 좀 더 현실적으로 바꾼 버전이야.

• customers 테이블엔 고객 정보가 들어있고, 기본 키는 customer_id야.
• delivery_services 테이블엔 배송 서비스 정보가 들어있고, 기본 키는 service_id야.
• orders 테이블(배송 테이블에서 order_id로 참조함)은 주문 정보를 위한 거고, 기본 키는 order_id야.
• deliveries 테이블은 배송 작업을 추적하는 중심 테이블이야.
  • 자기만의 기본 키: delivery_id
  • 세 개의 외래 키로 연결돼:
    • customer_id (FK): customers 테이블의 특정 구매자와 연결.
    • service_id (FK): delivery_services 테이블의 선택한 서비스와 연결.
    • order_id (FK): orders 테이블의 해당 주문과 연결.
  • created_date 필드는 배송 레코드가 만들어진 날짜와 시간을 나타내.

이렇게 기본 키와 외래 키를 쓰면 데이터 무결성이 보장돼. 예를 들어 customer_id나 order_id가 해당 테이블에 없으면 배송 레코드를 만들 수 없어. 그리고 연결된 정보를 유연하게 뽑아낼 수 있어.

관계형 모델의 장점

관계형 모델은 다른 방식에 비해 진짜 강력한 장점이 많아:

1. 구조가 단순함. 열과 행으로 된 테이블은 누구나 쉽게 이해할 수 있어.
2. 데이터 작업의 유연성. 새로운 데이터를 추가하거나 바꿔도 무결성이 깨지지 않아.
3. 복잡한 쿼리 지원. SQL을 쓰면 여러 테이블에서 데이터를 뽑고, 조합하고, 필터링하고, 원하는 건 거의 다 할 수 있어. 예를 들어, 특정 과목을 듣는 모든 학생을 찾는 것도 식은 죽 먹기!
4. 키를 통한 데이터 무결성. 기본 키와 외래 키를 쓰면 데이터가 항상 일관성 있게 유지돼. 예를 들어, 없는 과목에 학생을 등록하는 건 불가능해.

관계형 데이터 모델은 현대 데이터베이스의 기본이야. 단순하고, 강력하고, 구조화된 데이터를 저장하는 데 완전 딱 맞아. 에드거 코드가 말했듯이: "정리하지 않으면 망한다!" (뭐, 실제로는 좀 다르게 말했지만, 대충 이런 느낌이야...). 다음 강의에서는 관계형 모델이 다른 데이터베이스(예: NoSQL)랑 어떻게 다른지, 그리고 각각 어디에 쓰면 좋은지 알아볼 거야.