데이터 웨어하우스

Data warehouse
데이터 웨어하우스 개요
데이터 웨어하우스의 기본 아키텍처

컴퓨팅에서 데이터 웨어하우스(DW 또는 DWH)는 엔터프라이즈 데이터 웨어하우스(EDW)라고도 하며 보고 및 데이터 분석에 사용되는 시스템으로 비즈니스 [1]인텔리전스의 핵심 컴포넌트로 간주됩니다.DW는 하나 이상의 서로 다른 소스에서 가져온 통합 데이터의 중앙 저장소입니다.현재 데이터와 이력 데이터를 한 곳에[2] 저장하여 [3]전사적으로 작업자의 분석 보고서를 작성하는 데 사용됩니다.

웨어하우스에 저장된 데이터는 운영 시스템(마케팅 또는 영업 등)에서 업로드됩니다.데이터는 운용 데이터 스토어를 통과할 수 있으며, DW에서 보고서 작성에 사용하기 전에 데이터 품질을 확보하기 위해 추가 작업을 위해 데이터[2] 정리가 필요할 수 있습니다.

추출, 변환, 로드(ETL)와 추출, 로드, 변환(ELT)은 데이터 웨어하우스 시스템을 구축하는 데 사용되는 두 가지 주요 방법입니다.

ETL 기반 데이터 웨어하우스

일반적인 ETL(Extract, Transform, Load) 기반 데이터[4] 웨어하우스에서는 스테이징, 데이터 통합 및 액세스 계층을 사용하여 주요 기능을 수용합니다.스테이징 계층 또는 스테이징 데이터베이스는 서로 다른 소스 데이터 시스템 각각에서 추출된 원시 데이터를 저장합니다.통합 계층은 스테이징 계층의 데이터를 변환하여 서로 다른 데이터 세트를 통합합니다. 변환된 데이터는 종종 운영 데이터 저장소(ODS) 데이터베이스에 저장됩니다.그런 다음 통합 데이터는 데이터 웨어하우스 데이터베이스라고 불리는 또 다른 데이터베이스로 이동됩니다.여기서 데이터는 계층적 그룹, 종종 차원, 사실과 집계된 사실로 배열됩니다.사실과 차원의 조합을 스타 스키마라고 부르기도 한다.액세스 레이어는 사용자가 데이터를 [5]취득하는 데 도움이 됩니다.

데이터의 주요 소스는 관리자와 기타 비즈니스 전문가가 데이터 마이닝, 온라인 분석 처리, 시장 조사 및 의사결정 [6]지원에 사용할 수 있도록 정리, 변환, 카탈로그화 및 제공됩니다.그러나 데이터 검색 및 분석, 데이터 추출, 변환 및 로드, 데이터 사전 관리 등도 데이터 웨어하우징 시스템의 필수 구성요소로 간주됩니다.데이터 웨어하우징에 대한 많은 참조가 이 광범위한 컨텍스트를 사용합니다.따라서 데이터 웨어하우징에 대한 확장된 정의에는 비즈니스 인텔리전스 도구, 데이터를 추출, 변환 및 저장소로 로드하는 도구, 메타데이터를 관리하고 검색하는 도구가 포함됩니다.

ELT 기반 데이터 웨어하우스

ELT 기반 데이터 웨어하우스 아키텍처

ELT 기반 데이터 웨어하우징에서는 데이터 변환을 위한 별도의 ETL 도구가 필요하지 않습니다.대신 데이터 웨어하우스 내부에 스테이징 영역을 유지합니다.이 접근방식에서는 변환이 발생하기 전에 이종 소스 시스템에서 데이터를 추출하여 데이터 웨어하우스로 직접 로드합니다.그런 다음 필요한 모든 변환은 데이터 웨어하우스 자체에서 처리됩니다.마지막으로, 조작된 데이터는 동일한 데이터 웨어하우스의 대상 테이블에 로드됩니다.

혜택들

