데이터 볼트 모델링

이 글은 검증을 위해 인용구가 추가로 필요하다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선할 수 있도록 도와주십시오. 공급되지 않은 재료는 도전하여 제거할 수 있다. 출처 찾기: "데이터 볼트 모델링" – 뉴스 · 신문 · 책 · 학자 · JSTOR (2016년 11월) (이 템플릿 메시지 제거 방법과 시기 알아보기)

Data Vault Modeling은 여러 운영 체제에서 들어오는 데이터의 장기 기록 저장 기능을 제공하도록 설계된 데이터베이스 모델링 방법이다. 감사, 데이터의 추적, 변화를 위한 로딩 속도, 복원력 등의 문제를 다루는 과거 데이터를 살펴보는 것도 방법이며, 데이터베이스의 모든 데이터가 어디에서 왔는지 추적할 필요성을 강조하는 것도 방법이다. 즉, 데이터 볼트의 모든 행에는 기록 소스 및 로드 날짜 속성이 수반되어야 감사자가 소스로 다시 값을 추적할 수 있다. 2000년 다니엘 린스테트가 개발했다.

데이터 볼트 모델링은 좋은 데이터와 나쁜 데이터("불량")를 구분하지 않으며, 이는 비즈니스 규칙을 준수하지 않는다는 것을 의미한다.^[1] 이는 데이터 저장소가 정의에 부합하지 않는 데이터를 제거하거나 "삭제"하는 "단일 버전의 진실"^[2]을 저장하는 다른 데이터 웨어하우스 방법의 관행과는 반대로 "단일 버전의 사실"(Dan Linstedt에 의해 "모든 데이터, 항상"으로 표현됨)을 저장한다는 진술에 요약된다.

모델링 방법은 구조 정보와 기술 속성을 명시적으로 분리하여 저장 중인 데이터가 나오는 비즈니스 환경의 변화에 탄력적으로 대응할 수 있도록 설계되었다.^[3] 데이터 저장소는 최대한 병렬 로딩이 가능하도록 설계되어 있으므로 대규모 구현으로 대규모 재설계 없이도 스케일아웃할 수 있다.^[4]

역사와 철학

이 글에는 아마도 독창적인 연구가 포함되어 있을 것이다. Template talk에서 관련 논의를 확인할 수 있다.독창적인 연구. 클레임을 확인하고 인라인 인용문을 추가하여 개선하십시오. 독창적인 연구로만 구성된 진술은 삭제해야 한다. (2019년 8월) (이 템플릿 메시지를 제거하는 방법과 시기 알아보기)

데이터 웨어하우스 모델링에는 데이터가 저장되는 계층을 모델링하기 위한 두 가지 잘 알려진 경쟁 옵션이 있다. 랄프 킴볼(Ralph Kimball)에 따라 모델링하거나, 표준화된^{[citation needed]} 데이터베이스로 빌 인몬(Bill Inmon)에 따라 모델링. 두 기법 모두 데이터 웨어하우스를^{[citation needed]} 공급하는 시스템의 변화를 다룰 때 문제가 있다. 순응 치수의 경우 데이터를 정리(순응하기 위해)해야 하며, 이는 불가피하게 정보가^{[citation needed]} 손실되기 때문에 여러 경우 바람직하지 않다. 데이터 저장소는 데이터 저장 영역 밖에 있는 데이터 웨어하우스의 영역으로 이동(데이터 마트에서 정리가 수행됨)하고 구조적 항목(업무용 키 및 업무용 키 간의 연관성)을 기술 속성에서 분리함으로써 이러한 문제의 영향을 방지하거나 최소화하기 위해 설계된다.

메소드의 작성자인 댄 린스테트는 결과 데이터베이스를 다음과 같이 설명한다.

"Data Vault 모델은 하나 이상의 비즈니스 기능 영역을 지원하는 표준화된 테이블의 상세 지향적이고 과거 추적 및 고유하게 연결된 집합입니다. 3차 정규 형태(3NF)와 스타 스키마 사이 최고 품종을 아우르는 하이브리드 접근법이다. 유연하고, 확장 가능하며, 일관되고, 기업의 요구에 적응할 수 있는 설계"^[5]

