<div data-type="callout" data-emoji="👀" data-background-color="rgba(235, 236, 237, 0.3)" style="background-color: rgba(235, 236, 237, 0.3);">데이터 모델링, 이번 기회에 제대로 공부하고 싶다면!데이터 모델링, SQL 성능 최적화 뿐만 아니라 LTR 분석 등 다양한 분석 프레임워크까지 배울 수 있는 <a href="https://datarian.io/bootcamp/sql-master" target="_blank">SQL 마스터반</a> 커리큘럼을 살펴보세요. 쿠팡, 리디, 잡플래닛 출신 데이터 분석가들이 실무에 꼭 필요한 내용만 골라 담았어요.</div>엔티티, 속성에 대해 지금까지 여러가지 관점으로 주의해야 할 점에 대해 이야기해보았습니다. 마지막으로 ER 모델의 중요 3 요소 중 ‘관계’에 대해 이야기해보려고 합니다.관계에 대해 이야기하기 위해서 ‘무결성(Integrity)’이라는 개념을 알고 있으면 좋습니다. 특히 ‘관계’와 관련된 무결성은 ‘참조 무결성’인데요. 얘기가 나온 김에 무결성이라는 것이 뭔지 알아보겠습니다.<h1 id="c4c3a1d336924713936980bf24706314">데이터 무결성(Data Integrity)</h1><blockquote>데이터 무결성(Data Integrity)은 데이터를 저장하고 관리할 때 데이터의 정확성과 일관성을 유지하기 위해 사전에 정의한 규칙이다. 데이터 무결성은 실체 무결성(Entity Integrity), 영역 무결성(Domain Integrity), 참조 무결성(Referential Integrity)이 있다. 데이터 무결성을 통해 데이터의 정확성, 일관성, 유효성, 신뢰성을 확보할 수 있고, 무효 갱신으로부터 데이터를 보호할 수 있다. 데이터 모델링 과정에서 정의된 일련의 규칙에 따라 데이터가 생성, 수정, 삭제될 수 있도록 프로그램이나 데이터베이스 기능을 강제할 수 있다. 그 결과 권한이 부여된 사용자에 의해 야기될 수 있는 의미적 에러를 방지하고, 데이터베이스 내의 데이터가 현실세계의 올바른 데이터를 갖도록 보장할 수 있다. 핵심 데이터 모델링 - 유동오</blockquote>쉽게 말해 데이터가 정확성과 일관성을 가지기 위해 몇 가지 규칙들을 지켜야 한다는 이야기입니다. 실체 무결성, 영역 무결성, 참조 무결성 3가지가 있고, 이 규칙들이 실체가 없이 말로만 있으면 지켜지지 않을 수 있으니 데이터베이스 기능을 이용해 이를 강제할 수 있습니다. 무결성을 지키기 위해 데이터베이스에서 제공하는 기능들을 ‘제약조건(Constraint)’라고 부릅니다.이어서 실체 무결성, 영역 무결성, 참조 무결성 각각의 의미와 관련 데이터베이스 기능을 알아보겠습니다. 데이터베이스는 PostgreSQL을 기준으로 합니다.<h2 id="383b141eab7742a8ad00cf20afb27dbe">실체(Entity) 무결성</h2>실체 무결성은 각 인스턴스를 유일하게 식별할 수 있어야 한다는 것입니다. 다르게 말하면, 모든 속성 값이 동일한 인스턴스가 한 엔티티 안에 2개 이상 존재할 수 없다는 뜻도 됩니다. 이 유일성을 보장하기 위해 가장 쉽게 사용할 수 있는 방법은 기본키(Primary Key) 또는 고유 제약(Unique Constraint) 조건을 설정하는 것입니다.<h3 id="12294e3405784c83a29c80fad384efe8">기본키 설정</h3>예시로 기본키 설정하는 방법을 간단하게 살펴보겠습니다. 아래는 테이블을 생성할 때 기본키를 설정하는 방법입니다.<pre><code class="language-sql">CREATE TABLE table_name (
 column_1 data_type PRIMARY KEY, 
 column_2 data_type,
 …
);</code></pre>아래와 같이 이미 생성된 테이블에 기본키를 추가할 수도 있습니다.<pre><code class="language-sql">ALTER TABLE table_name ADD PRIMARY KEY (column_1, column_2, ...);</code></pre><h3 id="480e41b9c6e14a09a384cd39f2a37877">Unique 제약 조건 설정</h3>아래는 <code>email</code> 컬럼에 고유 제약 조건을 설정한 예시입니다.<pre><code class="language-sql">CREATE TABLE person (
 id SERIAL PRIMARY KEY, 
 first_name VARCHAR (50), 
 last_name VARCHAR (50), 
 email VARCHAR (50) UNIQUE
);</code></pre>위 테이블에 이미 들어있는 <code>email</code> 값과 같은 데이터를 넣으려고 하면 아래와 같은 에러가 출력됩니다. 기본키로 설정된 컬럼도 마찬가지로 동작합니다. 이렇게 DBMS의 기본키 설정, 고유 제약 조건 설정 기능을 이용해 실체 무결성을 시스템적으로 강제할 수 있습니다.<pre><code class="language-plain text">[Err] ERROR: duplicate key value violates unique constraint &quot;person_email_key&quot;
DETAIL: Key (email)=(j.doe@postgresqltutorial.com) already exists.</code></pre>번외로, DBMS는 중복 에러를 어떻게 빠르게 찾아줄 수 있는 것일까요? 언뜻 생각을 해봤을 때에는 새로운 데이터를 넣으려고 <code>INSERT</code> 시도를 할 때마다 전체 테이블을 스캔하여 지금 새롭게 추가하려는 데이터가 테이블에 있던 데이터인지 확인하는 절차가 필요할 것 같습니다. 그러면 매번 데이터를 넣을 때마다 굉장히 많은 연산이 필요하겠지요. 이 과정에서 DBMS가 최적화를 위해 어떤 작업을 미리 해놓는지 궁금하다면 <a href="https://datarian.io/blog/postgresql-unique-indexes" target="_blank">고유 인덱스 (Unique Index)</a>를 살펴봐주세요. 여러분들이 읽기 좋도록 PostgreSQL 공식 문서를 데이터리안이 번역했습니다 😊<h2 id="c1b747c3d1704819814253aae831d64f">영역(Domain) 무결성</h2>두 번째는 영역 무결성입니다. 데이터의 속성 값이 정해진 범위를 벗어나지 않고 데이터 타입이나, 데이터의 길이 등을 일관되게 유지해야 한다는 규칙입니다. 크게 3가지 기능으로 이를 강제할 수 있습니다.<ul><li><code>CHECK</code>: 속성 값이 특정 범위 내에 있는지, 특정 형식을 갖추고 있는지 등을 체크</li><li><code>DEFAULT</code>: 값을 넣어주지 않았을 때 기본으로 사용하는 값을 지정</li><li><code>NOT NULL</code>: 값으로 NULL이 들어갈 수 없음</li></ul><code>CHECK</code>, <code>DEFAULT</code>, <code>NOT NULL</code> 제약조건 예시<pre><code class="language-sql">CREATE TABLE invoices(
 id SERIAL PRIMARY KEY,
 product_id INT NOT NULL,
 qty numeric NOT NULL DEFAULT 0,
 net_price numeric CHECK(net_price &gt; 0) 
);</code></pre><h2 id="56e58949dd7a4a719c10169120777124">참조(Referential) 무결성</h2>마지막으로 참조 무결성은 모델링에서 정의한 엔티티간의 관계를 유지해야 한다는 것입니다.<figure data-type="image-block" data-src="https://attachments.datarian.io/production-20f0ab69-f36a-4418-a9a1-3dd96e6cebf2-umOwHHon-9M9C8Ave2QapbMPpwC6hrqxo1RrYuVvoTc.png" data-align="center" data-width="100%" style="width: 100%; max-width: 100%"><img src="https://attachments.datarian.io/production-20f0ab69-f36a-4418-a9a1-3dd96e6cebf2-umOwHHon-9M9C8Ave2QapbMPpwC6hrqxo1RrYuVvoTc.png" /></figure>예를 들어, <code>customers</code> 테이블과 <code>orders</code> 테이블이 <code>customer_id</code>로 1:N 관계를 가지고 있다고 모델링에서 정의했다면 실제 데이터베이스에 들어있는 데이터도 이 규칙에 따라야 합니다. <code>customers</code> 테이블에는 데이터가 없는 고객인데, <code>orders</code> 테이블에는 존재하는 상황이 있으면 안됩니다. 이 규칙을 시스템으로 강제하기 위해 DBMS에는 외래키(Foreign Key)를 설정하는 기능이 있습니다.아래 예시는 고객(customer) 한 명에 여러 연락 수단(contact)을 저장할 필요가 있을 때 <code>customers</code>, <code>contacts</code> 테이블을 각각 만드는 상황입니다. <code>contacts</code> 테이블을 정의할 때 <code>customer_id</code>를 외래키로 설정하고, 이 외래키가 <code>customers</code> 테이블의 <code>customer_id</code> 컬럼을 참조한다고 적었습니다. <pre><code class="language-sql">CREATE TABLE customers(
 customer_id INT GENERATED ALWAYS AS IDENTITY,
 customer_name VARCHAR(255) NOT NULL,
 PRIMARY KEY(customer_id)
);