데이터 웨어하우스는 소스 트랜잭션 시스템의 정보 복사본을 유지합니다.이러한 아키텍처의 복잡성으로 인해 다음과 같은 이점을 얻을 수 있습니다.

  • 여러 소스의 데이터를 단일 데이터베이스 및 데이터 모델로 통합합니다.단일 쿼리 엔진을 사용하여 ODS에 데이터를 표시할 수 있도록 데이터를 단일 데이터베이스로 더 많이 모을 수 있습니다.
  • 트랜잭션 처리 데이터베이스에서 대규모 장기 실행 분석 쿼리를 실행하려고 할 때 발생하는 트랜잭션 처리 시스템의 데이터베이스 격리 수준 잠금 경합 문제를 완화합니다.
  • 원본 트랜잭션 시스템이 그렇지 않은 경우에도 데이터 이력을 유지합니다.
  • 여러 소스 시스템의 데이터를 통합하여 기업 전체의 중앙 뷰를 지원합니다.이러한 이점은 항상 가치가 있지만, 특히 합병으로 조직이 성장한 경우에는 더욱 그렇습니다.
  • 일관된 코드와 설명을 제공하거나 불량 데이터를 플래깅하거나 수정하여 데이터 품질을 향상시킵니다.
  • 조직의 정보를 일관되게 제시합니다.
  • 데이터 소스에 관계없이 관심 있는 모든 데이터에 대해 단일 공통 데이터 모델을 제공합니다.
  • 비즈니스 사용자가 이해할 수 있도록 데이터를 재구성합니다.
  • 복잡한 분석 쿼리에서도 운영 체제에 영향을 주지 않고 뛰어난 쿼리 성능을 제공할 수 있도록 데이터를 재구성합니다.
  • 운영 비즈니스 애플리케이션, 특히 고객 관계 관리(CRM) 시스템에 가치를 더합니다.
  • 의사 결정 – 지원 쿼리를 보다 쉽게 작성할 수 있습니다.
  • 반복적인 데이터를 정리하고 명확하게 합니다.

포괄적인

데이터 웨어하우스 및 마트의 환경에는 다음이 포함됩니다.

  • 창고 또는 마트에 데이터를 제공하는 소스 시스템
  • 데이터 사용 준비에 필요한 데이터 통합 기술 및 프로세스
  • 조직의 데이터 웨어하우스 또는 데이터 마트에 데이터를 저장하기 위한 다양한 아키텍처
  • 다양한 사용자를 위한 다양한 도구 및 애플리케이션
  • 창고 또는 마트가 목적에 부합하도록 메타데이터, 데이터 품질 및 거버넌스 프로세스가 마련되어 있어야 합니다.

위의 소스 시스템에 대해 R. Kelly Rainer는 "데이터 웨어하우스에 있는 데이터의 공통 소스는 관계형 데이터베이스일 수 있는 회사의 운영 데이터베이스입니다."[7]라고 말합니다.

데이터 통합에 대해 Rainer는 "소스 시스템에서 데이터를 추출하여 변환한 후 데이터 마트나 [7]창고에 로드하는 것이 필요하다"고 말합니다.

Rainer는 조직의 데이터 웨어하우스 또는 데이터 [7]마트에 데이터를 저장하는 것에 대해 설명합니다.

메타데이터는 데이터에 대한 데이터입니다."IT 담당자는 데이터 소스, 데이터베이스, 테이블 및 열 이름, 갱신 일정 및 데이터 사용률 측정에 대한 정보가 필요합니다."[7]

오늘날 가장 성공적인 기업은 시장의 변화와 기회에 신속하고 유연하게 대응할 수 있는 기업입니다.이 응답의 열쇠는 분석가와 관리자가 [7]데이터와 정보를 효과적이고 효율적으로 사용하는 것입니다."데이터 웨어하우스"는 조직 [7]내 의사결정자를 지원하기 위해 대상별로 구성된 이력 데이터의 저장소입니다.데이터 마트나 웨어하우스에 데이터를 저장하면 데이터에 액세스할 수 있습니다.

관련 시스템(데이터마트, OLAP, OLTP, 예측 분석)

데이터 마트는 단일 주제(또는 기능 영역)에 초점을 맞춘 데이터 웨어하우스의 단순한 형태이기 때문에 영업, 재무 또는 마케팅 등 제한된 수의 소스로부터 데이터를 가져옵니다.데이터 마트는 대부분의 경우 조직 내의 단일 부서가 구축 및 관리합니다.소스는 내부 운영 시스템, 중앙 데이터 웨어하우스 또는 외부 [8]데이터일 수 있습니다.디노멀라이제이션은 이 시스템에서 데이터 모델링 기술의 표준입니다.데이터 마트는 일반적으로 데이터 웨어하우스에 포함된 데이터의 하위 집합만 대상으로 하기 때문에 구현이 더 쉽고 더 빠른 경우가 많습니다.

데이터 웨어하우스와 데이터 마트의 차이
기여하다 데이터 웨어하우스 데이터마트
데이터의 범위 전사적 부서 전체의
대상 영역 수 복수 싱글
구축의 어려움 어렵다 만만하다
구축에 걸리는 시간 더 적은
메모리 용량 더 큰 한정된

데이터 마트의 유형에는 종속, 독립 및 하이브리드 데이터 마트가 포함됩니다.[clarification needed]

