데이터 모델링이란?

데이터 모델링은 데이터베이스가 데이터를 어떻게 저장할지 정하기 전에 엔터티, 속성, 관계를 정리하는 과정입니다. 엔터티는 쉬운 부분입니다. 어떤 제품이든 자신의 사용자, 주문, 게시물이 무엇인지 압니다. 진짜 기술은 관계에 있습니다. 어떤 레코드가 어떤 레코드를 가리키는지, 몇 개나 가리키는지, 그 연결이 물리적으로 어디에 존재하는지입니다. 연결을 제대로 잡으면 쿼리는 저절로 써지고, 잘못 잡으면 모든 기능이 스키마와 싸우게 됩니다.

핵심 요약

같은 관계, 두 세계

먼저 관계형입니다. 외래 키가 일대다를 담당하고, 다대다는 연결 테이블을 통해 분해해야 합니다:

-- 1:N — 외래 키는 "다" 쪽에 둡니다
CREATE TABLE books (
  id        bigint PRIMARY KEY,
  title     text   NOT NULL,
  author_id bigint NOT NULL REFERENCES authors(id) ON DELETE CASCADE
);

-- M:N — FK 하나로는 표현할 수 없으므로 연결 테이블이 두 키를 모두 담습니다
CREATE TABLE book_genres (
  book_id  bigint REFERENCES books(id),
  genre_id bigint REFERENCES genres(id),
  added_at timestamptz DEFAULT now(),     -- 연결 테이블도 속성을 가질 수 있음
  PRIMARY KEY (book_id, genre_id)         -- 복합 키: 하나의 연결은 한 번만
);

문서 세계에서도 모델은 같습니다. 일대다 연결은 타입이 지정된 Pointer이고, 다대다 연결은 Relation입니다. 따로 고안할 연결 테이블이 없으며, 연결은 애플리케이션 코드에서 선언합니다:

// JavaScript / Node.js — Back4app JS SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
const author = await new Parse.Query('Author').get(authorId);

const book = new Parse.Object('Book');
book.set('title', 'Dune');
book.set('author', author);              // Pointer — typed one-to-many edge
await book.save();

const genres = book.relation('genres');  // Relation — many-to-many, unbounded
genres.add([sciFi, classics]);
await book.save();

// Flutter / Dart — Back4app Flutter SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
final book = ParseObject('Book')
  ..set('title', 'Dune')
  ..set('author', author.toPointer()); // Pointer — typed one-to-many edge
await book.save();

book.addRelation('genres', [sciFi, classics]); // Relation — many-to-many
await book.save();

// iOS / Swift — Back4app Swift SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
var book = Book()
book.title = "Dune"
book.author = try author.toPointer()   // Pointer — typed one-to-many edge
let saved = try await book.save()

let relation = try saved.relation("genres")
try await relation.add([sciFi, classics]).save() // Relation — many-to-many

// Android / Kotlin — Back4app Android SDK
// One-to-many: a Pointer. Many-to-many: a Relation.
val book = ParseObject("Book").apply {
  put("title", "Dune")
  put("author", author)                 // Pointer — typed one-to-many edge
}
book.save()

val genres = book.getRelation<ParseObject>("genres") // Relation — many-to-many
genres.add(sciFi)
genres.add(classics)
book.save()

개념 vs. 논리 vs. 물리: 세 가지 수준

세 수준이 강제하는 규율은 단순합니다. 팀이 아직 “주문”이 무엇인지 합의하지 못했다면, 인덱스를 두고 논쟁할 때가 아닙니다.

모든 관계, 모든 구현

검색 결과 상위 문서들이 만들지 않은 표입니다. 각 연결 유형과 두 세계에서의 구현을 함께 정리했습니다:

다이어그램을 읽기 위한 카디널리티 표기법도 알아 둘 만합니다. 까마귀발(crow’s foot) 표기법은 “하나”를 막대로, “다수”를 세 갈래 포크로 그립니다. ER 전통은 선 위에 1과 N을 적고, UML은 1과 * 같은 다중성을 적습니다. 방언은 셋이지만 문법은 하나입니다.

정규화, 비정규화, 아니면 임베딩?