정해진 정의와 업무 규칙에 맞지 않더라도 모든 데이터가 관련 데이터라는 게 데이터볼트의 철학이다. 데이터가 이러한 정의와 규칙을 준수하지 않는다면 그것은 데이터 웨어하우스가 아니라 비즈니스에 문제가 된다. 데이터가 "잘못됐다"는 판단은 모든 사람에게 유효하지 않을 수 있는 특정 관점 또는 모든 시점에서 비롯되는 데이터의 해석이다. 따라서 데이터 볼트는 모든 데이터를 캡처해야 하며, 데이터 볼트에서 데이터를 보고하거나 추출하는 경우에만 해석된다.

데이터 볼트가 응답하는 또 다른 문제는 데이터 웨어하우스의 모든 데이터에 대한 완전한 감사성과 추적성이 점점 더 필요하다는 것이다. 미국의 Sarbanes-Oxley 요건과 유럽의 유사한 조치들로 인해 이것은 많은 비즈니스 인텔리전스 구현에 관련된 주제로서, 모든 데이터 저장소의 구현의 초점은 모든 정보의 완전한 추적성과 감사 가능성이다.

Data Vault 2.0이 새로운 사양임. 그것은 공개적인 기준이다.^[6] 새로운 규격은 방법론(SEI/CMMI, Six Sigma, SDLC 등), 아키텍처 및 모델의 3개 축으로 구성된다. 방법론 내에서 모범 사례의 구현이 정의된다. Data Vault 2.0은 빅 데이터, NoSQL -와 같은 새로운 구성 요소를 포함시키는 데 중점을 두고 있으며 기존 모델의 성능에도 중점을 두고 있다. 이전 규격(대부분 여기에 문서화됨)은 데이터 볼트 모델링에 매우 중점을 두고 있다. 이 문서에는 다음과 같이 기록되어 있다. Data Vault 2.0으로 확장 가능한 데이터 웨어하우스 구축

EDW 및 BI 시스템을 오늘날의 비즈니스의 요구와 욕구를 최신 상태로 유지하기 위해서는 모범 사례와 함께 새로운 구성요소를 포함하도록 규격을 발전시킬 필요가 있다.

역사

데이터볼트 모델링은 1990년대 댄 린스테트가 구상한 것으로 2000년 공공영역 모델링 방식으로 출시됐다. Data Administration Newsletter에 대한 다섯 가지 기사에서는 Data Vault 방법의 기본 규칙을 확장하고 설명한다. 여기에는 일반적인 개요,^[7] 구성요소의 개요,^[8] 종료 날짜 및 조인에 대한 토론,^[9] 링크 ^[10]테이블 및 적재 작업 관련 기사가 포함된다.^[11]

이 방법의 대안적(그리고 거의 사용되지 않는) 명칭은 "공통 기초 통합 모델링 아키텍처"^[12]이다.

Data Vault 2.0은^[13][14] 2013년 현재 현장에 출시되었으며, 방법론, 아키텍처 및 구현 모범 사례와 함께 빅 데이터, NoSQL, 비정형, 반구조화, 원활한 통합이 표에 제시되어 있다.

대안적 해석

Dan Linstedt에 따르면, 데이터 모델은 뉴런, 덴드라이트, 시냅스에 대한 단순한 시각에서 영감을 얻거나 패턴화된 것으로, 여기서 뉴런은 허브 및 허브 위성과 연관되고, 링크는 덴드라이트(정보 벡터)이며, 다른 링크는 시냅스(반대 방향 벡터)이다. 알고리즘의 데이터 마이닝 세트를 사용함으로써, 링크는 자신감과 강도 등급으로 채점될 수 있다. 그것들은 현재 존재하지 않는 관계에 대한 학습에 따라 즉석에서 만들어지고 떨어뜨릴 수 있다. 모델은 새로운 구조물을 사용하고 공급함에 따라 자동으로 변형되고 조정될 수 있다.^[15]