온라인 분석 처리(OLAP)는 트랜잭션 양이 상대적으로 적은 것이 특징입니다.쿼리는 매우 복잡하고 집약이 수반되는 경우가 많습니다.OLAP 시스템의 경우 응답 시간이 효과적인 척도다.OLAP 애플리케이션은 데이터 마이닝 기술에 널리 사용됩니다.OLAP 데이터베이스는 집계된 이력 데이터를 다차원 스키마(일반적으로 스타 스키마)로 저장합니다.OLAP 시스템은 일반적으로 데이터 마트가 하루 가까이 지연될 것으로 예상되는 것과 달리 몇 시간의 데이터 지연 시간을 가집니다.OLAP 접근법은 여러 소스 및 관점에서 다차원 데이터를 분석하기 위해 사용됩니다.OLAP의 3가지 기본 조작은 롤업(통합), 드릴다운, 슬라이싱&다이싱입니다.

온라인 트랜잭션 처리(OLTP)는 다수의 짧은 온라인 트랜잭션(INSERT, UPDATE, DELETE)을 특징으로 합니다.OLTP 시스템은 다중 액세스 환경에서 매우 빠른 쿼리 처리 및 데이터 무결성 유지를 강조합니다.OLTP 시스템의 경우 효율성은 초당 트랜잭션 수로 측정됩니다.OLTP 데이터베이스에는 상세하고 최신 데이터가 포함되어 있습니다.트랜잭션 데이터베이스를 저장하는 데 사용되는 스키마는 엔티티 모델(일반적으로 3NF)[9]입니다.정규화는 이 시스템에서 데이터 모델링 기술의 표준입니다.

예측 분석은 미래 결과를 예측하는 데 사용할 수 있는 복잡한 수학적 모델을 사용하여 데이터의 숨겨진 패턴을 찾아 수량화하는 입니다.예측 분석은 OLAP와 달리 이력 데이터 분석에 중점을 두고 반응성이 뛰어나며 예측 분석은 미래에 초점을 맞춘다는 점에서 OLAP와 다릅니다.이러한 시스템은 고객 관계 관리(CRM)에도 사용됩니다.

역사

데이터 웨어하우징의 개념은 IBM 연구원 Barry Devlin과 Paul Murphy가 "비즈니스 데이터 웨어하우스"를 개발한 1980년대[10] 후반으로 거슬러 올라갑니다.본질적으로 데이터 웨어하우징 개념은 운영 체제에서 의사결정 지원 환경으로 데이터 흐름을 위한 아키텍처 모델을 제공하기 위한 것이었습니다.이 개념은 이 흐름과 관련된 다양한 문제(주로 이 흐름과 관련된 높은 비용)에 대처하려고 했습니다.데이터 웨어하우징 아키텍처가 없는 경우, 여러 의사 결정 지원 환경을 지원하기 위해 엄청난 양의 이중화가 필요했습니다.대기업에서는, 복수의 의사결정 서포트 환경이 개별적으로 운용되는 것이 일반적이었습니다.각 환경에서는 서로 다른 사용자에게 서비스를 제공했지만, 대부분의 경우 동일한 저장된 데이터가 필요했습니다.일반적으로 기존의 장기 운영 체제(일반적으로 레거시 시스템이라고 함)에서 다양한 소스에서 데이터를 수집, 정리 및 통합하는 프로세스는 일반적으로 각 환경에 대해 부분적으로 복제되었습니다.또한, 새로운 의사결정 지원 요건이 대두됨에 따라 운영 시스템을 자주 재검토하였다.많은 경우 새로운 요건으로 인해 사용자가 즉시 액세스할 수 있도록 맞춤화된 "데이터마트"에서 새로운 데이터를 수집, 정리 및 통합해야 했습니다.

또한 James M. Ker가 IRM Imperative(Wiley & Sons, 1991년)를 발행함에 따라 조직의 데이터 리소스를 관리 및 평가한 후 그 가치를 대차대조표에 자산으로 보고하는 아이디어가 널리 보급되었습니다.이 책에서 Ker는 트랜잭션 기반 시스템에서 파생된 데이터에서 주제 영역 데이터베이스를 채우고 요약 데이터를 더욱 활용하여 경영진의 의사결정을 알리는 스토리지 영역을 만드는 방법을 설명했습니다.이 개념은 모든 기업 내에서 데이터 웨어하우스를 실제적으로 개발하고 관리하는 방법에 대해 더욱 깊이 생각하게 하는 데 도움이 되었습니다.