CREATE TABLE contacts(
 contact_id INT GENERATED ALWAYS AS IDENTITY,
 customer_id INT,
 contact_name VARCHAR(255) NOT NULL,
 phone VARCHAR(15),
 email VARCHAR(100),
 PRIMARY KEY(contact_id),
 CONSTRAINT fk_customer
 -- customer_id를 외래키로 설정
 FOREIGN KEY(customer_id)
 -- customers 테이블의 customer_id 컬럼 참조
 REFERENCES customers(customer_id)
);</code></pre>크게 두 가지 효과가 있습니다.<ul><li>부모 테이블인 <code>customers</code>에 없는 <code>customer_id</code>를 자식 테이블인 <code>contacts</code>에 넣을 수 없습니다.</li><li>부모 테이블인 <code>customers</code>에서 특정 <code>customer_id</code>를 삭제하거나, 업데이트 할 때 자식 테이블에도 이 사항을 반영하도록 설정할 수 있습니다.</li></ul>참조 무결성을 이해하기 위해 <code>FOREIGN KEY</code> 설정 방법을 간단하게 알아봤습니다. 더 자세한 내용을 알고싶다면 참고 자료를 봐주세요!<h1 id="179c3f96e6404af4bb95af2fff2bb00b">관계선 그리기</h1>간혹 모델링을 할 때에 엔티티, 속성까지는 잘 생각을 해놓고 관계를 정의하는데에 소홀한 분들이 있는데요(접니다). 관계, 즉 참조 무결성 제약은 오류 데이터의 진입을 막는데 굉장히 효과적인 방법이기 때문에 신경을 쓰는 것이 좋습니다.ERD를 그리는 방법에 대해서 뒤에서 다시 다루겠지만, 관계선을 그릴 때에는 부모 엔티티의 기본키가 자식 엔티티의 외래키로 내려오는 관계가 존재할 때에만 관계선을 그려줘야 합니다. 이외의 경우(LIKE, BETWEEN 등 값이 정확하게 일치하는 관계가 아닌 경우 등)는 <code>FOREIGN KEY</code> 설정을 통해 참조 무결성을 구현할 수 없고, ERD에서 관계선으로 표현하는 것도 적절하지 않습니다. 다만 이런 규칙들도 표현을 해놓아야 ERD가 설계도로서 역할을 제대로 할 수 있겠지요. 이런 경우는 관계선보다는 설명으로 적어놓는 것이 좋습니다.<h1 id="cc3c2e6608a4419eb17fbfa688fa0fd4">M:N 관계는 이렇게 해결하세요</h1><a href="https://solvesql.com/playground/" target="_blank">solvesql</a> 플레이그라운드에 있는 ‘Museum of Modern Art Collection’ 데이터베이스를 이용해 M:N 관계를 해결하는 방법을 알아보겠습니다.이 데이터는 뉴욕의 MoMA 미술관에 전시된 작품과, 작품의 작가를 담고 있습니다. 한 명의 작가가 여러 작품을 MoMA에 전시할 수 있고, 한 작품에 여러 작가가 협업을 할 수 있기 때문에 작품과 작가는 다대다 관계입니다.<figure data-type="image-block" data-src="https://attachments.datarian.io/production-b3991421-c293-4a68-8263-f63a2a5a40e9-LoTySKwQT8iygXowHJrUy5y9-ghmuLratgKqKmbepws.png" data-align="center" data-width="576" style="width: 576px; max-width: 100%"><img src="https://attachments.datarian.io/production-b3991421-c293-4a68-8263-f63a2a5a40e9-LoTySKwQT8iygXowHJrUy5y9-ghmuLratgKqKmbepws.png" width="576" /></figure>이 경우 <code>artists</code>, <code>artworks</code> 엔티티 사이에 어떻게 관계선을 그려야 할까요? 관계선을 그리기 전에 먼저 다대다 관계를 해소해주어야 합니다. <a href="https://datarian.io/blog/database-normalization" target="_blank">제 1 정규화 원칙을 다시 생각해보면</a>, 하나의 셀에 여러 개의 값을 넣어야 하거나 개념적으로 중복되는 컬럼이 있는 경우 별도의 테이블로 분리해야 합니다. 예를 들어, <code>artists</code> 테이블을 아래와 같이 만들 수는 없습니다. (프랑스 사진 작가 <a href="https://www.moma.org/artists/229" target="_blank">Eugène Atget</a>은 MoMA에 5050점의 작품을 전시하고 있는데 이 정보를 저장하려면 컬럼을 5050개 추가해야 합니다.)테이블 &lt;artists&gt;<table><tbody><tr><th>artist_id</th><th>name</th><th>nationality</th><th>gender</th><th>birth_year</th><th>death_year</th><th>artwork_1</th><th>artwork_2</th><th>artwork_3</th><th>…</th></tr><tr><td>1</td><td>Robert Arneson</td><td>American</td><td>Male</td><td>1930</td><td>1992</td><td></td><td></td><td></td><td></td></tr><tr><td>2</td><td>Doroteo Arnaiz</td><td>Spanish</td><td>Male</td><td>1936</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>3</td><td>Bill Arnold</td><td>American</td><td>Male</td><td>1941</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>4</td><td>Charles Arnoldi</td><td>American</td><td>Male</td><td>1946</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>5</td><td>Per Arnoldi</td><td>Danish</td><td>Male</td><td>1941</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>이런 경우 <code>artworks_artists</code> 같은 중간 테이블을 만들어 <code>artists</code>와 <code>artworks</code>가 서로와 직접 연결되지 않고 중간 테이블을 거쳐 연결되어야 합니다. 이 작업을 통해 다대다 관계가 해소되고 2개의 1:N 관계가 만들어졌습니다.<figure data-type="image-block" data-src="https://attachments.datarian.io/production-464d82d9-b817-42a7-a854-53f628baf723-CDNTYIPTZsVDdn2f0lE0E9T9lWEuqXu9JT1gKoz7-q0.png" data-align="center" data-width="768" style="width: 768px; max-width: 100%"><img src="https://attachments.datarian.io/production-464d82d9-b817-42a7-a854-53f628baf723-CDNTYIPTZsVDdn2f0lE0E9T9lWEuqXu9JT1gKoz7-q0.png" width="768" /></figure>데이터 모델링을 하다보면 이런 상황이 매우 흔하게 발생합니다. 예를 들어, 데이터리안의 캠프와 수강생의 관계도 다대다 관계입니다. 한 캠프에 여러 명의 수강생이 있고 또 한 명의 수강생이 여러 캠프를 들을 수 있기 때문이죠. 이런 경우에도 수강생-캠프의 관계만 저장하는 <code>artworks_artists</code> 같은 테이블이 필요합니다. 저희 DB에는 <code>course_registration</code>이라는 이름의 테이블이 이 역할을 해주고 있습니다.마지막으로 초보자의 입장에서 어려움을 느끼기 쉬운 다대다 관계까지 이야기를 해보았습니다. 다음 글에서는 지금까지 배운 내용을 종합하여 ERD를 그려보겠습니다.<h1 id="92e0c9b3bb5d4fe0a64f671bfa1b428e">참고 자료</h1>PostgreSQL Tutorial - Database Constraints<ul><li><a href="https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-primary-key/" target="_blank">Primary Key</a></li><li><a href="https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-foreign-key/" target="_blank">Foreign Key</a></li><li><a href="https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-unique-constraint/" target="_blank">UNIQUE Constraint</a></li><li><a href="https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-check-constraint/" target="_blank">CHECK Constraint</a></li><li><a href="https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-not-null-constraint/" target="_blank">NOT NULL Constraint</a></li><li><a href="https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-default-value/" target="_blank">DEFAULT Constraint</a></li></ul>

