소개
훌륭한 의미 체계 모델을 만드는 일은 데이터 분석가가 Microsoft Power BI에서 수행할 수 있는 가장 중요한 작업 중 하나입니다. 이 작업을 잘 수행하면 데이터를 더 이해하기 쉽게 만들 수 있으며, 이에 따라 사용자와 개발자는 귀중한 Power BI 보고서를 더 쉽게 작성할 수 있습니다.
이 모듈의 페이지는 정보 제공 목적으로만 제공됩니다. 데이터 파일은 제공되지 않습니다. 랩을 통해 실제 데이터로 작업해 볼 수 있습니다.
좋은 의미 체계 모델은 다음과 같은 이점을 제공합니다.
데이터 탐색 속도가 더 빠릅니다.
집계를 더 간단히 작성합니다.
보고서가 더 정확합니다.
보고서를 작성하는 데 걸리는 시간이 더 짧습니다.
나중에 보고서를 더 쉽게 관리합니다.
모든 데이터가 다르고 이러한 데이터의 사용에 차이가 있기 때문에 좋은 의미 체계 모델을 만드는 요소에 대한 집합 규칙을 제공하기는 어렵습니다. 일반적으로 의미 체계 모델이 작을수록 더 빠르게 수행되고 사용하기가 더 간단하므로 더 좋습니다. 그러나 경험적이고 주관적인 개념이기 때문에 더 작은 의미 체계 모델의 의미를 정의하는 것은 동일하게 문제가 됩니다.
일반적으로 더 작은 의미 체계 모델은 사용자가 볼 수 있는 테이블 수가 더 적고 각 테이블의 열의 수도 더 적습니다. 판매 데이터베이스에서 필요한 테이블을 모두 가져오는 경우 총 테이블 수가 30개라면, 사용자에게 이 데이터 모델은 직관적이지 않습니다. 이러한 테이블을 5개의 테이블로 축소하면 사용자 관점에서 보다 직관적인 의미 체계 모델이 됩니다. 반면, 사용자가 한 테이블을 열었을 때 열이 100개가 있다면 과도하다고 느낄 수도 있습니다. 불필요한 열을 제거하여 더 관리하기 쉬운 수의 열을 제공하면 사용자가 모든 열 이름을 읽을 가능성이 커집니다. 요약하자면, 의미 체계 모델을 디자인할 때 단순성을 목표로 해야 합니다.
다음 이미지는 의미 체계 모델의 예입니다. 상자에는 데이터 테이블이 포함되어 있고 상자 안에 있는 각 항목은 열입니다. 상자를 연결하는 선은 테이블 간의 관계를 나타냅니다. 테이블 간 관계는 이런 간단한 모델에서도 복잡할 수 있습니다. 의미 체계 모델은 쉽게 체계가 무너질 수 있고, 모델 내의 총 테이블 수는 점진적으로 증가할 수 있습니다. 의미 체계 모델을 간단하고 포괄적이며 정확하게 유지하려면 일관된 노력이 필요합니다.
관계는 기본 키와 외래 키를 통해 테이블 간에 정의됩니다. 기본 키는 null이 아닌 고유 데이터 행을 각각을 식별하는 열입니다. 예를 들어 Customers 테이블이 있는 경우 고유한 각 고객을 식별하는 인덱스가 있을 수 있습니다. 첫 번째 행의 ID는 1, 두 번째 행의 ID는 2 순으로 증가합니다. 각 행에는 고유한 값이 할당되며, 이 값은 기본 키와 같은 단순 값에서 참조할 수 있습니다. 이 프로세스는 다른 테이블의 행을 참조(외래 키의 역할)할 때 중요해집니다. 테이블 간의 관계는 서로 다른 테이블 간에 공통된 기본 키와 외래 키가 있는 경우에 형성됩니다.
Power BI를 사용하면 서로 다른 데이터 원본이 사용된 테이블에서 관계를 만들 수 있습니다. 이러한 강력한 기능을 통해 예를 들어 Microsoft Excel에서 하나의 테이블을, 관계형 데이터베이스에서 다른 테이블을 끌어올 수 있습니다. 그런 다음, 이 두 테이블 간의 관계를 만들어 통합된 의미 체계 모델로 처리합니다.
데이터 스키마를 구성하는 관계에 대해 알아봤으므로 고성능과 유용성을 위해 최적화된 특정 유형의 스키마 디자인인 별모양 스키마를 탐색할 수 있습니다.
별모양 스키마
데이터를 단순화하기 위해 별모양 스키마를 디자인할 수 있습니다. 이 스키마는 데이터를 단순화하는 유일한 방법은 아니지만 널리 사용되는 방법입니다. 그러므로 모든 Power BI 데이터 분석가는 이 스키마를 이해해야 합니다. 별모양 스키마에서 의미 체계 모델 내의 각 테이블은 다음 그림에서처럼 차원 테이블이나 팩트 테이블로 정의됩니다.
팩트 테이블은 판매 주문, 제품 수, 가격, 거래 날짜 및 시간, 수량 등의 관찰 데이터 또는 이벤트 데이터 값을 포함합니다. 팩트 테이블은 여러 개의 반복된 값을 포함할 수 있습니다. 예를 들어 하나의 제품이 서로 다른 고객에 대해 여러 날짜에 여러 행에서 여러 번 나타날 수 있습니다. 이 값을 집계하여 시각적 개체를 만들 수 있습니다. 예를 들어 총 판매 주문에 대한 시각적 개체는 팩트 테이블의 모든 판매 주문의 집계입니다. 팩트 테이블에서는 열이 숫자와 날짜로 채워지는 것이 일반적입니다. 숫자는 판매 금액과 같은 측정 단위이거나 고객 ID와 같은 키일 수 있습니다. 날짜는 주문 날짜 또는 배송 날짜와 같이 기록되는 시간을 나타냅니다.
차원 테이블은 제품, 위치, 직원, 주문 유형과 같이 팩트 테이블의 데이터에 대한 세부 정보를 포함합니다. 이 테이블은 키 열을 통해 팩트 테이블에 연결됩니다. 차원 테이블은 팩트 테이블의 데이터를 필터링하고 그룹화하는 데 사용됩니다. 반면 팩트 테이블에는 판매 및 수익과 같은 측정 가능한 데이터가 포함되며, 각 행은 차원 테이블의 고유한 값 조합을 나타냅니다. 총 판매 주문에 대한 시각적 개체의 경우 제품별 총 판매 주문을 표시하도록 데이터를 그룹화할 수 있습니다. 여기서 제품은 차원 테이블의 데이터입니다.
개인 판매량과 같은 다수의 이벤트가 팩트 테이블에서 발생하기 때문에 팩트 테이블은 차원 테이블보다 훨씬 큽니다. 차원 테이블은 필터링하고 그룹화할 수 있는 항목의 수로 제한되기 때문에 일반적으로 더 작습니다. 예를 들어 1년에는 해당하는 개월 수만 포함되고 미국은 특정 수의 주로만 구성됩니다.
팩트 테이블과 차원 테이블에 대한 이 정보를 고려할 때, Power BI에서 이 시각적 개체를 작성할 수 있는 방법이 궁금할 수도 있습니다.
관련 데이터는 다음 의미 체계 모델에 나온 것처럼 Employee 및 Sales라는 두 테이블에 있습니다. Sales 테이블은 집계할 수 있는 판매 주문 값을 포함하므로 팩트 테이블로 간주됩니다. Employee 테이블은 판매 주문을 필터링하는 특정 직원 이름을 포함하므로 차원 테이블이 됩니다. 두 테이블 사이에서 공통된 열은 Employee 테이블의 기본 키로, EmployeeID입니다. 따라서 이 열을 기반으로 하여 두 테이블 간의 관계를 설정할 수 있습니다.
이 관계를 만들 때는 다음 그림과 같이 요구 사항에 따라 시각적 개체를 작성할 수 있습니다. 두 테이블 간의 공통점을 염두에 두고 이 관계를 설정하지 않은 경우에는 시각적 개체를 작성하기가 더 어려웠을 수 있습니다.
별모양 스키마와 기본 의미 체계 모델은 올바르게 구성된 보고서의 기반입니다. 이러한 연결과 디자인을 만드는 데 더 많은 시간을 들일수록 보고서를 만들고 유지 관리하기가 더 쉽습니다.