데이터 웨어하우징 초기 몇 년간의 주요 발전:

  • 1960년대General Mills와 Dartmouth College는 공동 연구 프로젝트에서 용어의 치수[11]사실을 개발했습니다.
  • 1970년대 – AC닐센과 IRI는 소매 [11]판매를 위한 치수 데이터 마트를 제공합니다.
  • 1970년대Bill Inmon은 데이터 [citation needed][12]웨어하우스라는 용어의 정의와 논의를 시작했습니다.
  • 1975Spirry Univac은 세계 최초의 4GL을 포함한 데이터베이스 관리 및 보고서 작성 시스템인 MAPPER(MAintain, Prepare, and Product Executive Reports)를 도입했습니다.이 플랫폼은 정보 센터(현대 데이터 웨어하우스 기술의 선구자)를 구축하기 위해 설계된 최초의 플랫폼입니다.
  • 1983 – Teradata는 의사결정 [13]지원을 위해 특별히 설계된 DBC/1012 데이터베이스 컴퓨터를 도입했습니다.
  • 1984 – David Liddle과 Don Massaro에 의해 설립Metapo Computer Systems는 비즈니스 사용자를 위한 하드웨어/소프트웨어 패키지와 GUI를 출시하여 데이터베이스 관리 및 분석 시스템을 구축합니다.
  • 1988 – Barry Devlin과 Paul Murphy는 "비즈니스 및 정보 시스템을 위한 아키텍처"라는 기사를 발표하면서 "비즈니스 데이터 웨어하우스"[14]라는 용어를 도입했습니다.
  • 1990 – Ralph Kimball이 설립한 Red Brick Systems는 데이터 웨어하우징 전용 데이터베이스 관리 시스템인 Red Brick Warehouse를 도입했습니다.
  • 1991 - James M. Ker의 저자인 The IRM Imperative는 데이터 자원을 대차대조표에 자산으로 보고할 수 있음을 시사하고 데이터 웨어하우스 설립에 대한 상업적 관심을 높였습니다.
  • 1991 – Bill Inmon에 의해 설립된 Prism Solutions는 데이터 웨어하우스 개발을 위한 소프트웨어인 Prism Warehouse Manager를 도입했습니다.
  • 1992Bill Inmon은 데이터 [15]웨어하우스 구축이라는 책을 출판합니다.
  • 1995 – 데이터 웨어하우징을 촉진하는 영리 단체인 Data Warehousing Institute가 설립되었습니다.
  • 1996Ralph Kimball은 The Data Warehouse [16]Toolkit이라는 을 출판합니다.
  • 2000 – Dan Linstedt는 여러 운영체제에서 들어오는 데이터의 장기 이력 스토리지를 제공하기 위해 1990년에 Inmon 및 Kimball을 대체하는 Data Vault 모델을 공개하고 소스 데이터 모델의 변경에 대한 추적, 감사 및 복원력을 강조합니다.
  • 2008Bill Inmon은 Derek Strauss 및 Genia Neushloss와 함께 "DW 2.0: 차세대 데이터 웨어하우징을 위한 아키텍처"를 출판하여 데이터 웨어하우징에 대한 톱다운 접근방식을 설명하고 데이터 웨어하우징 2.0이라는 용어를 결합하였습니다.
  • 2012Bill Inmon은 "텍스트의 모호성 해소"로 알려진 공개 기술을 개발하고 개발합니다.텍스트 명확화는 원시 텍스트에 컨텍스트를 적용하고 원시 텍스트와 컨텍스트를 표준 데이터베이스 형식으로 재구성합니다.텍스트의 명확화를 통해 원시 텍스트가 전달되면 표준 비즈니스 인텔리전스 기술을 통해 쉽고 효율적으로 액세스하고 분석할 수 있습니다.텍스트 ETL의 실행을 통해 텍스트 명확화가 이루어집니다.텍스트 명확화는 문서, Hadoop, e-메일 등 원시 텍스트가 발견되는 모든 곳에서 유용합니다.

정보 저장소

사실들

팩트는 관리대상 엔티티 또는 시스템에 대한 팩트를 나타내는 값 또는 측정값입니다.

보고 주체에 의해 보고된 사실은 미가공 수준이라고 합니다.예를 들어 휴대전화 시스템에서 BTS(Base Transceiver Station)가 트래픽채널 할당 요구를 1,000개 수신하여 820개를 할당하고 나머지를 거부하면 다음 3가지 사실 또는 측정치가 관리 시스템에 보고됩니다.

  • tch_req_total = 1000
  • tch_req_success = 820
  • tch_req_fail = 180

원시 수준의 사실은 다양한 차원에서 더 높은 수준으로 집계되어 더 많은 서비스 또는 비즈니스 관련 정보를 추출합니다.이를 집계, 요약 또는 집계된 사실이라고 합니다.

예를 들어, 도시에 3개의 BTS가 있는 경우, 위의 사실은 BTS에서 네트워크 차원에서 도시 수준까지 집약할 수 있습니다.예를 들어 다음과 같습니다.

  • tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3
  • avg_tch_req_success_city = (tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3) / 3