데이터 표준화, 식별자, 유연함을 가진 속성 모델링

속성(Attribute) 톺아보기

참조 무결성 제약은 오류 데이터의 진입을 막는데 굉장히 효과적인 방법입니다.

관계(Relationship) 톺아보기 (feat. 데이터 무결성)

ERD를 어떻게 읽어야 하는지 모른다면, 이번 글에서 그 방법을 익혀봅시다.

ERD 어떻게 읽어야 하나요?

1정규형부터 3정규형까지, 데이터 모델링의 꽃인 정규화 이론에 대해서 쉽게 배워봐요.

데이터베이스 정규화(Normalization) 알아보기

ERD에서 자주 본 PK, FK의 정확한 의미를 알아봅시다.

여러 종류의 Key 이해하기 (feat. PK, FK의 정확한 의미)

ERD에서 관계 표기(Crow’s foot)를 이해하기 어려웠다면 이 글에 있는 꿀팁을 참고해보세요.

ER 모델의 구성 요소 3가지: 엔티티, 속성, 관계

엔티티를 잘 정의하기 위해서는 본질을 꿰뚫어보는 눈이 필요합니다

엔티티(Entity) 톺아보기

데이터 모델링의 종류를 이해하고 ERD를 직접 그려봅시다.

관계(Relationship) 톺아보기 (feat. 데이터 무결성)

Contents

데이터 분석 소식을
매월 받아보세요

알아두면 쓸데있는 데이터 모델링 모아보기

함께 읽어보면 좋은 글

MySQL 서브쿼리 연산자 (비교 연산자, IN, ANY/SOME, ALL, EXISTS)

인덱스 조합 기능 (Combining Multiple Indexes)

인덱스와 ORDER BY

데이터 분석 소식을
매월 받아보세요데이터 분석 소식을 받아보세요

관계(Relationship) 톺아보기 (feat. 데이터 무결성)

Contents

데이터 분석 소식을 매월 받아보세요

알아두면 쓸데있는 데이터 모델링 모아보기

함께 읽어보면 좋은 글

MySQL 서브쿼리 연산자 (비교 연산자, IN, ANY/SOME, ALL, EXISTS)

인덱스 조합 기능 (Combining Multiple Indexes)

인덱스와 ORDER BY

데이터 분석 소식을 매월 받아보세요데이터 분석 소식을 받아보세요

데이터 분석 소식을
매월 받아보세요

데이터 분석 소식을
매월 받아보세요데이터 분석 소식을 받아보세요