또 다른 관점은 데이터 볼트 모델이 엔터프라이즈의 온톨로지(Ontology of Enterprise)를 제공하는 것으로, 엔터프라이즈의 도메인(Hubs)과 그것들 사이의 관계(Links)를 설명하고, 필요한 경우 기술 속성(위성)을 추가하는 것이다.

데이터 볼트 모델을 생각하는 또 다른 방법은 그래프 모델이다. 데이터 볼트 모델은 실제로 관계형 데이터베이스 세계에서 허브와 관계를 가진 "그래프 기반" 모델을 제공한다. 이러한 방식으로 개발자는 SQL을 사용하여 초 미만의 응답과 그래프 기반 관계를 얻을 수 있다.

기본 개념

데이터 저장소는 비즈니스 키(비즈니스 엔터티를 고유하게 식별하기 때문에 자주 변경되지 않음)와 이러한 비즈니스 키 간의 연결을 해당 키의 기술 속성에서 분리함으로써 환경 변화에 대처하는 문제를 해결하려고 시도한다.

비즈니스 키와 그 연관성은 데이터 모델의 골격을 형성하는 구조적 속성이다. 데이터 저장 방식은 비즈니스가 변화할 때만 실제 비즈니스 키가 변화한다는 공리 중 하나이며, 따라서 과거 데이터베이스의 구조를 도출하는 가장 안정적인 요소다. 이러한 키를 데이터 웨어하우스의 백본으로 사용하면, 나머지 데이터를 정리할 수 있다. 이는 허브를 위한 올바른 키를 선택하는 것이 모델의 안정성을 위해 가장 중요하다는 것을 의미한다.^[16] 키는 구조물에 몇 가지 제약조건이 있는 표에 저장된다. 이러한 열쇠 장비는 허브라고 불린다.

허브

허브에는 변경 성향이 낮은 고유한 비즈니스 키 목록이 포함되어 있다. 허브에는 각 허브 항목에 대한 대리 키와 비즈니스 키의 원점을 설명하는 메타데이터도 포함되어 있다. 허브에 대한 정보에 대한 설명 속성(키에 대한 설명 등, 아마도 다국어로 된 설명 등)은 아래에 설명될 위성 표라는 구조에 저장된다.

허브에는 적어도 다음 필드가 포함되어 있다.^[17]

• 다른 구조물을 이 테이블에 연결하는 데 사용되는 대리 키
• 이 허브의 원동력인 비즈니스 키 비즈니스 키는 여러 분야로 구성될 수 있다.
• 각 비즈니스 키를 먼저 로드한 시스템을 확인할 수 있는 레코드 소스
• 선택적으로 수동 업데이트(사용자/시간) 및 추출 날짜에 대한 정보가 포함된 메타데이터 필드가 있을 수도 있다.

허브는 두 시스템이 동일한 비즈니스 키를 제공하지만 다른 의미를 갖는 충돌을 제외하고 여러 비즈니스 키를 포함할 수 없다.

허브에는 일반적으로 적어도 하나의 위성이 있어야 한다.^[17]

허브 예제

자동차(H_CAR)라고 불리는 자동차가 들어 있는 허브테이블의 예다. 운전 키는 차량 식별 번호 입니다.

필드명	설명	필수?	댓글
H_CAR_ID	허브의 시퀀스 ID 및 대리 키	아니요.	권장되지만 선택[18] 사항
차량_ID_NR	이 허브를 구동하는 비즈니스 키. 복합 비즈니스 키에 대해 둘 이상의 필드일 수 있음	네
H_RSRC	처음 로드될 때 이 키의 레코드 원본	네
LOAD_AUDIT_아이디	로드 시간, 로드 기간, 라인 수 등 감사 정보가 포함된 테이블의 ID.	아니요.

링크

비즈니스 키 간의 연결 또는 트랜잭션(예: 구매 거래를 통해 고객과 제품을 위한 허브와 서로 연결)은 링크 테이블을 사용하여 모델링한다. 이러한 테이블은 기본적으로 다대다 조인 테이블이며, 일부 메타데이터가 있다.

