치수 모델링

Dimensional modeling

치수 모델링(DM)은 Ralph Kimball이 개발한 비즈니스 차원 라이프 사이클 방법론의 일부로서, 데이터 웨어하우스 [1]: 1258–1260 [2]설계에 사용하기 위한 방법, 기법 및 개념을 포함합니다.이 접근방식은 비즈니스 내에서 주요 비즈니스 프로세스를 식별하고 이를 모델링하여 상향식 [1]: 1258–1260 접근방식으로 구현하는데 중점을 두고 있습니다.Inmon의 대안적 접근법은 엔티티-관계 모델링([1]: 1258–1260 ER) 등의 도구를 사용하여 모든 기업 데이터의 모델을 하향식으로 설계하는 것을 지지합니다.

묘사

치수 모델링은 항상 사실(측도)과 차원(콘텍스트)의 개념을 사용합니다.팩트는 일반적으로 집계할 수 있는(항상 그렇지는 않지만) 숫자 값이며, 차원은 팩트를 정의하는 계층 및 설명자 그룹입니다.예를 들어 매출액은 팩트입니다.타임스탬프, 제품, 레지스터 번호, 스토어 번호 등은 치수의 요소입니다.치수 모델은 매장 판매, 재고, 청구 등 비즈니스 프로세스 영역별로 구축됩니다.서로 다른 비즈니스 프로세스 영역은 일부 차원을 공유하지만 모든 차원을 공유하지는 않기 때문에 설계, 운영 및 일관성의 효율은 일치된 치수, 즉 대상 영역 [citation needed]전체에서 공유 차원의 복사본을 사용하여 달성됩니다.

치수 모델링에 관계형 데이터베이스가 반드시 필요한 것은 아닙니다.다차원 데이터베이스나 플랫 파일 등 모든 물리적 형태에 대해 논리 수준에서 동일한 모델링 방식을 사용할 수 있습니다.이해성과 [citation needed]퍼포먼스에 중점을 두고 있습니다.

설계 방법

모델 설계

치수 모델은 별 모양 스키마 또는 눈송이 스키마 위에 구축되며, 차원은 팩트 [3][4]테이블을 둘러싸고 있습니다.스키마를 작성하려면 다음 설계 모델이 사용됩니다.

  1. 비즈니스 프로세스 선택
  2. 곡식을 신고하다
  3. 치수를 특정
  4. 사실을 특정하다
비즈니스 프로세스 선택

치수 모델링 프로세스는 치수 모델의 사용성과 데이터 웨어하우스의 사용을 보장하는 4단계 설계 방법을 기반으로 합니다.설계의 기본은 데이터 웨어하우스가 커버해야 하는 실제 비즈니스 프로세스를 기반으로 합니다.따라서 모델의 첫 번째 단계는 모델이 구축된 비즈니스 프로세스를 설명하는 것입니다.예를 들어 소매점의 판매 상황일 수 있습니다.비즈니스 프로세스를 설명하려면 이를 일반 텍스트로 수행하거나 BPMN(Business Process Modeling Numption) 또는 Unified Modeling Language(UML)와 같은 기타 설계 가이드를 사용할 수 있습니다.

곡식을 신고하다

비즈니스 프로세스를 설명한 후 설계의 다음 단계는 모델의 결점을 선언하는 것입니다.모델의 입자는 치수 모델이 무엇에 초점을 맞춰야 하는지에 대한 정확한 설명입니다.예를 들어, "소매점에서 고객 전표에 기재된 개별 품목"이 있을 수 있습니다.곡물의 의미를 명확히 하기 위해서는 중심 과정을 골라 한 문장으로 설명해야 합니다.게다가 그 곡식(문장)은 당신이 당신의 차원과 사실표를 만드는 것입니다.모델이 제공할 수 있는 정보에 대한 새로운 정보를 얻기 위해 이 단계로 돌아가서 곡선을 변경해야 할 수도 있습니다.

치수를 특정

설계 프로세스의 세 번째 단계는 모델의 치수를 정의하는 것입니다.치수는 4단계 프로세스의 두 번째 단계부터 그레인 내에서 정의해야 합니다.치수는 팩트 테이블의 기초이며 팩트 테이블의 데이터가 수집되는 곳입니다.일반적으로 치수는 날짜, 매장, 재고 등의 명사입니다.이러한 치수는 모든 데이터가 저장되는 곳입니다.예를 들어 날짜 차원에는 연도, 월 및 요일과 같은 데이터가 포함될 수 있습니다.