데이터 저장에 대한 치수와 정규화 접근법

데이터 웨어하우스에 데이터를 저장하는 방법에는 세 가지 이상의 주요 접근법이 있습니다. 가장 중요한 접근법은 치수 접근법과 정규화 접근법입니다.

차원 접근법은 데이터 웨어하우스를 차원 모델/ 스키마를 사용하여 모델링해야 한다는 Ralph Kimball의 접근 방식을 말합니다.3NF 모델(Third Normal Form)이라고도 하는 정규화 접근방식은 데이터 웨어하우스를 E-R 모델/정규화 [17]모델을 사용하여 모델링해야 한다는 Bill Inmon의 접근방식을 말합니다.

차원적 접근

차원적 접근에서 트랜잭션 데이터는 일반적으로 수치적인 트랜잭션 데이터인 '팩트'와 사실에 대한 맥락을 제공하는 참조 정보인 '차원'으로 구분된다.예를 들어, 판매 트랜잭션은 주문 건수, 총대금 등의 사실과 주문 날짜, 고객 이름, 상품 번호, 주문 발송처 및 청구처 장소, 주문 수령 담당 영업사원 등의 차원으로 나눌 수 있습니다.

차원 접근법의 주요 장점은 데이터 웨어하우스를 사용자가 더 쉽게 이해하고 사용할 수 있다는 것입니다.또, 데이터 웨어하우스로부터의 데이터 취득은 매우 [16]고속으로 행해지는 경향이 있습니다.치수 구조는 측정/팩트 및 컨텍스트/차원으로 구분되므로 비즈니스 사용자가 이해하기 쉽습니다.사실은 조직의 비즈니스 프로세스 및 운영 시스템과 관련이 있지만, 이를 둘러싼 차원에는 측정에 대한 컨텍스트가 포함되어 있습니다(Kimball, Ralph 2008).차원 모델이 제공하는 또 다른 장점은 매번 관계형 데이터베이스를 포함하지 않는다는 것입니다.따라서 이러한 모델링 기법은 데이터 웨어하우스의 최종 사용자 쿼리에 매우 유용합니다.

사실과 차원의 모델은 데이터 [18]큐브로도 이해할 수 있습니다.여기서 치수는 다차원 입방체의 범주 좌표이며 사실은 좌표에 해당하는 값입니다.

치수 접근법의 주요 단점은 다음과 같습니다.

  1. 사실과 차원의 무결성을 유지하기 위해 서로 다른 운영 체제의 데이터를 데이터 웨어하우스에 로드하는 것은 복잡합니다.
  2. 차원적 접근 방식을 채택한 조직이 비즈니스 수행 방식을 변경할 경우 데이터 웨어하우스 구조를 수정하기가 어렵습니다.

표준화된 접근법

정규화 어프로치에서는 데이터 웨어하우스의 데이터는 어느 정도 데이터베이스 정규화 규칙에 따라 저장됩니다.테이블은 일반적인 데이터 범주(예: 고객, 제품, 재무 등)를 반영하는 주제별로 그룹화됩니다.정규화된 구조는 데이터를 엔티티로 분할하여 관계형 데이터베이스에 여러 테이블을 만듭니다.대기업에 적용하면 수십 개의 테이블이 결합 웹에 의해 서로 링크됩니다.또한 생성된 각 엔티티는 데이터베이스 구현 시 별도의 물리적 테이블로 변환됩니다(Kimball, Ralph 2008).이 접근법의 주요 장점은 데이터베이스에 정보를 쉽게 추가할 수 있다는 것입니다.이 접근법의 몇 가지 단점은 관련된 테이블의 수 때문에 사용자가 서로 다른 소스의 데이터를 의미 있는 정보에 결합하고 데이터 웨어하우스의 데이터 구조를 정확하게 이해하지 않으면 정보에 액세스하기가 어려울 수 있다는 것입니다.

정규화 모델과 차원 모델 모두 결합된 관계 테이블을 포함하므로 개체 관계 다이어그램에 나타낼 수 있습니다.두 모형의 차이는 정규화의 정도(정규 형식이라고도 함)입니다.이러한 접근방식은 상호 배타적이지 않으며 다른 접근방식이 있습니다.차원 접근법에는 어느 정도 데이터 정규화가 수반될 수 있습니다(Kimball, Ralph 2008).

정보 중심 [19]비즈니스에서 Robert Hillard는 비즈니스 문제의 정보 요구에 따라 두 가지 접근 방식을 비교하는 접근방식을 제안합니다.이 기술은 정규화된 모델이 치수 등가물보다 훨씬 더 많은 정보를 보유한다는 것을 보여주지만(두 모델에서 동일한 필드를 사용하는 경우에도), 이러한 추가 정보는 사용 편의성을 희생합니다. 기술은 정보의 엔트로피와 사용성의 관점에서 Small Worlds 데이터 변환 측정의 [20]관점에서 정보량을 측정합니다.