링크는 세분화된 변경사항을 처리하기 위해 다른 링크에 연결할 수 있다(예를 들어, 데이터베이스 테이블에 새 키를 추가하면 데이터베이스 테이블의 결점이 변경된다). 예를 들어, 고객과 주소 사이에 연관성이 있는 경우, 제품과 운송 회사의 허브 간 링크에 참조를 추가할 수 있다. 이것은 "배달"이라고 불리는 연결고리일 수 있다. 다른 링크에서 링크를 참조하는 것은 병렬 로딩을 더 어렵게 만드는 링크 사이의 종속성을 도입하기 때문에 잘못된 관행으로 간주된다. 다른 링크에 대한 링크는 다른 링크의 허브와의 새로운 링크와 동일하므로, 이러한 경우 다른 링크를 참조하지 않고 링크를 생성하는 것이 선호되는 해결책이다(자세한 내용은 로드 프랙티스 섹션 참조).

링크는 때때로 허브를 그 자체로 허브를 구성할 만큼 충분하지 않은 정보에 연결한다. 이는 링크에 의해 연결된 비즈니스 키 중 하나가 실제 비즈니스 키가 아닐 때 발생한다. 예를 들어, "주문 번호"를 키로 한 주문 양식을 취하고, 반랜덤 번호로 키를 맞춘 라인을 주문하여 고유하게 만든다. "독특한 숫자"라고 하자. 후자의 키는 실제 비즈니스 키가 아니므로 허브가 아니다. 그러나 링크에 대한 정확한 세분성을 보장하기 위해 우리는 그것을 사용할 필요가 있다. 이 경우 우리는 대리 키가 있는 허브를 사용하지 않고 비즈니스 키 "독특한 번호" 자체를 링크에 추가한다. 이는 다른 링크에 비즈니스 키를 사용하거나 위성 속성의 키로 사용할 가능성이 없는 경우에만 수행된다. 이 건축물은 댄 린스테트가 그의 (지금은 없어진) 포럼에서 '독다리 고리'라고 불렸다.

링크에는 연결된 허브에 대한 대리 키, 링크에 대한 자체 대리 키 및 연결의 원점을 설명하는 메타데이터가 포함되어 있다. 관련 정보에 대한 기술 속성(시간, 가격 또는 금액 등)은 아래에서 설명하는 위성 표라는 구조에 저장된다.

링크 예제

자동차용 두 허브(H_CAR)와 사람(H_Person)의 링크테이블을 예로 들 수 있다. 링크는 "드라이버"(L_DRIVER)라고 불린다.

필드명	설명	필수?	댓글
L_DRIVER_아이디	링크에 대한 시퀀스 ID 및 대리 키	아니요.	권장되지만 선택[18] 사항
H_CAR_ID	링크의 첫 번째 앵커인 자동차 허브의 대리 키	네
H_Person_아이디	링크의 두 번째 앵커인 사용자 허브에 대한 대리 키	네
L_RSRC	처음 로드될 때 이 연결의 레코드 원본	네
LOAD_AUDIT_아이디	로드 시간, 로드 기간, 라인 수 등 감사 정보가 포함된 테이블의 ID.	아니요.

위성

허브와 링크는 모델의 구조를 형성하지만 일시적 속성이 없고 서술적 속성이 없다. 이것들은 위성이라고 불리는 별도의 테이블에 저장된다. 이것들은 그들을 그들의 부모 허브나 링크에 연결하는 메타데이터, 연결의 기원과 속성의 기원을 설명하는 메타데이터, 그리고 속성의 시작일과 종료일이 있는 타임라인으로 구성된다. 허브와 링크가 모델의 구조를 제공하는 경우, 위성은 허브와 링크에서 포착되는 비즈니스 프로세스의 맥락인 모델의 "고기"를 제공한다. 이러한 속성은 타임라인뿐만 아니라 사안의 세부사항과 관련해서도 저장되며, 상당히 복잡한 (고객의 완전한 프로필을 기술하는 모든 분야)에서부터 꽤 단순한 (유효한 식별자와 타임라인만 있는 링크 위의 위성)까지 다양할 수 있다.