사실의 특정

치수를 정의한 후 프로세스의 다음 단계는 팩트 테이블의 키를 만드는 것입니다.이 단계에서는 각 팩트테이블 행을 채울 수치 팩트를 식별합니다.이 단계는 데이터 웨어하우스에 저장된 데이터에 액세스할 수 있는 시스템 비즈니스 사용자와 밀접한 관련이 있습니다.따라서 대부분의 팩트 테이블 행은 수치, 수량 또는 단위당 비용 등의 가산 수치입니다.

치수 정규화

치수 정규화 또는 눈송이에 의해 정규화된 평탄한 치수로 알려진 중복 속성이 제거됩니다.치수는 하위 치수로 엄격하게 결합됩니다.

눈꽃은 데이터 [4]웨어하우스의 많은 철학과는 다른 데이터 구조에 영향을 미칩니다.여러 개의 설명(차원) 표로 둘러싸인 단일 데이터(팩트) 표

개발자는 다음과 같은 몇 가지 [5]이유로 치수를 정규화하지 않는 경우가 많습니다.

  1. 정규화는 데이터 구조를 더욱 복잡하게 만듭니다.
  2. 테이블 간 조인 수가 많기 때문에 성능이 저하될 수 있습니다.
  3. 공간 절약은 최소
  4. 비트맵 인덱스를 사용할 수 없습니다.
  5. 성능을 쿼리합니다.3NF 데이터베이스는 분석이 필요할 수 있는 많은 차원 값을 집계하거나 검색할 때 성능 문제를 겪습니다.운용 보고서만 작성하는 경우 운용 사용자가 매우 세밀한 데이터를 요구하고 있기 때문에 3NF로 그럭저럭 대처할 수 있습니다.

정규화가 [4]유용한 이유에 대한 몇 가지 주장이 있습니다.계층 구조의 일부가 둘 이상의 차원에 공통인 경우 이점이 될 수 있습니다.예를 들어, 지리적 치수는 고객과 공급업체 치수가 모두 사용하기 때문에 재사용할 수 있습니다.

치수 모델링의 이점

치수 모델의 장점은 다음과 같습니다.[6]

  • 이해하기 쉬워요.정규화된 모델에 비해 치수 모델은 이해하기 쉽고 직관적입니다.차원 모델에서는 정보를 일관성 있는 비즈니스 범주 또는 차원으로 그룹화하여 읽고 해석하기 쉽게 합니다.또한 단순성으로 인해 소프트웨어는 데이터베이스를 효율적으로 탐색할 수 있습니다.정규화된 모델에서는 데이터가 여러 개의 개별 엔티티로 분할되며, 단순한 비즈니스 프로세스에서도 수십 개의 테이블이 복잡한 방식으로 결합될 수 있습니다.
  • 성능을 쿼리합니다.차원 모델은 데이터 쿼리에 대해 더 정규화되고 최적화되는 반면, 정규화된 모델은 데이터 중복을 제거하고 트랜잭션 로드 및 업데이트에 최적화됩니다.차원 모델의 예측 가능한 프레임워크를 통해 데이터베이스는 성능에 긍정적인 영향을 미칠 수 있는 데이터에 대해 강력한 가정을 할 수 있습니다.각 차원은 팩트테이블의 동등한 엔트리 포인트이며, 이 대칭 구조를 통해 복잡한 쿼리를 효과적으로 처리할 수 있습니다.스타 조인 데이터베이스에 대한 쿼리 최적화는 단순하고 예측 가능하며 제어할 수 있습니다.
  • 확장성치수 모델은 확장 가능하며 예상치 못한 새로운 데이터를 쉽게 수용할 수 있습니다.기존 테이블은 테이블에 새 데이터 행을 추가하거나 SQL alter table 명령을 실행하여 변경할 수 있습니다.데이터 웨어하우스 상부에 있는 쿼리나 애플리케이션은 변경에 대응하기 위해 재프로그래밍할 필요가 없습니다.이전 쿼리 및 응용 프로그램은 다른 결과를 생성하지 않고 계속 실행됩니다.그러나 정규화된 모델에서는 데이터베이스 테이블 간의 의존성이 복잡하기 때문에 각 수정에 대해 신중하게 검토해야 합니다.

