데이터베이스는 일반적으로 온라인 트랜잭션 데이터를 저장하는 반면 데이터 웨어하우스는 일반적으로 기록 데이터를 저장합니다.
데이터베이스 설계는 가능한 한 중복을 피하고, 일반적으로 패러다임에 맞는 규칙을 사용하며, 데이터 웨어하우스 설계는 의도적으로 중복성을 도입하고 반패러다임을 채택하는 것입니다.
데이터베이스는 데이터를 캡처하는 데 사용되고 데이터 웨어하우스는 데이터를 분석하는 데 사용됩니다. 두 가지 기본 요소는 차원 테이블과 사실 테이블입니다. 차원은 시간, 부서, 차원 테이블과 같은 문제를 보는 관점으로, 이러한 것들의 정의가 들어 있으며 사실 테이블에는 쿼리할 데이터와 차원의 ID 가 들어 있습니다.
개념적으로 좀 애매하다. 어떤 기술이든 앱을 위한 것이기 때문에 앱과 결합하면 이해하기 쉽다. 은행업을 예로 들다. 데이터베이스는 거래 시스템의 데이터 플랫폼입니다. 은행에서 고객의 모든 거래가 데이터베이스에 기록되고 기록됩니다. 여기서는 데이터베이스 부기로 간단히 이해할 수 있다. 데이터 웨어하우스는 거래 시스템에서 데이터를 가져오고, 데이터를 요약 및 처리하고, 의사 결정자에게 의사 결정의 근거를 제공하는 분석 시스템의 데이터 플랫폼입니다. 예를 들어, 한 은행의 한 지점에서 한 달에 얼마나 많은 거래가 발생했는지, 그 지점의 당좌 예금 잔액은 얼마인가. 예금이 많고 소비 거래가 많으면 이 지역에 현금인출기를 설치해야 한다.
분명히, 은행의 거래량은 어마하다, 보통 백만 배 혹은 백만 배로 계산된다. 거래 시스템은 실시간이며 적시성을 요구한다. 고객은 수십 초 동안 돈을 예금하여 데이터베이스에 짧은 기간 동안의 데이터만 저장할 것을 요구하는데, 이는 감당할 수 없는 일이다. 분석 시스템은 사후이며 관련 기간 동안 유효한 모든 데이터를 제공해야 합니다. 이 데이터는 대량, 요약 계산이 느리지만, 효과적인 분석 데이터를 제공할 수 있다면 목적을 달성할 수 있다.
데이터 웨어하우스는 이미 많은 데이터베이스가 있는 경우 데이터 리소스를 더 발굴하여 의사 결정의 요구를 충족시키기 위해 만들어졌습니다. 소위 "대형 데이터베이스" 가 아닙니다. 그렇다면 데이터 웨어하우스와 기존 데이터베이스의 차이점은 무엇입니까? W.H.Inmon 의 데이터 웨어하우스 정의 (주제 지향, 통합, 시간 관련, 불변 데이터 세트) 를 살펴보겠습니다.
주제 지향: 기존 데이터베이스는 주로 응용 프로그램을 위해 데이터를 처리하며 동일한 주제에 따라 데이터를 저장하지 않을 수 있습니다. 데이터 웨어하우스는 데이터 분석에 중점을 두고 주제별로 저장됩니다. 이것은 전통적인 농산물 시장과 슈퍼마켓의 차이와 비슷하다. 시장에서 배추, 무, 고수는 노점상에 있을 것이다. 슈퍼마켓에는 배추무향채가 각각 하나씩 있다. 즉, 시장의 요리 (데이터) 는 노점상 (앱) 에 따라 쌓이고, 슈퍼마켓의 요리는 음식의 종류에 따라 쌓인다.
시간 관련: 데이터베이스가 정보를 저장할 때 시간 정보가 있어야 한다는 점을 강조하지 않습니다. 데이터 웨어하우스는 의사 결정의 필요성으로 인해 데이터 웨어하우스의 데이터에 시간 속성을 표시해야 합니다. 시간 속성은 의사 결정에서 매우 중요합니다. 같은 고객이 총 9 대의 차를 샀는데, 하나는 최근 3 개월 동안 9 대의 차를 샀는데, 하나는 최근 1 년 동안 차를 사지 않은 것이 의사결정자에게 의미가 다르다.
수정 불가능: 데이터 저장소의 데이터는 최신 상태가 아니라 다른 데이터 소스에서 가져온 것입니다. 데이터웨어 하우스는 많은 데이터베이스에서 처리하는 일일 거래 데이터 (통신 청구 데이터베이스 및 실시간 정보 처리와 같은 일부 데이터베이스) 가 아닌 과거 정보를 반영합니다. 따라서 데이터 웨어하우스의 데이터는 거의 또는 전혀 수정되지 않습니다. 물론 데이터 웨어하우스에 데이터를 추가할 수 있습니다.
데이터 웨어하우스의 출현은 데이터베이스를 대체하는 것이 아닙니다. 현재 대부분의 데이터 웨어하우스는 관계형 데이터베이스 관리 시스템에 의해 관리됩니다. 데이터베이스와 데이터 웨어하우스는 상호 보완적이며 각각 장점이 있다고 할 수 있다.
그건 그렇고, 데이터 웨어하우스 스키마 구축의 목적은 프런트 엔드 쿼리 및 분석의 기반이 되는 것입니다. 더 큰 중복으로 인해 더 많은 스토리지가 필요합니다. 프런트 엔드 애플리케이션에 더 잘 서비스를 제공하려면 데이터 웨어하우스에 다음과 같은 이점이 있어야 합니다. 그렇지 않으면 실패한 데이터 웨어하우스 스키마입니다.
1. 충분히 효율적입니다. 고객이 요구하는 분석 데이터는 일반적으로 일, 주, 월, 분기, 연도 등으로 나뉜다. 일별 주기 데이터 요구 사항이 가장 효율적이며 고객이 24 시간 또는 12 시간 이내에 어제의 데이터 분석을 볼 것을 요구한다는 것을 알 수 있습니다. 일부 기업의 일일 데이터 양이 많기 때문에 설계가 좋지 않은 데이터 웨어하우스에 문제가 발생하는 경우가 많기 때문에 지연 1-3 일 동안 데이터를 제공하는 것은 분명 불가능합니다.
2. 데이터 품질. 고객이 각종 정보를 보려면 정확한 데이터가 있어야 한다. 그러나 데이터 웨어하우스 프로세스는 최소 3 단계와 2 개의 ETL 로 구분되므로 복잡한 스키마에는 더 많은 계층이 있습니다. 그런 다음 데이터 소스에 더러운 데이터가 있거나 코드가 엄격하지 않아 데이터 왜곡이 발생할 수 있습니다. 고객이 잘못된 정보를 볼 경우 잘못된 분석 결정을 내리고 수익이 아닌 손실을 초래할 수 있습니다.
3. 확장성. 일부 대형 데이터웨어 하우스 시스템의 아키텍처 설계가 복잡한 이유는 향후 3 ~ 5 년간의 확장성을 고려하여 고객이 데이터웨어 하우스 시스템을 재구성하는 데 너무 많은 돈을 들이지 않고도 안정적으로 운영 할 수 있다는 것입니다. 데이터 모델링의 합리성에 주로 반영되며, 데이터 웨어하우스 스키마에는 더 많은 중간 계층이 있어 대량의 데이터 스트림을 충분히 버퍼링할 수 있어 데이터 양이 많지 않거나 실행되지 않습니다.