데이터 엔티티 관계(ERD) 기초: 비전공자 셰프가 깨달은 데이터 설계의 중요성
뉴질랜드 퀸스타운 QRC 데이터 분석 과정이 막바지 들고 있습니다. 비전공자 셰프인 저가 학교에서 배운 데이터 엔티티 관계 설정법을 공유합니다. 데이터 분석의 설계도인 ERD 기초 개념을 통해 복잡한 데이터를 구조화하는 방법을 쉽게 확인하세요. 잘못 이해한 것도 같이 풀겠습니다.
데이터 엔티티 관계(ERD) 이해의 중요성

복잡해 보이시죠? 위의 데이터 엔티티(entity) 관계(ERD)는 뉴질랜드 퀸스타운 QRC 과제입니다. 제가 해 놓고도 잘 못 알아 보겠네요.
즉, 설계가 잘못됐는데, 결과가 나온다 한들 그것이 맞는 결과가 아니란 얘기입니다. 집 지을 때도 설계 도면이 똑바로 되어 있어야 튼튼한 건물을 짓듯이, 데이터 분석도 마찬가지입니다.
엔티티(Entity), 데이터 세상의 주인공들
위에서 설명하면서도 계속 엔티티라는 말이 나옵니다.
저도 말로 백 번 들어도 잘 몰랐는데, Tutor가 엑셀 압축 파일을 하나 던져 주시면서 풀어보라고 하시더라고요. 파일을 풀고서야 엔티티(Entity) 개념을 이해할 수 있었습니다.

자전거 가게의 데이터 분석 과제였습니다. 파일이 9개입니다. 예리하신 분들은 위의 ERD 사진에서 몇 개의 Entity(네모 모양)이 있는 지 기억하실 겁니다. 바로 9개입니다.
바로 Brands가 바로 Entity 중 하나입니다. categories도 Entity입니다. 이런 식으로 데이터를 가지고 있는 그릇이 무엇에 대한 것인지를 뜻합니다. Brands 파일을 열어보도록 하겠습니다.
Entity & Artribute

Brands 파일을 열었더니, 2개의 컬럼 Brand_id와 Brand_name이 보입니다. 이것들을 Artribute라고 합니다. Brand Entity에 들어있는 세부적인 데이터 자료를 의미합니다.

오우 감이 오시죠? 어떻게 그려야 할지? 위의 ERD 사진은 그렇게 9개의 파일을 하나씩 열어서 일일이 그렸습니다. 아니 AI가 있는데, 이것을 일일이 그려야 해? 라고 생각하시고 계시죠. 저도 처음에 그렇게 생각했습니다.
하지만, 데이터 엔티티 관계를 이해하는 데에는 AI가 뚝딱 만들어 주는 것 보다 이렇게 하나씩 직접 그려보는 것이 훨씬 이해도를 높이는 데 좋은 것 같습니다. 처음에
그런데 위의 Brands 사진을 보시면 Brand_id 옆에 PK(Primary Key)라고 적어 놓은 것이 보이실 겁니다. 이는 Brand 데이터 자료 하나 하나에 넘버를 매겨 놓은 것으로 그 데이터를 유일한 값으로 만드는 키라고 보시면 됩니다.
우리나라 사람들이 다 다른 주민등록번호를 가지고 있는 것과 같다고 보시면 됩니다. 그 번호는 다 달라서 유일한 값이라고 할 수 있죠.
PK, FK And Bridge

이번에는 Products 엔티티 사진 속에 Product_id(PK)와 Brand_id(FK), Category(FK)이 보이시나요? PK는 알겠는데, FK(foreign key)라고 또 보입니다. 이것은 쉽게 얘기해서 다른 엔티티의 PK를 가지고 있는 것으로 보시면 됩니다.
Brand_ID가 Brand entity에서는 PK이지만, 이것을 Products entity로 가져오면 FK라고 나타냅니다.
만약 2개의 데이터 엔티티의 관계를 알고 싶은데, 그 둘 사이의 공통되는 데이터가 하나도 없다면, 그런데 진짜 이 둘 사이의 관계를 알아야 한다면 그 때는 브릿지(Bridge) 엔티티를 생성하면 됩니다.