보통 속성은 소스 시스템별로 위성으로 그룹화된다. 그러나 크기, 비용, 속도, 양 또는 색상과 같은 기술 속성은 서로 다른 비율로 변할 수 있으므로, 이러한 속성은 그 변화 속도를 바탕으로 다른 위성에서 분할할 수도 있다.

모든 표에는 최소한 소스 시스템과 이 항목이 유효하게 된 날짜를 최소로 기술한 메타데이터가 포함되어 있어 데이터 웨어하우스로 들어가는 데이터의 완전한 과거 뷰를 제공한다.

위성 예

이것은 "운전자 보험"(S_DRIVER_)이라 불리는 자동차용 허브와 사람 사이의 드라이버 링크 위성에 대한 예다.보험). 이 위성은 자동차와 그것을 운전하는 사람 사이의 관계에 대한 보험에 특유한 속성을 포함하고 있다. 예를 들어, 이것이 1차 운전자인지, 이 자동차와 사람의 보험 회사 이름(별도의 허브가 될 수도 있음) 및 이 콤비나티와 관련된 사고 횟수를 요약한 것이다.차량 및 운전자에게서. 또한 R_RISTARY_CARCATORY라는 조회 테이블 또는 참조 테이블에 대한 참조도 포함되어 있으며, 여기에는 이 관계가 해당된다고 간주되는 위험 범주에 대한 코드가 포함되어 있다.

필드명	설명	필수?	댓글
S_DRIVER_보험_아이디	링크에서 위성에 대한 시퀀스 ID 및 대리 키	아니요.	권장되지만 선택[18] 사항
L_DRIVER_아이디	(iiii) 위성의 부모인 드라이버 링크의 기본 키	네
S_SEQ_NR	하나의 상위 키에 대해 유효한 위성이 여러 개 있는 경우 고유성을 적용하기 위한 주문 또는 시퀀스 번호	No(**)	예를 들어, 허브 CUS가 있고 과정 이름이 속성이지만 몇 개의 다른 언어로 된 경우 이 문제가 발생할 수 있다.
S_LDTS	상위 키 L_DRIVER_에 대한 이 속성 값 조합의 유효성에 대한 로드 날짜(시작 날짜)아이디	네
S_LEDTS	상위 키 L_DRIVER_에 대한 이 속성 값 조합의 유효성을 위한 종료 날짜(종료 날짜) 로드아이디	아니요.
IND_Primary_DRIVER	운전자가 이 차의 기본 운전자인지 여부를 표시한다.	아니오(*)
보험_회사	이 차량과 이 운전자의 보험 회사 이름	아니오(*)
NR_OF_ACCOESS	이 차량에서 이 운전자가 낸 사고 횟수	아니오(*)
R_RACE_CARCHERIORY_CD	드라이버에 대한 위험 범주. R_RISTARY_CARCHERORIGE에 대한 참조사항이다.	아니오(*)
S_RSRC	이 위성을 처음 로드할 때 이 위성에 있는 정보의 레코드 원본	네
LOAD_AUDIT_아이디	로드 시간, 로드 기간, 라인 수 등 감사 정보가 포함된 테이블의 ID.	아니요.

(*) 적어도 하나의 속성은 필수 사항. (**) 시퀀스 번호는 동일한 허브 또는 링크에 있는 여러 유효 위성에 대해 고유성을 적용해야 할 경우 필수 사항이 된다.

참조표

참조 테이블은 정상적인 데이터 볼트 모델의 일반적인 부분이다. 그것들은 많이 참조되는 단순한 참조 데이터의 중복 저장을 방지하기 위해 존재한다. 보다 공식적으로 댄 린스테드는 기준 데이터를 다음과 같이 정의한다.