설계 방법

상향식 설계

상향식 접근법에서는 먼저 특정 비즈니스 프로세스에 대한 보고 및 분석 기능을 제공하기 위해 데이터 마트를 만듭니다.그런 다음 이러한 데이터 마트를 통합하여 포괄적인 데이터 웨어하우스를 구축할 수 있습니다.데이터 웨어하우스 버스 아키텍처는 주로 두 개 이상의 데이터 [21]마트에서 사실 간에 (특정 방식으로) 공유되는 치수사실집합인 "버스"를 구현한 것입니다.

톱다운 설계

하향식 접근 방식은 표준화된 엔터프라이즈 데이터 모델을 사용하여 설계되었습니다."원자" 데이터, 즉 가장 상세한 수준의 데이터가 데이터 웨어하우스에 저장됩니다.특정 비즈니스 프로세스 또는 특정 부서에 필요한 데이터를 포함하는 차원 데이터 마트는 데이터 [22]웨어하우스에서 생성됩니다.

하이브리드 설계

데이터 웨어하우스(DW)는 허브스포크 아키텍처와 유사한 경우가 많습니다.웨어하우스를 지원하는 레거시 시스템에는 고객 관계 관리 및 엔터프라이즈 리소스 계획이 포함되어 대량의 데이터를 생성하는 경우가 많습니다.이러한 다양한 데이터 모델을 통합하고 변환 부하 추출 프로세스를 용이하게 하기 위해 데이터 웨어하우스는 종종 실제 DW로 해석되는 정보인 운영 데이터 저장소를 사용합니다. 데이터 중복성을 줄이기 위해 대규모 시스템이 데이터를 정규화된 방식으로 저장하는 경우가 많습니다.그런 다음 특정 보고서의 데이터 마트를 데이터 웨어하우스 위에 구축할 수 있습니다.

하이브리드 DW 데이터베이스는 데이터 중복을 제거하기 위해 세 번째 정규 형식으로 유지됩니다.그러나 차원 모델링이 널리 사용되는 비즈니스 인텔리전스 보고서에는 일반적인 관계형 데이터베이스가 효율적이지 않습니다.소규모 데이터 마트는 통합 웨어하우스에서 데이터를 구입하여 필요한 팩트 테이블 및 치수에 대해 필터링된 특정 데이터를 사용할 수 있습니다.DW는 데이터 마트가 읽을 수 있는 단일 정보 소스를 제공하여 광범위한 비즈니스 정보를 제공합니다.하이브리드 아키텍처를 통해 DW를 운영 정보(정적이 아닌)가 상주할 수 있는 마스터 데이터 관리 저장소로 대체할 수 있습니다.

데이터 볼트 모델링 구성 요소는 허브 및 스포크 아키텍처를 따릅니다.이 모델링 스타일은 제3의 정규 형태와 스타 스키마의 베스트 프랙티스로 구성된 하이브리드 디자인입니다.데이터 볼트 모델은 진정한 세 번째 정규 형식이 아니며 규칙 중 일부를 위반하지만 상향식 설계를 사용하는 하향식 아키텍처입니다.데이터 볼트 모델은 완전히 데이터 웨어하우스에 맞춰져 있습니다.최종 사용자가 접근할 수 있도록 설계되어 있지 않습니다.구축 시에도 비즈니스 목적으로 데이터마트 또는 스타 스키마 기반 릴리스 영역을 사용해야 합니다.

데이터 웨어하우스 특성

데이터 웨어하우스에는 서브젝트 오리엔테이션, 데이터 통합, 시간 변수, 비휘발성 데이터, 데이터 정밀도 등 데이터를 정의하는 기본 기능이 있습니다.

주체지향적

운영 체제와 달리 데이터 웨어하우스의 데이터는 기업의 주제를 중심으로 이루어집니다.피사체 방향은 데이터베이스 정규화가 아닙니다.주제지향은 의사결정에 매우 유용할 수 있다.필요한 개체를 수집하는 것을 주체 지향이라고 합니다.

통합된

데이터 웨어하우스 내에서 발견된 데이터는 통합됩니다.여러 운영 체제에서 제공되므로 모든 불일치를 제거해야 합니다.일관성에는 명명 규칙, 변수 측정, 인코딩 구조, 데이터의 물리적 속성 등이 포함됩니다.

시간 변수

