본문으로 건너뛰기
5분

엔티티와 관계

왜 조인 대신 관계로 표현하는지, 엔티티와 관계가 각각 무엇을 담는지 설명합니다.

엔티티는 직원, 프로젝트, 팀, 거래처처럼 현실에 존재하는 대상입니다. 표의 한 행이 아니라 개념 자체를 가리키므로, 같은 직원이 참여 기록과 팀 명단에 각각 등장해도 엔티티는 하나입니다.

관계는 두 엔티티가 어떻게 이어지는지를 담습니다. 직원이 프로젝트에 참여하고, 프로젝트가 거래처와 함께하는 연결에는 방향과 이름이 있습니다. 조인은 질문할 때마다 다시 쓰는 일회성 연결이지만, 관계는 모델에 남아 다음 질문에서도 그대로 쓰입니다.

엔티티는 표가 아니라 개념입니다

엔티티를 만들 때 정의하는 속성은 특정 표의 컬럼 목록이 아니라 그 개념이 가지는 성질입니다. 직원이라는 엔티티에 소속 팀과 입사일이 있다면, 그 값이 어느 표에서 오는지는 나중 문제입니다.

이 구분이 실제로 드러나는 경우는 원본이 여러 개일 때입니다. 직원 정보가 세 표에 나뉘어 있어도 엔티티는 하나로 두고, 세 표를 각각 그 엔티티로 적재합니다. 표를 그대로 엔티티로 옮기면 표 개수만큼 개념이 생기고, 같은 직원을 세 번 세는 문제가 모델 안으로 들어옵니다.

다이어그램을 불러오는 중입니다. Mermaid 원본:

flowchart LR
    accTitle: 세 원본 표가 직원 엔티티 하나로 모이는 구조
    accDescr: 직원 명단, 발령 이력, 자격 기록 세 표가 각각 적재되어 직원 엔티티 하나를 이룹니다. 원본 표가 셋이어도 엔티티는 하나입니다.
    T1[직원 명단 표] -->|적재| E[직원 엔티티]
    T2[발령 이력 표] -->|적재| E
    T3[자격 기록 표] -->|적재| E

관계는 모델에 남습니다

조인은 질의 안에서만 존재합니다. 어떤 열끼리 이어지는지 아는 사람이 매번 다시 작성하고, 그 지식은 질의문 밖에 남지 않습니다.

관계는 이름과 방향을 가진 자원으로 모델에 저장됩니다. 직원이 프로젝트에 참여한다는 연결에 join_project 같은 이름을 붙이면, 다음 사람은 어떤 열끼리 맞춰야 하는지 다시 알아낼 필요가 없습니다. 방향이 필요한 이유도 여기에 있습니다. 직원과 팀 사이의 연결은 어느 쪽이 속하는 쪽이고 어느 쪽이 품는 쪽인지에 따라 뜻이 달라지고, 그 차이는 모델이 기억해야 합니다.

식별 키가 관계를 가능하게 합니다

엔티티에는 인스턴스를 구분하는 식별 키가 필요합니다. 식별 키는 같은 대상을 두 번 넣지 않기 위한 기준이자, 관계가 양 끝을 가리키는 근거입니다.

다이어그램을 불러오는 중입니다. Mermaid 원본:

flowchart LR
    accTitle: 관계가 두 엔티티의 식별 키로 양 끝을 가리키는 구조
    accDescr: 직원 엔티티는 emp_no를, 프로젝트 엔티티는 prj_cd를 식별 키로 가집니다. join_project 관계는 두 식별 키 값을 참조 컬럼으로 받아 양 끝을 가리키고, 관계 행 자신은 시스템이 관리하는 구조 컬럼 id로 구분됩니다.
    S[직원 엔티티<br/>식별 키 emp_no] -->|소스 식별 키| R[join_project 관계<br/>행 구분은 구조 컬럼 id]
    R -->|대상 식별 키| T[프로젝트 엔티티<br/>식별 키 prj_cd]
  • 엔티티 인스턴스는 식별 키를 기준으로 갱신되므로, 같은 키가 다시 들어오면 새 행이 아니라 갱신이 됩니다.
  • 관계는 소스와 대상 엔티티의 식별 키 값을 참조 컬럼으로 전달받습니다. 양쪽 중 하나라도 식별 키가 없으면 관계 자체를 만들 수 없습니다.
  • 관계 행 자신은 시스템이 관리하는 구조 컬럼 id로 구분됩니다. 사용자가 고른 식별 키는 엔티티의 것이고, 관계의 것이 아닙니다.

식별 키를 고르는 일이 모델링에서 가장 먼저 막히는 지점인 이유가 여기 있습니다. 무엇으로 같은 대상을 판정할지 정하지 못하면 적재도 관계도 진행되지 않습니다.

엔티티로 만들지 속성으로 둘지

모든 명사를 엔티티로 만들 필요는 없습니다. 판단 기준은 두 가지입니다.

첫째, 그 대상이 독립적으로 조회되는지 봅니다. 프로젝트의 담당 거래처를 이름 문자열로만 쓴다면 속성으로 충분하지만, 거래처별로 무엇이 걸려 있는지 되묻는다면 엔티티가 맞습니다.

둘째, 다른 대상과 이어지는지 봅니다. 관계의 끝에 놓일 일이 없는 값은 속성으로 두는 편이 모델을 가볍게 유지합니다. 엔티티를 늘리면 표현력이 늘지만 적재해야 할 것과 관리해야 할 식별 키도 함께 늘어납니다.