개념 모델

개념 모델은 고객·주문·상품처럼 시스템이 다룰 대상을 업무의 말로 먼저 맞춰 둡니다. 대상과 그 관계만 적을 뿐 저장 방식은 아직 정하지 않습니다. 데이터 모델링에서 가장 먼저 그리는 모델입니다. 소프트웨어 설계 전반에서도 구현을 빼고 개념만 그린 모델을 같은 이름으로 부릅니다.

쉽고 빠른 이해

무슨 일을 하나 — 만들 시스템이 무엇을 다루는지 그림 한 장으로 맞춰 둡니다. 쇼핑몰이라면 「고객이 주문을 한다」와 「주문에 상품이 담긴다」를 적은 그림입니다.

왜 이렇게 하나 — 테이블부터 짜면 업무 담당자가 그 설계를 읽고 확인하기 어렵습니다. 잘못 알아들은 요구사항이 테이블에 굳습니다. 그 잘못은 데이터가 쌓인 뒤에야 드러납니다. 업무의 말로 된 그림은 만들기 전에 함께 읽고 고칠 수 있습니다.

어떻게 도나

1. 요구사항에서 다룰 대상을 뽑습니다
2. 대상끼리 어떻게 이어지는지, 몇 대 몇인지 적습니다
3. 업무 담당자와 그림을 같이 읽으며 틀린 곳을 고칩니다
4. 확정된 그림을 테이블 설계로 옮깁니다

대가 — 관리할 그림이 하나 더 생깁니다. 테이블이 바뀔 때 함께 고치지 않으면 시스템과 어긋난 그림이 남습니다.

상세

집을 새로 지을 때는 먼저 건축주와 마주 앉아 방이 몇 개 필요한지 정합니다. 거실 옆에 주방, 안방 옆에 욕실을 붙이자는 식입니다. 벽을 무엇으로 쌓을지, 배관을 어디로 낼지는 아직 꺼내지 않습니다.

개념 모델은 이 첫 대화에 해당합니다. 방은 시스템이 다룰 대상입니다. 어느 방 옆에 어느 방을 붙이나는 대상끼리의 관계입니다. 벽과 배관은 테이블·인덱스 같은 저장 결정이라 뒤로 미룹니다.

이 절은 개념 모델을 쇼핑몰 하나로 따라갑니다. 먼저 개념 모델에 무엇을 담고 무엇을 빼는지 봅니다. 이어서 왜 테이블보다 먼저 그리는지, 어떤 순서로 세우는지, 다음 모델로 어떻게 넘어가는지 봅니다. 끝에서는 이름이 비슷한 개념 스키마와 어떻게 다른지, 따로 그리지 않아도 되는 때는 언제인지 봅니다.

데이터 모델링은 담을 데이터를 무엇으로 나누고 무엇으로 이을지 정하는 일입니다. 이 일은 보통 개념 모델, 논리 모델, 물리 모델 세 개를 차례로 그리며 나아갑니다. 논리 모델은 테이블·열·키로 담는 방법을, 물리 모델은 쓸 데이터베이스에서 저장하는 방법을 정합니다. 개념 모델은 그 첫째입니다.

개념 모델은 시스템이 다룰 대상과 대상끼리의 이어짐을 업무에서 쓰는 말로 적어 둡니다. 쇼핑몰이라면 「고객이 주문을 한다」와 「주문에 상품이 담긴다」가 개념 모델의 내용입니다. 개발자와 업무 담당자는 이 그림을 같이 보며 무엇을 만들지 맞춥니다.

개념 모델에 담는 것

개념 모델은 세 가지를 담습니다. 쇼핑몰 예로 하나씩 봅니다.

첫째는 엔티티입니다. 시스템이 하나하나 가려서 기록해 둘 대상을 말합니다. 쇼핑몰에서는 고객·주문·상품이 엔티티입니다. 대상을 먼저 정해야 무엇에 대해 데이터를 모을지가 정해집니다.

둘째는 관계입니다. 엔티티끼리 어떻게 이어지는지를 동사로 적습니다. 고객과 주문 사이의 「한다」, 주문과 상품 사이의 「담긴다」가 관계입니다. 관계를 적어 두어야 「이 주문은 누가 했나」 같은 물음에 답할 길이 생깁니다.

셋째는 관계마다 붙는 카디널리티입니다. 한쪽 하나에 다른 쪽이 몇 개까지 이어질 수 있는지를 말합니다. 고객 한 명은 주문을 여럿 할 수 있습니다. 주문 하나는 고객 한 명의 것입니다. 이런 이어짐을 일대다라고 부릅니다.

주문과 상품은 양쪽이 다 여럿입니다. 주문 하나에 상품이 여럿 담깁니다. 상품 하나도 여러 주문에 들어갑니다. 이런 이어짐을 다대다라고 부릅니다.

몇 대 몇인지는 업무 규칙입니다. 그래서 개발자가 짐작으로 정하지 않고 업무 담당자에게 물어서 적습니다.