코드의 설명을 해결하거나 키를 (sic) 일관된 방식으로 변환하기 위해 필요하다고 간주되는 정보 이들 분야 중 많은 부분이 본질적으로 "설명적"이며 다른 보다 중요한 정보의 특정 상태를 설명한다. 따라서 참조 데이터는 원시 Data Vault 테이블과 별도의 테이블에 저장된다.^[19]

참조 테이블은 Satellite에서 참조되지만 실제 외래 키로는 절대 바인딩되지 않는다. 참조 테이블에 대해 규정된 구조는 없다. 단순 조회 테이블에서 소형 데이터 볼트 또는 별에 이르기까지 특정 경우에 가장 적합한 구조를 사용하십시오. 그것들은 역사적일 수도 있고 역사가 없을 수도 있지만, 자연적인 열쇠를 고수하고 그런 경우에는 대리키를 만들지 않는 것이 좋다.^[20] 일반적으로 데이터 볼트에는 다른 데이터 웨어하우스와 마찬가지로 많은 참조 테이블이 있다.

참조 예제

이것은 차량 운전자에 대한 위험 범주가 있는 참조표의 예다. 데이터 저장소에 있는 모든 위성에서 참조할 수 있다. 현재 우리는 그것을 위성 S_DRIVER_에서 참조한다.보험. 참조표는 R_RISCORY_CARCATORY 입니다.

필드명	설명	필수?
R_RACE_CARCHERIORY_CD	위험 범주에 대한 코드	네
REACKE_CARTORY_DESCH	위험 범주에 대한 설명	아니오(*)

(*) 하나 이상의 속성이 필수 사항.

로딩 프랙티스

데이터 볼트 모델 업데이트를 위한 ETL은 매우 간단하다(Data Vault Series 5 – Loading Practices 참조). 먼저 모든 허브를 로드하여 새로운 비즈니스 키에 대한 대리 ID를 생성해야 한다. 이제 허브를 조회하면 모든 비즈니스 키를 대리 ID로 해결할 수 있다. 두 번째 단계는 허브 간의 연결을 해결하고 새로운 연결에 대한 대리 ID를 만드는 것이다. 동시에 대리 ID에 대한 키를 확인할 수 있으므로 허브에 연결된 모든 위성을 만들 수도 있다. 대리 키로 모든 새 링크를 만들었으면 모든 링크에 위성을 추가할 수 있다.

링크를 통해서만 허브가 서로 연결되지 않기 때문에 모든 허브를 병렬로 로딩할 수 있다. 링크는 서로 직접 연결되지 않기 때문에 모든 링크도 병렬로 로딩할 수 있다. 인공위성은 허브와 링크에만 부착할 수 있기 때문에 이를 병렬로 탑재할 수도 있다.

ETL은 매우 간단하고 쉬운 자동화나 템플리트에 적합하다. 문제는 다른 링크와 관련된 링크에서만 발생한다. 링크에서 비즈니스 키를 해결하면 다른 링크도 해결되어야 하기 때문이다. 이러한 상황이 여러 허브로 연결되는 등가성 때문에 이러한 경우를 리모델링하여 이러한 어려움을 피할 수 있으며, 이는 실제로 권장되는 관행이다.^[11]

데이터를 로드하는 동안 기술적 오류가 발생하지 않는 한 데이터는 데이터 볼트에서 삭제되지 않는다.

데이터 볼트 및 치수 모델링

데이터 볼트 모델링 계층은 일반적으로 데이터를 저장하는 데 사용된다. 쿼리 성능에 최적화되어 있지 않으며, Cognos, OBIE, SAP Business Objects, Pentaho 등 잘 알려진 쿼리 도구로 쿼리하기도 쉽지 않다.^{[citation needed]} 이러한 최종 사용자 컴퓨팅 도구는 데이터가 치수 모델에 포함될 것으로 기대하거나 선호하기 때문에 일반적으로 변환이 필요하다.

이러한 목적을 위해, 그러한 허브의 허브와 관련 위성은 치수로 간주될 수 있고 링크와 관련 위성은 치수 모델의 사실 표로 볼 수 있다. 이를 통해 뷰를 사용하여 데이터 볼트 모델에서 치수 모델을 신속하게 프로토타입할 수 있다.