운영 시스템은 일상적인 운영을 지원하기 때문에 현재 가치를 반영하지만, 데이터 웨어하우스 데이터는 긴 시간 범위(최대 10년)를 나타내며, 이는 대부분 과거 데이터를 저장한다는 것을 의미합니다.주로 데이터 마이닝 및 예측용입니다.(예를 들어 사용자가 특정 고객의 구매 패턴을 찾는 경우 현재 및 과거의 구매 데이터를 볼 필요가 있습니다.)[23]

비휘발성

데이터 웨어하우스의 데이터는 읽기 전용이므로 업데이트, 생성 또는 삭제할 수 없습니다(규제 또는 법적 의무가 없는 한).[24]

데이터 웨어하우스 옵션

집약

데이터 웨어하우스 프로세스에서는 추상화 수준이 다른 데이터 마트에 데이터를 집약할 수 있습니다.사용자는 전체 지역에서 제품의 총 판매 단위를 보기 시작할 수 있습니다.그런 다음 사용자는 해당 지역의 상태를 확인합니다.마지막으로, 그들은 특정 상태의 개별 매장을 검사할 수 있다.따라서 일반적으로 분석은 더 높은 수준에서 시작하여 더 낮은 수준의 [23]세부 정보를 드릴다운합니다.

데이터 웨어하우스 아키텍처

조직이 지정한 데이터 웨어하우스를 구축/구성하는 데 사용되는 다양한 방법이 있습니다.데이터 웨어하우스의 올바른 기능에 특히 필요한 하드웨어, 작성된 소프트웨어 및 데이터 리소스는 데이터 웨어하우스 아키텍처의 주요 구성요소입니다.모든 데이터 웨어하우스에는 조직의 요건이 수정되고 [25]미세 조정되는 여러 단계가 있습니다.

운영 체제와 비교

운영체계는 데이터베이스 정규화 및 엔티티 관계 모델을 사용하여 데이터 무결성 보존 및 비즈니스 트랜잭션 기록 속도를 위해 최적화된다.운영 체제 설계자는 일반적으로 데이터 무결성을 보장하기 위해 Codd의 12가지 데이터베이스 정규화 규칙을 따릅니다.완전히 정규화된 데이터베이스 설계(즉, 모든 Codd 규칙을 충족하는 설계)로 인해 비즈니스 트랜잭션의 정보가 수십에서 수백 개의 테이블에 저장되는 경우가 많습니다.관계형 데이터베이스는 이러한 테이블 간의 관계를 효율적으로 관리할 수 있습니다.트랜잭션이 처리될 때마다 해당 테이블의 적은 양의 데이터만 영향을 받기 때문에 데이터베이스는 삽입/업데이트 성능이 매우 빠릅니다.성능을 향상시키기 위해 오래된 데이터는 일반적으로 운영 체제에서 정기적으로 삭제됩니다.

데이터 웨어하우스는 분석 액세스 패턴에 맞게 최적화되어 있습니다.분석 액세스 패턴은 일반적으로 특정 필드를 선택해야 하며, 거의 선택되지 않는 경우가 없습니다.select *모든 필드/패킷을 선택합니다.이것은, 운용 데이타베이스에서 보다 일반적인 필드/패킷입니다.이러한 액세스 패턴의 차이로 인해 운영 데이터베이스(느슨한 OLTP)는 행 지향 DBMS를 사용하는 반면 분석 데이터베이스(느슨한 OLAP)는 열 지향 DBMS를 사용하는 이점을 누릴 수 있습니다. 일반적으로 비즈니스 스냅샷을 유지하는 운영 시스템과 달리 데이터 웨어하우스는 무한히 긴 역사를 유지합니다.운영체제에서 데이터 웨어하우스로 데이터를 정기적으로 이행하는 ETL 프로세스를 통해 구현됩니다.

조직 사용의 진화

이러한 용어는 데이터 웨어하우스의 정교함 수준을 나타냅니다.