관계형 모델링은 정규화에서 출발합니다. 모든 사실이 한 곳에만 존재하도록 데이터를 나누어, 쓰기를 이상 현상(anomaly)으로부터 보호합니다. 분석 모델링과 문서 모델링은 이 원칙을 의도적으로 구부립니다. 비정규화는 읽기가 잦은 필드를 복제해 조인을 없애고, 임베딩은 비정규화의 문서 네이티브 사촌입니다. 임베딩 vs. 참조 체크리스트는 세 가지 질문으로 압축됩니다. 함께 읽힙니까? 하나의 부모가 소유합니까? 크기가 제한됩니까? 셋 다 “예”라면 임베딩하고, 하나라도 “아니요”라면 참조합니다. 그리고 이 모든 것 위에, 범용 가이드들이 건너뛰는 현대의 규칙이 있습니다. 쿼리부터 나열하는 것입니다. 모델이 처리해야 할 접근 패턴을 적은 비용으로 처리할 수 있을 때 그 모델은 올바르며, 엔터티만으로는 그것을 알 수 없습니다.

일반적인 사용 사례

• 새 백엔드 설계. 고전적인 절차입니다. 엔터티의 이름을 정하고, 연결을 그리고, 위 표에 따라 연결마다 구현을 고릅니다. 이 모든 일을 첫 줄의 코드를 쓰기 전에 합니다.
• 속성을 가진 연결 테이블 패턴. 수강 등록, 멤버십, 주문 항목처럼 연결 자체에 데이터(날짜, 수량, 역할)가 있다면, 연결 테이블(또는 Pointer 두 개를 가진 연결 클래스)은 일급 엔터티입니다.
• 커져 버린 스키마 정리. 증상이 연결을 가리킵니다. 중복된 행은 잘못 모델링된 다대다를, 비대해진 문서는 크기 제한 없는 임베딩을 드러냅니다.
• 세계 간 마이그레이션. 관계형에서 문서형으로 옮긴다는 것은 모든 FK를 임베딩으로 할지 Pointer로 할지 다시 결정한다는 뜻이며, 위의 표가 그 번역 사전입니다.
• AI와 분석 피드. 데이터 웨어하우스는 연결이 명시적이고 안정적이기를 원합니다. 모델링 부채는 데이터를 내보내려는 날 드러납니다.

각 연결은 어떻게 모델링해야 할까? 결정 매트릭스

한계와 트레이드오프

• 모델은 가정을 고정합니다. “사용자는 주소가 하나” 같은 카디널리티 결정은 스키마가 됩니다. 종이 위에서는 바꾸기 쉽지만 출시 후에는 비쌉니다. 내일의 카디널리티를 기준으로 모델링해야 합니다.
• 두 세계 모두 인덱스 없는 연결에 대가를 치르게 합니다. FK 열과 Pointer 필드는 조인 경로입니다. 여기에 인덱스를 빠뜨리는 것이 가장 흔한, 그리고 드러나지 않는 성능 버그입니다.
• 임베딩은 무결성을 지역성과 맞바꿉니다. 임베딩된 사본이 원본과 일관성을 유지하도록 강제하는 엔진은 없습니다. 그 책임은 이제 애플리케이션의 업데이트 로직에 있습니다.
• 연결 테이블은 조인을 늘리고, Relation은 조인을 숨깁니다. 모든 다대다 읽기는 연결 저장소를 거칩니다. 어느 세계에 있든 쿼리 경로의 비용을 미리 계산해야 합니다.
• 접근 패턴 중심 모델링에도 비용이 있습니다. 오늘의 쿼리에 최적화하면 스키마가 오늘의 제품에 묶일 수 있습니다. 중립적인 기준점으로 개념 모델을 계속 유지하는 것이 좋습니다.

Back4app에서의 데이터 모델링

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. Back4app의 모델링 어휘는 위 표들의 문서형 열을 일급 기능으로 만든 것입니다. Pointer는 타입이 지정된 일대다 연결이고, Relation은 직접 만든 연결 테이블 없이 다대다를 담당하며, 배열은 크기가 제한된 소수 관계를 처리합니다. 선언한 모든 연결은 즉시 탐색할 수 있습니다. include()는 한 번의 요청으로 Pointer를 따라가고, GraphQL은 한 번의 쿼리로 Relation을 중첩해 가져옵니다. 스키마는 대시보드에서 늘 보이고 편집할 수 있으므로, 물리 모델이 개념 모델을 설계한 팀의 시야에서 벗어나는 일이 없습니다.