데이터 볼트 모델에서 (변형된) 치수 모델로 데이터를 이동하는 것은 비교적 간단하지만, 치수 모델의 사실 표의 비원형 특성을 고려할 때, 데이터 볼트의 세 번째 일반적인 형태와는 근본적으로 다른, 그 반대의 경우는 쉽지 않다.

데이터 볼트 방법론

데이터 볼트 방법론은 SEI/CMMI 레벨 5 모범 사례를 기반으로 한다. CMMI 레벨 5의 여러 구성 요소를 포함하고 있으며, 식스 시그마, TQM, SDLC의 모범 사례와 결합한다. 특히 스콧 앰블러의 신속한 구축 및 배치 방법론에 초점을 맞추고 있다. 데이터 볼트 프로젝트는 범위가 제어되는 짧은 릴리스 주기를 가지며 2-3주마다 프로덕션 릴리스로 구성되어야 한다.

데이터 저장 방법론을 사용하는 팀은 CMMI 레벨 5에서 예상되는 반복 가능하고 일관되며 측정 가능한 프로젝트에 쉽게 적응해야 한다. EDW 데이터 볼트 시스템을 통해 흐르는 데이터는 BI(비즈니스 인텔리전스) 프로젝트에서 오랫동안 빠져 있던 TQM(총품질관리) 라이프사이클을 따르기 시작한다.

도구들

2150 데이타볼 빌더

웨레스케이프

볼트 속도

참조

인용구

원천

문학

• 패트릭 쿠바: 데이터 볼트 구루. 데이터 저장소 구축에 대한 실용적 가이드. Selbstverlag, ohne Ort 2020, ISBN 979-86-9130808-6.
• 존 자일스: 냉장고에 있는 코끼리. 비즈니스 중심 모델 구축을 통해 Data Vault 성공을 위한 안내 단계 테크닉스, 바스킹리지 2019, ISBN 978-1-63462-489-3.
• 켄트 그라지아노: 더 나은 데이터 모델링. Data Vault 2.0을 사용한 신속한 변화를 위한 데이터 엔지니어링 소개 데이터 워리어, 휴스턴 2015.
• Hans Hultgren: Data Vault로 신속한 변화를 위한 데이터 웨어하우스 모델링. 2012년 덴버의 브라이튼 해밀턴, ISBN 978-0-615-72308-2.
• Dirk Lerner: Data Vault für 신속한 변화를 위한 Data-Warehouse-Architecturen. 인: Stephan Trahash, Michael Zimmer (Hrsg): 민첩한 비즈니스 인텔리전스. Theory und Praxis. dpunkt.verlag, Hielberg 2016, ISBN 978-3-86490-312-0, S. 83–98.
• 대니얼 린스테트: 데이터 웨어하우스를 대폭 충전하십시오. Data Vault를 구현하기 위한 귀중한 데이터 모델링 규칙. 린스테트, 세인트 알반스, 버몬트 2011, ISBN 978-1-4637-7868-2.
• 대니얼 린스테트, 마이클 올스키: Data Vault 2.0으로 확장 가능한 데이터 웨어하우스 구축 모건 카우프만, 메사추세츠 월텀, ISBN 978-0-12-802510-9
• Dani Schnider, Clos Jordan u. 데이터 웨어하우스 Blueprint. Praxis의 비즈니스 인텔리전스. 한서, 뮌헨 2016 ISBN 978-3-446-45075-2, S. 35–37, 161–173.

외부 링크

• Data Vault 커뮤니티 사용자를 위한 홈
• 인증 경로
• Data Vault 모델 개발자인 Dan Linstedt의 홈페이지
• Dan Linstedt가 관리하는 Data Vault 전용 웹 사이트
• Data Vault 모델링 접근 방식 및 방법론에 대한 YouTube 비디오
• Dan Linstedt의 슬라이드 공유 사이트
• Data Vault 인증 사이트
• 신속한 변화를 위한 데이터 사이트
• 훈련된 신속한 변화를 위한 배송(DAD) 사이트