엔티티에 딸린 주요 값인 속성을 함께 적기도 합니다. 고객의 이름이나 상품의 가격이 속성입니다. 개념 모델에서는 업무를 이해하는 데 필요한 속성만 추려 적는 일이 많습니다.

세 가지를 모아 그리면 아래와 같습니다. 엔티티를 상자로, 관계를 선으로 그린 이런 그림을 ER 다이어그램(Entity-Relationship diagram, 엔티티-관계 다이어그램)이라고 부릅니다. 개념 모델은 대개 이 그림으로 그립니다.

erDiagram
    direction TB
    고객 ||--o{ 주문 : "한다"
    주문 }o--|{ 상품 : "담는다"

선 끝의 기호는 그 끝에 붙은 쪽이 몇 개인지를 말합니다. 세 갈래는 「여럿」, 세로 막대는 「하나」, 동그라미는 「없을 수도 있음」을 뜻합니다.

고객과 주문 사이 선은 이렇게 읽습니다. 주문 쪽 끝은 고객 한 명에게 주문이 없거나 여럿일 수 있다는 뜻입니다. 고객 쪽 끝은 주문 하나에 고객이 꼭 한 명 있다는 뜻입니다.

주문과 상품 사이 선은 양 끝이 다 세 갈래입니다. 그래서 다대다입니다. 상품 쪽 끝의 막대는 주문 하나에 상품이 적어도 하나 들어간다는 뜻입니다. 주문 쪽 끝의 동그라미는 상품이 어느 주문에도 안 들어갈 수 있다는 뜻입니다.

그림 어디에도 테이블 이름이나 열은 없습니다. 이 그림만 보고는 어떤 데이터베이스를 쓸지도 알 수 없습니다. 다음 소절이 그 까닭을 봅니다.

개념 모델에서 빼는 것

개념 모델은 저장에 관한 결정을 전부 뒤로 미룹니다. 무엇을 빼는지 보면 이 모델이 누구를 위해 있는지가 드러납니다.

표의 왼쪽 칸은 전부 저장하는 쪽의 말입니다. 개념 모델은 이 말들을 쓰지 않고 엔티티와 관계만으로 이야기합니다.

빼는 까닭은 둘입니다. 첫째는 함께 읽을 사람 때문입니다. 업무 담당자와 그림을 같이 읽으려면 그 사람이 모르는 말이 없어야 합니다. 외래 키나 인덱스가 섞이면 그림을 읽을 수 있는 사람이 개발자로 줄어듭니다.

둘째는 오래 남기기 위해서입니다. 저장 방식이 바뀌어도 무엇을 다루는지는 잘 안 바뀝니다. 관계형 데이터베이스를 문서 데이터베이스로 바꿔도 쇼핑몰에는 여전히 고객과 주문이 있습니다. 저장에 관한 결정을 빼 두면 개념 모델은 그런 변화를 겪어도 남습니다.

테이블보다 먼저 그리는 까닭

개발자는 요구사항을 들으면 테이블부터 짜고 싶어집니다. 그런데 테이블 설계는 업무 담당자가 읽고 맞는지 확인하기 어렵습니다. 잘못 알아들은 요구사항이 있어도 아무도 모른 채 테이블로 굳습니다.

예를 하나 듭니다. 「주문 하나는 한 곳으로만 배송한다」고 알아듣고 주문 테이블에 배송지 열을 하나 두었다고 합시다. 나중에 한 주문의 상품을 여러 곳으로 나눠 보내야 한다는 요구가 드러납니다. 그러면 테이블을 다시 나눠야 합니다. 이미 쌓인 주문 데이터도 새 모양으로 옮겨야 합니다.

개념 모델에서는 같은 문제가 선 하나로 보입니다. 주문과 배송지 사이 선이 일대일인지 일대다인지를 업무 담당자에게 물으면 됩니다. 그림 위에서 고치면 옮길 데이터가 없습니다.

개념 모델을 세우는 순서

흔히 쓰는 순서를 쇼핑몰 요구사항 한 줄로 따라갑니다. 요구사항은 「고객은 상품을 골라 주문한다. 주문 하나에 여러 상품을 담을 수 있다」입니다.

1. 요구사항 문장에서 명사를 뽑아 엔티티 후보로 둡니다. 고객·상품·주문이 나옵니다
2. 후보마다 따로 기록할 대상인지, 다른 대상에 딸린 값인지 가립니다. 딸린 값이면 속성으로 내립니다
3. 동사에서 관계를 찾습니다. 「주문한다」와 「담는다」가 관계가 됩니다
4. 관계마다 몇 대 몇인지 적습니다. 모르는 것은 업무 담당자에게 묻습니다
5. 업무 담당자와 그림을 소리 내어 읽으며 틀린 곳을 고칩니다

명사를 엔티티 후보로 두는 것은 출발점일 뿐입니다. 주소는 명사지만 고객에 딸린 글자 한 줄이면 속성입니다. 배송지를 여러 개 저장해 두고 골라 쓰는 서비스라면 주소를 따로 떼어 엔티티로 둡니다. 무엇이 엔티티인지는 요구사항이 정합니다.

논리 모델과 물리 모델로 넘어가는 길

개념 모델 다음에는 모델 두 개가 더 옵니다. 둘은 같은 내용을 점점 저장에 가깝게 옮깁니다. 세 모델이 무엇을 정하는지 쇼핑몰 예와 함께 모으면 아래와 같습니다.

위로 갈수록 업무의 말에 가깝습니다. 아래로 갈수록 저장 장치에 가깝습니다. 데이터베이스 제품을 바꾸면 물리 모델은 새로 짭니다. 개념 모델은 손대지 않고 남습니다.

옮기는 동안 개념 모델에 없던 것이 생기기도 합니다. 주문과 상품의 다대다 관계는 개념 모델에서 선 하나입니다. 그런데 주문 테이블과 상품 테이블 둘만으로는 이 이어짐을 담을 수 없습니다.

그래서 논리 모델에서는 테이블을 하나 새로 둡니다. 주문 하나와 상품 하나의 짝을 한 줄씩 적는 테이블입니다. 흔히 주문 항목이라고 부르는 이런 테이블을 연결 테이블이라고 합니다.

개념 스키마와 헷갈리는 이름

이름이 비슷한 개념 스키마는 다른 계층을 가리킵니다. 데이터베이스를 세 단계로 나눠 보는 3단계 스키마 구조에서 가운데 단계의 이름입니다.

개념 스키마는 데이터베이스 전체의 논리 구조를 적습니다. 관계형 데이터베이스라면 어떤 테이블과 열이 있는지가 개념 스키마에 적힙니다. 데이터 모델링의 말로는 개념 모델보다 논리 모델 쪽에 가깝습니다.

「개념」이라는 낱말만 보고 둘을 같은 것으로 읽으면 어긋납니다. 개념 모델은 테이블이 정해지기 전의 그림입니다. 개념 스키마는 테이블이 정해진 뒤의 구조입니다.

데이터 모델링 밖의 개념 모델

개념 모델이라는 이름은 데이터베이스 설계 밖에서도 쓰입니다. 뜻의 뼈대는 같습니다. 구현을 빼고 무엇이 있고 서로 어떻게 이어지는지만 적은 모델입니다.

객체 지향 분석에서도 클래스를 코드로 짜기 전에 업무에 나오는 개념과 그 연관을 그림으로 먼저 그립니다. 이 그림도 개념 모델이라고 부릅니다. 도메인 모델이라고도 부릅니다.

이 그림은 흔히 UML(Unified Modeling Language, 통합 모델링 언어)의 표기를 빌려 그립니다. UML은 소프트웨어 설계를 그림으로 나타내는 표준 표기법입니다. 그중 클래스를 상자로, 클래스 사이의 연관을 선으로 그리는 클래스 다이어그램을 씁니다.

따로 그리는 경우와 건너뛰는 경우

요구사항을 확인해 줄 사람이 개발자 밖에 있으면 개념 모델을 따로 그립니다. 기획자나 업무 담당자와 함께 읽을 그림이 필요하기 때문입니다. 새 시스템을 처음 설계할 때도 따로 그리는 일이 많습니다. 다룰 대상이 무엇인지부터 맞춰야 하기 때문입니다.

다룰 대상이 서넛뿐인 작은 서비스는 따로 그리지 않고 건너뛰는 일이 흔합니다. 개발자가 머릿속으로 개념 모델을 세우고 바로 테이블을 짭니다. 이때도 개념 모델이 없는 것은 아닙니다. 그림으로 남기지 않았을 뿐입니다.

따로 그린 그림은 관리할 문서가 하나 더 늘어난다는 뜻이기도 합니다. 테이블이 바뀔 때 그림을 함께 고치지 않으면 그림이 시스템과 어긋납니다. 어긋난 그림은 새로 온 사람에게 틀린 구조를 가르칩니다.

관련 항목

개념 모델이 속하는 설계 단계

데이터 모델링 · 데이터베이스 설계 · 요구사항 분석 · 논리 모델 · 물리 모델

개념 모델을 이루는 구성 요소

엔티티 · 속성 · 관계 · 카디널리티 · 식별자

개념 모델을 그리는 표기법

ER 다이어그램 · 개체 관계 모델 · UML · 클래스 다이어그램

논리 모델로 옮기며 생기는 구조

테이블 · 열 · 행 · 기본 키 · 외래 키 · 연결 테이블 · 정규화

개념 모델을 옮겨 담는 데이터 모델

관계형 모델 · 관계형 데이터베이스 · 문서 데이터베이스 · 그래프 데이터베이스

개념 모델과 헷갈리는 이웃

개념 스키마 · 3단계 스키마 구조 · 스키마 · 도메인 모델

개념 모델을 업무와 맞추는 설계 방법

객체 지향 분석 · 도메인 주도 설계 · 유비쿼터스 언어 · 이벤트 스토밍