Power BI 데이터 모델링: 관계 설정, 카디널리티 4종, 스타 스키마까지

핵심 메시지

• 데이터를 하나의 큰 테이블에 몰아넣으면 중복(redundancy)이 생기고 조회 속도가 느려지므로, 여러 테이블로 나눠 저장한다.
• 테이블을 나눌 때는 공통 필드로 서로 참조할 수 있어야 한다. 관계가 없으면 “관리자가 누구냐” 같은 질문에 답할 수 없다.
• 두 테이블의 관계는 일대일·일대다·다대일·다대다 네 가지뿐이며, 이를 결정하는 개념이 카디널리티다.
• Power BI는 데이터를 불러오면 관계를 자동으로 감지하지만, 사용자가 카디널리티가 맞는지 검증할 책임이 있다.
• 거래 데이터가 담긴 팩트 테이블과 보조 정보가 담긴 차원 테이블로 구성된 모델을 팩트-차원 모델, 즉 스타 스키마라고 부른다.

쉽게 이해하기

Edureka 세션 강사는 데이터 모델링을 설명하기 위해 먼저 정규화 개념을 든다. 직원 정보, 부서, 관리자, 이메일, 전화번호를 하나의 큰 테이블에 모두 넣으면 같은 부서 정보가 직원마다 반복 저장돼 중복이 발생한다. 데이터베이스는 비싸고, 테이블이 커질수록 조회 시간도 늘어난다. 그래서 실제 기업은 데이터를 여러 테이블로 논리적으로 나눈다.

다만 단순히 쪼개기만 하면 “직원 B의 관리자는 누구인가” 같은 질문에 답할 수 없다. 강사는 테이블을 나눌 때 반드시 공통 필드(예: 부서)를 통해 한 테이블에서 다른 테이블을 참조할 수 있어야 한다고 강조한다. 이렇게 참조가 가능해야 “Ravi 밑에서 일하는 직원은 누구인가”도 답할 수 있다.

관계를 만들려면 카디널리티를 이해해야 한다. 강사는 한 사람과 하나의 고유 식별번호(인도의 Aadhaar, 미국의 사회보장번호 등)처럼 양방향 모두 결과가 하나뿐이면 일대일, 부서로 직원을 조회하면 여러 명이 나오는 경우처럼 방향에 따라 일대다·다대일, 의사-환자처럼 양쪽 모두 여러 결과가 나오면 다대다라고 설명한다. 관계는 이 네 가지뿐이다.

Power BI는 데이터를 불러오면 모델 뷰에서 테이블 간 관계를 자동으로 감지한다. 특히 RDBMS에서는 관계가 데이터베이스 수준에서 이미 정의돼 있어 그대로 가져오고, 없으면 새로 감지해 만든다. 강사는 그래도 사용자가 개념을 알아야 자동 생성된 관계와 카디널리티가 올바른지 검증할 수 있다고 말한다.

마지막으로 강사는 커피 체인 데이터를 예로 팩트 테이블(매일 갱신되는 거래·이익·판매가 등)과 차원 테이블(지역, 제품 등 거의 변하지 않는 보조 정보)을 구분한다. 팩트 테이블을 가운데 두고 차원 테이블이 둘러싼 모델이 별 모양을 닮았다 하여 스타 스키마(팩트-차원 모델)라고 부른다.

주요 인사이트

• 관계가 정의되지 않은 두 테이블의 데이터는 하나의 시각화에 함께 넣을 수 없다. Power BI는 “서로 관련 없는 두 테이블의 데이터를 한 비주얼에 쓸 수 없다”는 오류를 낸다. 관계를 만들어야 비로소 여러 테이블의 데이터를 한 차트에 담을 수 있다.
• 교차 필터 방향(cross filter direction)은 기본이 단방향이며, 보통 차원 테이블에서 팩트 테이블로 필터가 흐른다. 양방향으로 바꾸면 양쪽에서 필터가 작동하지만 성능이 저하되므로 실무에서는 대개 단방향을 유지한다.
• 강사는 기본키·외래키 같은 데이터베이스 전문 개념까지는 필요 없다고 본다. 공통 필드가 무엇이고 각 필드에 어떤 데이터가 들어 있는지만 알아도 관계를 만드는 데 충분하다는 것이다.
• 관계가 자동 감지되지 않았다면, 모델 뷰에서 한 테이블의 공통 필드를 다른 테이블의 같은 필드로 끌어다 놓기만 하면 관계와 카디널리티가 자동으로 정의된다.

자주 묻는 질문

관련 AI 소식