오프라인 운영 데이터 웨어하우스
이 진화 단계에 있는 데이터 웨어하우스는 운영 체제에서 정기적으로(보통 매일, 매주 또는 매월) 갱신되며 데이터는 통합 보고서 지향 데이터베이스에 저장됩니다.
오프라인 데이터 웨어하우스
이 단계의 데이터 웨어하우스는 운영체제 내의 데이터로부터 정기적으로 갱신되며, 데이터 웨어하우스 데이터는 보고가 용이하도록 설계된 데이터 구조에 격납된다.
정시 데이터 웨어하우스
온라인 통합 데이터 웨어하우징은 실시간 데이터 웨어하우스의 단계 데이터가 소스 데이터에 대해 수행되는 모든 트랜잭션에 대해 업데이트됩니다.
통합 데이터 웨어하우스
이러한 데이터 웨어하우스는 서로 다른 비즈니스 영역의 데이터를 통합하여 사용자가 다른 [26]시스템에서 필요한 정보를 검색할 수 있도록 합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Dedić, Nedim; Stanier, Clare (2016). Hammoudi, Slimane; Maciaszek, Leszek; Missikoff, Michele M. Missikoff; Camp, Olivier; Cordeiro, José (eds.). An Evaluation of the Challenges of Multilingualism in Data Warehouse Development. International Conference on Enterprise Information Systems, 25–28 April 2016, Rome, Italy (PDF). Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016). Vol. 1. SciTePress. pp. 196–206. doi:10.5220/0005858401960206. ISBN 978-989-758-187-8.
  2. ^ a b "9 Reasons Data Warehouse Projects Fail". blog.rjmetrics.com. 4 December 2014. Retrieved 2017-04-30.
  3. ^ "Exploring Data Warehouses and Data Quality". spotlessdata.com. Archived from the original on 2018-07-26. Retrieved 2017-04-30.
  4. ^ "What is Big Data?". spotlessdata.com. Archived from the original on 2017-02-17. Retrieved 2017-04-30.
  5. ^ Patil, Preeti S.; Srikantha Rao; Suryakant B. Patil (2011). "Optimization of Data Warehousing System: Simplification in Reporting and Analysis". IJCA Proceedings on International Conference and Workshop on Emerging Trends in Technology (ICWET). Foundation of Computer Science. 9 (6): 33–37.
  6. ^ Marakas & O'Brien 2009
  7. ^ a b c d e f Rainer, R. Kelly; Cegielski, Casey G. (2012-05-01). Introduction to Information Systems: Enabling and Transforming Business, 4th Edition (Kindle ed.). Wiley. pp. 127, 128, 130, 131, 133. ISBN 978-1118129401.
  8. ^ "Data Mart Concepts". Oracle. 2007.
  9. ^ "OLTP vs. OLAP". Datawarehouse4u.Info. 2009. We can divide IT systems into transactional (OLTP) and analytical (OLAP). In general, we can assume that OLTP systems provide source data to data warehouses, whereas OLAP systems help to analyze it.
  10. ^ "The Story So Far". 2002-04-15. Archived from the original on 2008-07-08. Retrieved 2008-09-21.
  11. ^ a b 킴볼 2013, 15페이지
  12. ^ "The audit of the Data Warehouse Framework" (PDF).
  13. ^ Paul Gillin (February 20, 1984). "Will Teradata revive a market?". Computer World. pp. 43, 48. Retrieved 2017-03-13.
  14. ^ Devlin, B. A.; Murphy, P. T. (1988). "An architecture for a business and information system". IBM Systems Journal. 27: 60–80. doi:10.1147/sj.271.0060.
  15. ^ Inmon, Bill (1992). Building the Data Warehouse. Wiley. ISBN 0-471-56960-7.
  16. ^ a b Kimball, Ralph (2011). The Data Warehouse Toolkit. Wiley. p. 237. ISBN 978-0-470-14977-5.
  17. ^ Golfarelli, Matteo; Maio, Dario; Rizzi, Stefano (1998-06-01). "The dimensional fact model: a conceptual model for data warehouses". International Journal of Cooperative Information Systems. 07 (2n03): 215–247. doi:10.1142/S0218843098000118. ISSN 0218-8430.
  18. ^ "Introduction to Data Cubes".
  19. ^ Hillard, Robert (2010). Information-Driven Business. Wiley. ISBN 978-0-470-62577-4.
  20. ^ "Information Theory & Business Intelligence Strategy - Small Worlds Data Transformation Measure - MIKE2.0, the open source methodology for Information Development". Mike2.openmethodology.org. Retrieved 2013-06-14.
  21. ^ "The Bottom-Up Misnomer - DecisionWorks Consulting". DecisionWorks Consulting. 17 September 2003. Retrieved 2016-03-06.
  22. ^ Gartner, 데이터 웨어하우스, 운용 데이터 스토어, 데이터마트 및 데이터 아웃하우스, 2005년 12월
  23. ^ a b Paulraj., Ponniah (2010). Data warehousing fundamentals for IT professionals. Ponniah, Paulraj. (2nd ed.). Hoboken, N.J.: John Wiley & Sons. ISBN 9780470462072. OCLC 662453070.
  24. ^ H., Inmon, William (2005). Building the data warehouse (4th ed.). Indianapolis, IN: Wiley Pub. ISBN 9780764599446. OCLC 61762085.
  25. ^ Gupta, Satinder Bal; Mittal, Aditya (2009). Introduction to Database Management System. Laxmi Publications. ISBN 9788131807248.
  26. ^ "Data Warehouse".

추가 정보