차원 모델, 하둡 및 빅데이터

우리는 여전히 하둡 및 유사한 빅데이터 프레임워크에서 차원 모델의 이점을 누리고 있습니다.그러나 Hadoop의 일부 기능에서는 표준 접근 방식을 [citation needed]치수 모델링에 약간 수정해야 합니다.

  • Hadoop 파일 시스템은 불변합니다.데이터 추가만 가능하며 업데이트는 불가능합니다.그 결과 치수 테이블에만 레코드를 추가할 수 있습니다.Hadoop에서 차원을 느리게 변경하는 것이 기본 동작이 됩니다.치수 테이블에서 최신 레코드를 얻으려면 세 가지 옵션이 있습니다.먼저 윈도우 기능을 사용하여 최신 레코드를 검색하는 View를 만들 수 있습니다.둘째, 압축 서비스를 백그라운드에서 실행하여 최신 상태를 재현할 수 있습니다.셋째, 치수 테이블을 HBase와 같은 가변 스토리지에 저장하고 두 유형의 스토리지에 걸쳐 쿼리를 연합할 수 있습니다.
  • HDFS를 통해 데이터가 분산되는 방식 때문에 데이터 결합에 비용이 많이 듭니다.Distributed Relational Database(MPP; 분산 릴레이셔널 데이터베이스)에서는 클러스터 내의 동일한 노드 상에 동일한 프라이머리 키와 외부 키를 사용하여 레코드를 동시에 배치할 수 있습니다.따라서 매우 큰 테이블을 결합하는 것이 비교적 저렴합니다.결합을 수행하기 위해 네트워크를 통과할 필요가 없는 데이터입니다.이것은 Hadoop과 HDFS에서는 매우 다릅니다.HDFS 테이블은 큰 청크로 분할되어 클러스터의 노드에 분산됩니다.NAT은 개별 레코드와 레코드의 키가 클러스터 전체에 분산되는 방식을 제어할 수 없습니다.따라서 두 개의 매우 큰 테이블을 위해 Hadoop에 가입하는 것은 데이터를 네트워크를 통해 이동해야 하기 때문에 비용이 많이 듭니다.가능하면 가입은 피해야 합니다.큰 팩트 및 치수 테이블의 경우 치수 테이블을 팩트 테이블로 직접 정규화할 수 있습니다.매우 큰 트랜잭션 테이블 2개의 경우 상위 테이블 내에 하위 테이블의 레코드를 중첩하고 런타임에 데이터를 평탄하게 만들 수 있습니다.

문학.

  • Kimball, Ralph; Margy Ross (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). Wiley. ISBN 978-1-118-53080-1.
  • Ralph Kimball (1997). "A Dimensional Modeling Manifesto". DBMS and Internet Systems. 10 (9).
  • Margy Ross (Kimball Group) (2005). "Identifying Business Processes". Kimball Group, Design Tips (69). Archived from the original on 12 June 2013.

레퍼런스

  1. ^ a b c Connolly, Thomas; Begg, Carolyn (26 September 2014). Database Systems - A Practical Approach to Design, Implementation and Management (6th ed.). Pearson. Part 9 Business Intelligence. ISBN 978-1-292-06118-4.
  2. ^ Moody, Daniel L.; Kortink, Mark A.R. "From Enterprise Models to Dimensional Models: A Methodology for Data Warehouse and Data Mart Design" (PDF). Dimensional Modelling. Archived (PDF) from the original on 17 May 2017. Retrieved 3 July 2018.
  3. ^ Ralph Kimball; Margy Ross; Warren Thornthwaite; Joy Mundy (10 January 2008). The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses (Second ed.). Wiley. ISBN 978-0-470-14977-5.
  4. ^ a b c Matteo Golfarelli; Stefano Rizzi (26 May 2009). Data Warehouse Design: Modern Principles and Methodologies. McGraw-Hill Osborne Media. ISBN 978-0-07-161039-1.
  5. ^ Ralph Kimball; Margy Ross (26 April 2002). The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second ed.). Wiley. ISBN 0-471-20024-7.
  6. ^ Ralph Kimball; Margy Ross; Warren Thornthwaite; Joy Mundy; Bob Becker (January 2008). The Data Warehouse Lifecycle Toolkit (Second ed.). Wiley. ISBN 978-0-470-14977-5.