위의 사진은 또 다른 데이터 분석에서 가져왔습니다. 예를 들어, Transaction과 Product의 관계를 알고 싶은데, 둘 사이의 공통 데이터가 없습니다.
이럴 때 Transaction Details 이라는 새로운 브릿지 엔티티를 하나 만듭니다. 만드는 방법은 2개의 데이터 엔티티의 각각의 PK를 가져오시면 됩니다.
| 구분 | 의미 |
| PK(Primary Key) | 그 엔티티를 유일하게 만드는 키 |
| FK(Foreign key) | 다른 엔티티와 연결이 되도록 하는 키 |
| 브릿지 테이블 | 2개의 엔티티를 연결해 주는 엔티티 |
데이터 엔티티 관계(Relationship)의 종류
데이터 엔티티는 이제 이해하셨으니, 다음은 이 데이터 엔티티 간의 관계에 대해서 이야기 하겠습니다. 위 사진은 내가 받았던 9개의 파일을 Power BI에 올려서 그 관계를 EDR로 보시고 있는 것입니다.
엔티티 간의 선으로 막 연결되어 있는 것이 보이시죠? 자세히 보시면 1, * 그리고 화살표가 보이실 겁니다.
| 구분 | 1 | * | 화살표 |
| 의미 | 하나(one) | 다수(many) | 방향 |
예를 들어서 Brands와 Product 간의 관계에 대해서 보겠습니다. Brands에는 1이 적혀 있고, Products에는 * 라고 쓰여져 있고 방향은 Brands -> Product 입니다. 제가 이것을 문장으로 만들어 보겠습니다.
– 하나의 브랜드는 여러 개의 상품 모델을 가질 수 있다.
애플 브랜드는 아이패드, 아이폰, 맥북 등 여러 개의 상품 모델을 가질 수 있지 않습니까? 그래서 1 : 다수(many) 라는 관계가 성립하는 것입니다.
데이터 엔티티 관계를 말로 표현해 보기
저는 이렇게 종이에 데이터 엔티티 관계를 그리고 이렇게 문장으로 표현해 봤습니다. 그리고 이것을 Power BI의 엔티티 관계와 비교해 보았습니다.
뉴질랜드 퀸스타운 QRC 데이터 분석 강의가 궁금하신 분들은 아래 순서대로 포스팅을 읽어 보시기를 추천 드립니다. 데이터 분석에 관심 있으시거나, 분석가가 되고 싶으신 분들에게 도움이 될 것 같습니다.
비전공자 셰프의 ERD 실습 기록
제가 ERD 과제를 하면서 가장 크게 느꼈던 것은 바로 데이터의 속성을 이해하는 것이었습니다. Order items와 Orders 데이터를 볼 때 그 점을 느꼈습니다. 이름도 비슷한데 도대체 무엇이 다른 것이지 라는 생각이 들었습니다.
이 2개의 데이터가 무엇을 말하는 지, 어떤 데이터인지 모르면 관계를 파악할 수 없다는 생각이 들었습니다. Order Items는 수 많은 상품 모델 중에 고객이 주문을 한 상품을 의미합니다. 반면에 Orders는 어떤 고객이 상품 주문을 한 그 건에 대한 것입니다.
예를 들어 A라는 고객의 주문이 order id 1번이라고 치면, 그 안에는 여러 가지 order items가 들어가는 거죠. 자전거 A모델, B모델, C모델 등등 이렇게 생각해 보면, Orders 와 Order items의 관계는 1:다가 되는 것입니다.
그런데 제가 이 둘의 의미를 모르면, 관계 설정하는 것도 도저히 엄두가 나지 않겠죠?
마무리
오늘은 데이터 엔티티 관계, 즉 ERD 기초에 대해서 알아보는 시간을 가져 보았습니다. 위의 경우는 우리가 데이터 소스를 파일로만 가졌을 경우 얘기한 것입니다.
하지만 언젠가 우리가 필요한 데이터가 언제나 항상 우리 앞에 있지는 않습니다. 여러 기업들로 부터 하나씩 데이터가 필요할 경우도 발생할 수 있습니다.
그럴 때 Tutor는 API를 활용할 수 있다고 합니다. 다음 포스팅에서는 API에 대해서 이야기 하도록 하겠습니다.






