2. Data Models and Query Languages

관계형, 문서, 그래프 모델과 질의 언어

  • Haram Lee
  • 2026-04-05
  • studies / Topics / DDIA
#ddia #database #data-modeling
  • 데이터 모델의 중요성
    • 데이터 모델은 소프트웨어를 어떻게 작성하는지뿐 아니라, 문제를 어떻게 바라보고 해결할지에도 영향을 줌
    • 대부분의 애플리케이션은 데이터 모델을 계층적으로 쌓아 만듦
    • 각 계층은 아래 계층의 복잡성을 숨기는 추상화
    • 모델마다 잘하는 일과 못하는 일이 다르므로 문제에 맞는 모델을 고르는 게 중요
flowchart TD
  world["현실 세계"] --> app["객체 / 데이터 구조 / API"]
  app --> storage["JSON·XML, 관계형 테이블, 그래프 모델"]
  storage --> bytes["메모리 / 디스크 / 네트워크 상의 바이트 표현"]

2.1 Relational Model Versus Document Model

  • 관계형 모델
    • 데이터를 테이블(관계)과 로우(튜플)로 표현
    • SQL이 대표 질의 언어
    • 구현 세부를 숨기고, 정규화된 구조로 저장하고 질의하는 데 강함
    • 조인, 다대일, 다대다 관계를 다루기 유리
  • NoSQL의 등장
    • 관계형 모델만으로는 어려운 요구를 다루려고 등장
    • 배경: 대규모 데이터셋과 높은 쓰기 처리량, 오픈소스 선호, 특수한 질의 패턴, 더 유연한 데이터 모델
    • 관계형 DB를 대체한다기보다 함께 쓰는 경우가 많음: 다중 저장소 지속성(polyglot persistence)
  • 객체-관계형 불일치
    • 객체지향 언어의 객체 구조와 관계형 테이블 구조는 잘 안 맞는 경우가 많음: 임피던스 불일치(impedance mismatch)
    • ORM이 완화하지만 완전히 없애지는 못함
  • 문서 모델
    • 관련 데이터를 문서(JSON 등) 하나에 묶어 저장
    • 이력서, 프로필처럼 문서 단위로 읽고 쓰는 데이터에 적합
    • 장점
      • 애플리케이션 객체 구조와 더 비슷함
      • 관련 정보가 한곳에 있어 지역성(locality)이 좋음
      • 일대다 트리 구조를 자연스럽게 표현
    • 단점
      • 조인 지원이 약한 경우가 많음
      • 다대일·다대다 관계가 많아질수록 불편함
      • 일부만 필요해도 문서 전체를 읽어야 할 수 있음
  • 정규화와 ID 참조
    • 사람이 읽는 문자열 대신 ID를 저장하면 중복이 줄어듦
    • 의미 있는 정보는 한 곳에만 두고, 다른 곳에서는 ID로 참조하는 것이 정규화(normalization)의 핵심
    • 관계형 모델은 이런 참조와 조인에 강하고, 문서 모델은 트리 구조엔 강하지만 서로 얽힌 데이터엔 약할 수 있음
  • 어떤 모델이 더 적합한가
    • 문서처럼 생긴 일대다 트리 구조면 문서 모델
    • 다대다 관계와 상호 연결이 많으면 관계형 모델
    • 어느 쪽이 무조건 좋은 게 아니라 데이터의 관계 구조가 선택 기준
  • 문서 모델의 스키마 유연성
    • 문서 DB는 보통 스키마를 강제하지 않음. 그래서 흔히 스키마리스(schemaless)라고 부르지만, 실제로는 읽는 쪽이 암묵적으로 구조를 가정함
    • 더 정확히는
      • 쓰기 스키마(schema-on-write): 관계형 DB 중심
      • 읽기 스키마(schema-on-read): 문서 모델 중심
    • 구조가 자주 바뀌거나 형태가 제각각이면 문서 모델이, 구조가 일정하고 예측 가능하면 명시적 스키마가 유리
  • 문서 DB와 관계형 DB의 경계
    • 관계형 DB도 JSON과 XML 지원을 강화하고, 문서 DB도 참조와 조인 비슷한 기능을 일부 지원
    • 둘이 서로의 장점을 흡수하며 비슷해지는 중

