<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><a href="https://datarian.io/blog/what-are-the-components-of-er-diagrams-in-dbms" target="_blank">이전 글</a>에서 ER 모델에 관해 잘 이해하고 오셨나요? 혹시 아직 보지 않으셨다면, 먼저 읽어보고 오셔야 이번 글 이해가 더 쉬울 거예요. 그럼, 이번 글에서는 이전 글에서 배운 엔티티, 속성, 관계의 개념을 다시 한번 짚어보면서 ERD에 관해 이야기해 보겠습니다. <h1 id="3e8a31df1d66463cb18b87531ab81ee7">ERD란?</h1>데이터 모델링은 건축 설계와 비슷해요. 아무런 계획 없이 빈 땅에 바로 건물을 짓는 것이 아니라, 여러 설계 단계를 거쳐 도면을 수정하고 시공에 들어갑니다. 데이터 모델링을 건축 설계에 비유하자면, ERD는 설계 도면과 같아요. 아래에 첨부한 이미지가 바로 ERD인데요. 아마 데이터베이스에 있는 데이터를 다룰 때 이런 이미지를 보신 적이 있을 거예요. 혹시 보신 적 없더라도! 저와 차근차근 알아가봐요🖐️<figure data-type="image-block" data-src="https://attachments.datarian.io/production-ce478fb4-e040-41d8-8f11-a9332f58dc07-agrRNvzr0CcX_nekT1mPtqxfrBIaSjNyEDnQfX4f8U0.png" data-align="center" data-width="100%" style="width: 100%; max-width: 100%"><img src="https://attachments.datarian.io/production-ce478fb4-e040-41d8-8f11-a9332f58dc07-agrRNvzr0CcX_nekT1mPtqxfrBIaSjNyEDnQfX4f8U0.png" /></figure>ERD는 Entity Relationship Diagram의 약자예요. 개체 관계 지도, 개체 관계 다이어그램이라고도 부릅니다. 데이터베이스 안에 있는 개체(Entity) 간의 관계(Relationship)를 시각화해서 보여주는 방식을 말해요. <a href="https://datarian.io/blog/what-are-the-components-of-er-diagrams-in-dbms" target="_blank">이전 글</a>에서 배운 ER 모델을 시각적으로 보여주는 방식이 바로 ERD입니다. 간단하게는 데이터 구조를 나타낸 설계 문서라고 생각해 주세요. ER 모델의 종류는 개념 모델, 논리 모델, 물리 모델로 나누어집니다. 이에 따라 도식화하는 방법, 즉 ERD를 그리는 방법도 달라지는데요. 이번 글에서 다룰 ERD는 논리 모델 수준에서 구현한 ERD인 점 참고해 주세요.ERD는 주로 관계형 데이터베이스를 설계하거나 디버깅하는 데 사용됩니다. 사실 데이터 분석가들은 직접 데이터베이스를 설계하는 일이 많지는 않고, 이미 설계된 데이터베이스에서 데이터를 가져와서 분석하는 일을 주로 해요. 이럴 때 ERD가 있어야 데이터가 어디에 어떻게 저장이 되어있는지, 테이블 사이의 관계는 어떻게 되어 있는지 쉽게 알 수 있습니다.<h1 id="2f1cef0b36b6443682183466c4886a31">ERD를 읽어봅시다</h1>ERD는 아래 이미지와 같이 여러 방식으로 표현할 수 있어요. 이 방식 중 Crow’s Foot 표기법이 가장 직관적으로 이해가 쉬운 방법이라, 이번 글에서는 이 Crow’s Foot 표기법을 소개할 예정이에요. 위에 예시로 보여드린 ERD도 이 표기법으로 그린 ERD입니다. Crow’s Foot 표기법은 <a href="http://geverest.umn.edu/" target="_blank">Gordon C. Everest</a> 교수가 발표한 1976년도 논문에서 시작되었어요. 엔티티를 박스로, 그 박스 사이의 선으로 관계를 표현하고, 그 선의 끝 모양으로 관계수와 선택성을 표현합니다.<figure data-type="image-block" data-src="https://attachments.datarian.io/production-17c6b26b-620b-4f58-a79c-1ead0b65f048-qKQBVSRianPAgxjJQ-RnSUrc-W_1ei_P8S2VHq3y8Eo.png" data-align="center" data-width="336" data-show-caption="true" style="width: 336px; max-width: 100%"><img src="https://attachments.datarian.io/production-17c6b26b-620b-4f58-a79c-1ead0b65f048-qKQBVSRianPAgxjJQ-RnSUrc-W_1ei_P8S2VHq3y8Eo.png" width="336" /><figcaption>여러 ERD 표기법 (이미지 출처: <a href="https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model" target="_blank">위키피디아</a>)</figcaption></figure><h2 id="ea59ef58cd704579ab41d27bc481c14e">1. 엔티티</h2>먼저 ‘엔티티’가 어떤 부분인지 살펴볼게요. Crow’s Foot 표기법에서는 박스로 엔티티를 나타낸다고 위에서 이야기 했는데요. 그 박스 최상단에는 엔티티의 이름을 적습니다. 여기에는 총 4개의 박스가 있네요. 즉 &lt;orders&gt;, &lt;customers&gt;, &lt;order_item&gt;, &lt;items&gt;가 바로 엔티티입니다.<figure data-type="image-block" data-src="https://attachments.datarian.io/production-2e8769ee-2df2-4d27-81b3-8575431bf780-X_glTXNfGoq_DbjBosUxXHAVcnMATLziJHWR-m9xPKg.png" data-align="center" data-width="100%" style="width: 100%; max-width: 100%"><img src="https://attachments.datarian.io/production-2e8769ee-2df2-4d27-81b3-8575431bf780-X_glTXNfGoq_DbjBosUxXHAVcnMATLziJHWR-m9xPKg.png" /></figure><h2 id="e0a33b2cfdef44379936671af9f99909">2. 속성</h2><a href="https://datarian.io/blog/what-are-the-components-of-er-diagrams-in-dbms" target="_blank">이전 글</a>에서 ‘속성’은 데이터의 특성을 서술하는 기준이라고 했어요. &lt;orders&gt; 엔티티에서는 order_id, order_date, customer_id가 속성이고, &lt;customers&gt; 엔티티에서는 customer_id와 country, &lt;order_items&gt; 엔티티에서는 item_id와 order_id, price, quantity, 마지막으로 &lt;items&gt; 엔티티에서는 item_id와 name이 바로 속성입니다.<figure data-type="image-block" data-src="https://attachments.datarian.io/production-d31416d3-270c-44b0-b386-3d26287b3fdf-UsrsHqfE9d9oR1SwRyPgbSfQ25c2g9K6xBMvTlk-FUc.png" data-align="center" data-width="100%" style="width: 100%; max-width: 100%"><img src="https://attachments.datarian.io/production-d31416d3-270c-44b0-b386-3d26287b3fdf-UsrsHqfE9d9oR1SwRyPgbSfQ25c2g9K6xBMvTlk-FUc.png" /></figure>이 속성 중에서도 엔티티에서 개별 데이터(인스턴스, Instance)를 식별할 수 있게 만드는 속성을 ‘식별자’ 혹은 ‘기본키(Primary Key, PK)’라고 부릅니다. &lt;orders&gt; 엔티티에서는 order_id, &lt;customers&gt; 엔티티에서는 customer_id, &lt;order_items&gt;엔티티에서는 order_item_id, 그리고 &lt;items&gt; 엔티티에서는 item_id가 PK로 사용되고 있는 걸 보실 수 있어요.다른 테이블에 있는 기본 키를 참조해서 사용할 때는, 그 식별자를 ‘외래키(Foreign Key, FK)’라고 부르는데요. &lt;orders&gt; 엔티티의 customer_id와 &lt;order_items&gt; 엔티티의 item_id와 order_id가 FK입니다. 이 FK는 어느 테이블의 기본 키를 참조한 것인지, 엔티티간의 관계를 한번 살펴볼게요.<h2 id="5b02501011b64462be4c14d3ad9c1412">3. 관계</h2><a href="https://datarian.io/blog/what-are-the-components-of-er-diagrams-in-dbms" target="_blank">이전 글</a>에서 관계는 ‘관계수’와 ‘선택성’으로 구성된다고 이야기한 것 기억나시나요? ‘관계수’는 어떤 엔티티의 인스턴스 하나가 다른 엔티티의 인스턴스 몇 개와 대응되는지를 표현하고, 1:1, 1:N, M:N 유형이 있습니다. 여기서 1은 세로바(|)로 표현하고, 2개 이상(N, M)은 Crow’s foot(&lt;)을 이용해 표시합니다. 그리고 ‘선택성’은 엔티티의 인스턴스에 대해 상대 엔티티에 정보가 존재하는지 여부를 나타내는데요. 양쪽 필수, 한쪽 필수, 양쪽 선택으로 나누어집니다. 필수(Mandatory), 즉 1개 이상 존재하는 경우에는 세로바(|)로 표기하고요. 선택(Optional), 즉 0개 이상이면 O로 표시합니다. <figure data-type="image-block" data-src="https://attachments.datarian.io/production-4bb15007-b880-494b-abfe-c9a2b8c43375-Co-G_BW1x5JuHrzxuadxovyTUB5gxPzc6mwVFMEcw5k.png" data-align="center" data-width="416" data-height="212" data-show-caption="true" style="width: 416px; max-width: 100%"><img src="https://attachments.datarian.io/production-4bb15007-b880-494b-abfe-c9a2b8c43375-Co-G_BW1x5JuHrzxuadxovyTUB5gxPzc6mwVFMEcw5k.png" width="416" height="212" /><figcaption>이미지 출처: <a href="https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning" target="_blank">https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning</a></figcaption></figure>이 내용을 생각하면서 ERD를 다시 한번 볼게요. &lt;orders&gt;와 &lt;order_items&gt;는 1:N이자 양쪽 필수 관계이고, &lt;order_items&gt;는 &lt;items&gt;와는 1:N이자 한쪽 필수 관계라는 것을 알 수 있습니다. 그리고 &lt;customers&gt;와 &lt;orders&gt;도 1:N, 그리고 한쪽 필수 관계입니다.<figure data-type="image-block" data-src="https://attachments.datarian.io/production-22c8231e-788c-443f-a5bd-297c1cd7c8be-dcZBDDQkjD9t3SxJAtz2YZj9Qdu-8cbIi4UtnkYlIj4.png" data-align="center" data-width="100%" style="width: 100%; max-width: 100%"><img src="https://attachments.datarian.io/production-22c8231e-788c-443f-a5bd-297c1cd7c8be-dcZBDDQkjD9t3SxJAtz2YZj9Qdu-8cbIi4UtnkYlIj4.png" /></figure>이렇게만 봐서는 조금 이해가 어려울 수도 있을 것 같아요. 이 데이터의 상세 특징과 함께 조금 풀어서 설명을 해볼게요. 우선 이 회사의 모든 주문 내역은 &lt;orders&gt;에, 그리고 회사가 판매하는 모든 물건의 정보는 &lt;items&gt;에 있습니다. 고객은 한 번 주문할 때 여러 종류의 물건을 주문할 수 있어요. 그래서 아래와 같이 &lt;order_items&gt; 엔티티에는 같은 order_id가 여러 번 저장될 수 있습니다.<table><tbody><tr><th>order_item_id</th><th>order_id</th><th>item_id</th><th>price</th><th>quantity</th></tr><tr><td>1</td><td>1</td><td>512</td><td>10,000</td><td>1</td></tr><tr><td>2</td><td>1</td><td>673</td><td>36,000</td><td>3</td></tr><tr><td>3</td><td>1</td><td>1,034</td><td>5,000</td><td>1</td></tr></tbody></table>&lt;order_items&gt; 예시 데이터그리고 같은 물건을 여러 고객이 주문할 수도 있고, 혹은 같은 고객이 여러 번 주문할 수도 있어요. 그래서 &lt;order_items&gt; 엔티티의 item_id도 여러 번 저장될 수 있습니다. 이와 반대로 한 번도 주문되지 않은 물건도 있습니다. 이런 물건의 정보는 &lt;items&gt;에만 저장되고 &lt;order_items&gt;에는 저장되지 않아요. 그래서 두 엔티티는 한쪽 필수 관계입니다.<table><tbody><tr><th>order_item_id</th><th>order_id</th><th>item_id</th><th>price</th><th>quantity</th></tr><tr><td>10</td><td>3</td><td>512</td><td>30,000</td><td>3</td></tr><tr><td>11</td><td>4</td><td>512</td><td>70,000</td><td>7</td></tr><tr><td>12</td><td>15</td><td>512</td><td>20,000</td><td>2</td></tr></tbody></table>&lt;order_items&gt; 예시 데이터이번에는 customer_id를 살펴볼게요. 모든 고객의 정보가 &lt;customers&gt; 엔티티에 저장되지만, 아직 주문을 한 번도 하지 않은 고객의 정보는 &lt;orders&gt; 엔티티에 저장되지 않아요. 반면에 여러 번 주문한 고객이라면 &lt;orders&gt;에 customer_id가 여러 번 저장됩니다. 그래서 &lt;customers&gt;와 &lt;orders&gt;는 1:N이면서 한쪽 필수인 관계입니다.<table><tbody><tr><th>order_id</th><th>order_date</th><th>customer_id</th></tr><tr><td>1</td><td>2024-04-01</td><td>5</td></tr><tr><td>4</td><td>2024-04-15</td><td>5</td></tr><tr><td>15</td><td>2024-05-01</td><td>5</td></tr></tbody></table>&lt;orders&gt; 예시 데이터<h1 id="6c3e6fb461924d0f982d25750b659178">마무리</h1>이렇게 ERD를 읽는 방법까지 배워봤습니다🎉 ER 모델의 구성 요소별로 하나씩 살펴보니, 이상한 그림 같았던 ERD가 이제는 이해되시나요? 데이터 분석가로 회사에 입사하면, 회사에 있는 데이터를 우선 파악해야 그 데이터를 이용해 분석을 할 수 있어요. 데이터를 이해하고 파악하기 위해 ERD를 읽을 줄 아는 것이 정말 중요합니다. 이번 글을 통해 남이 그린 ERD를 읽고 데이터를 이해할 수 있게 되었다면 충분합니다. 수많은 데이터를 구조화해서 이해하는 데에 큰 도움이 될 거예요. 다음 글에서는 직접 모델링을 할 수 있도록 엔티티, 속성, 관계에 대해 더 자세히 알아볼게요.

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

속성(Attribute) 톺아보기

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

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

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

ERD 어떻게 읽어야 하나요?

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

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

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

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

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

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

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

엔티티(Entity) 톺아보기

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

ERD 어떻게 읽어야 하나요?

Contents

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

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

함께 읽어보면 좋은 글

25년 12월 데이터 분석가 채용공고 모음

데이터로 말하면 사람들이 듣기 시작합니다

빅쿼리(Google BigQuery) 필수 문법, UNNEST 사용법

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

ERD 어떻게 읽어야 하나요?

Contents

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

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

함께 읽어보면 좋은 글

25년 12월 데이터 분석가 채용공고 모음

데이터로 말하면 사람들이 듣기 시작합니다

빅쿼리(Google BigQuery) 필수 문법, UNNEST 사용법

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

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

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