2.2 Query Languages for Data

  • 선언형 vs 명령형
    • 명령형: 데이터를 어떻게 찾을지 절차를 하나씩 직접 지정
    • 선언형: 어떤 결과를 원하는지만 기술 (SQL이 대표)
    • 선언형의 장점
      • 더 간결함
      • 구현 세부를 숨길 수 있음
      • DB가 내부적으로 최적화하기 쉬움
      • 병렬 처리에 유리함
  • 질의 최적화기(query optimizer)
    • 어떤 순서로 실행할지, 어떤 색인을 쓸지를 자동으로 결정
    • 개발자가 접근 경로를 세세하게 짤 필요가 없다는 점이 관계형 모델의 큰 장점
  • 맵리듀스(MapReduce)
    • 대량 데이터를 여러 장비에서 처리하기 위한 프로그래밍 모델
    • 일부 NoSQL이 이를 이용한 질의를 지원했지만, SQL보다 저수준이라 사용성이 떨어짐
    • 그래서 많은 시스템이 결국 선언형 집계 언어를 다시 도입함

2.3 Graph-Like Data Models

  • 그래프 모델이 필요한 경우
    • 다대다 관계가 흔하고 연결 구조가 복잡할수록 그래프가 자연스러움
    • e.g. 소셜 네트워크, 웹 링크 구조, 도로·철도 네트워크, 사람-장소-이벤트-조직 간 관계
  • 기본 요소
    • 정점(vertex): 사람, 장소, 조직 같은 개체
    • 간선(edge): 개체 사이의 관계
    • 서로 다른 종류의 개체와 관계를 한 저장소에 함께 표현하기 좋음
flowchart LR
  person["Person"] -- "LIVES_IN" --> city["City"]
  person -- "WORKS_AT" --> org["Organization"]
  org -- "LOCATED_IN" --> city
  • 속성 그래프(property graph)
    • 정점: 고유 식별자, 속성(키-값), 유입·유출 간선
    • 간선: 고유 식별자, 시작 정점과 끝 정점, 관계 레이블, 속성
    • 장점: 관계 구조를 유연하게 확장할 수 있고, 상호 연결이 많은 데이터를 표현하기 쉬움, 새 기능이 생겨도 구조를 비교적 자연스럽게 늘릴 수 있음
  • 사이퍼(Cypher)
    • 그래프 DB(e.g. Neo4j)의 선언형 질의 언어
    • 노드와 간선을 패턴처럼 써서 질의하므로 복잡한 그래프 순회를 비교적 직관적으로 표현할 수 있음
  • SQL과 그래프 질의
    • 그래프도 관계형 테이블로 표현할 수는 있음
    • 하지만 가변 길이 경로를 따라가는 질의는 SQL에서 복잡해짐. 그래서 전용 모델과 언어가 더 자연스러운 경우가 많음
  • 트리플 저장소(triple store)
    • (주어, 서술어, 목적어) 형태로 저장
    • 속성 그래프와 거의 같은 생각을 다른 용어로 표현한 모델
    • RDF, 시맨틱 웹과 연결되지만 꼭 웹 공개용이 아니어도 내부 데이터 모델로 쓸 수 있음
  • 스파클(SPARQL)
    • RDF와 트리플 저장소용 선언형 질의 언어로, 패턴 매칭 방식
  • 데이터로그(Datalog)
    • 오래된 규칙 기반 질의 언어로, 현대 그래프 질의 언어의 이론적 기반
    • 사실(fact)과 규칙(rule)으로 새로운 사실을 유도하는 방식

2.4 Summary

  • 관계형 모델
    • 조인, 정규화, 다대다 관계에 강함
    • 구조가 비교적 명확하고 반복적인 데이터에 적합
  • 문서 모델
    • 문서 단위 데이터, 일대다 트리 구조에 강함
    • 유연한 스키마와 지역성이 장점
  • 그래프 모델
    • 상호 연결이 많은 데이터에 가장 자연스러움
    • 복잡한 관계 탐색과 경로 질의에 강함
Discussion