나는 단지 Data Vault modeling에 대해 읽고 있었고, 내가 이해하는 한, 허브는 키 (및 레코드 소스)만을 포함하고있다. 그래서 내가 레코드 저장소를 저장하기 위해 왜 허브 테이블을 만들어야하는지 궁금합니다. 위성 및 링크 만 있으면 충분하지 않습니까?데이터 저장소 모델 : 허브가 좋은 점은 무엇입니까?
Btw : 데이터 저장소 양식의 간단한 mysql 테이블을 다운로드하여 함께 사용하려고합니다.
나는 단지 Data Vault modeling에 대해 읽고 있었고, 내가 이해하는 한, 허브는 키 (및 레코드 소스)만을 포함하고있다. 그래서 내가 레코드 저장소를 저장하기 위해 왜 허브 테이블을 만들어야하는지 궁금합니다. 위성 및 링크 만 있으면 충분하지 않습니까?데이터 저장소 모델 : 허브가 좋은 점은 무엇입니까?
Btw : 데이터 저장소 양식의 간단한 mysql 테이블을 다운로드하여 함께 사용하려고합니다.
허브는 여러 소스의 수동 통합이 적용되는 곳입니다. 데이터 소스에 대한 열을 가지며 허브에 처음 도착할 때 각 키의 모든 인스턴스를 기록합니다. 예를 들어 CRM 시스템과 ERP 시스템이 있고 CRM 시스템의 데이터를 먼저 동기화하면 ERP 데이터를 사용할 수 있습니다. CRM 시스템의 모든 키를 "CRM"의 데이터 소스 열 값과 함께 추가합니다. 그런 다음 ERP 시스템을 도입 할 때 테이블 구조가 동일하다고 가정하고 ERP 시스템에만 존재하는 새로운 키를 "ERP"라는 데이터 소스와 함께 추가합니다. 키가 다른 경우 두 시스템의 모든 데이터를 추가해야합니다. 요점은 모든 시스템의 모든 데이터를 유지한다는 것입니다. Business Data Vault 또는 데이터 마트가 될 다음 계층으로 이동할 때 "비즈니스 규칙"에 따라 허브 및 위성에 대해 비즈니스 로직을 적용하여 적용 가능한 경우 두 시스템의 결과 행 하나를 가져옵니다. 변환을이 중간 상태로 저장하기 전에 변환을 사용하면 감사 기능이 손실되고 나중에 비즈니스 규칙을 변경할 수 있습니다. 이해가 되니?
데이터 볼트 모델링의 주요 개념 중 하나는 비즈니스 키, 상세 데이터 용 위성 및 허브 연결 링크입니다.
예
Employee
--------
Personnel Number
Name
Surname
Street
City
Department
--------
ID
Shortcode
Name
Employee Number
은 한 부서가 하나 명의 직원을 가지고 상상해보십시오. 비즈니스 키
이제 비즈니스를위한 비즈니스 식별자는 직원 및 부서 필요가 식별 할 객체. 이 부서의 직원 및 단축 코드에 대한 인원 수이 될 것입니다.
부서에 대한 이유는 무엇입니까? ID는 데이터베이스 내부 ID 일 가능성이 큽니다. 짧은 코드는이 예에서 DEP_A1613
과 같은 것으로 부서를 식별하는 데 내부적으로 사용됩니다.
모델링
직원의 허브는 현장 직원 수 및 부서 만의 단축 코드의 허브로 구성되어 있습니다.
즉, 데이터 볼트 모델링의 허브는 비즈니스 키 만 만 저장하기위한 것입니다. 물론 데이터 볼트 필드는 레코드 소스, 등로드 날짜 등이 필요합니다. 두 허브는 설명 데이터에 대해 해당 Satellite를 갖습니다. 허브없이 위성을 서로 연결하는 것은 데이터 볼트 모델링 기술을 위반하는 것입니다. 그것은 당신이 허브를 생략한다면 거기에 없을 Satellite 데이터를위한 어떤 종류의 공통 식별자를 필요로합니다.
결론
그래서 귀하의 질문에 대답 : 당신은 비즈니스 키 위해 허브를 모델링한다. 전혀. 실제로 허브는 데이터 볼트 모델링의 필수 요소입니다. 링크는 위성에만 연결되지 않고 허브에만 연결됩니다.
직원 소프트웨어가 변경된 것을 상상해보십시오. 다른 모든 필드는 이제 직원 Satellite에 저장됩니다.새로운 소스 직원 소프트웨어를 사용하는 경우 동일한 허브 및 비즈니스 키을 사용하는 동안 모든 데이터를 새 위성 에 저장할 수 있습니다.
그냥이 예제를 완료 : 링크가 직원 및 부서직원 수와 부서에서 연결합니다.EDIT 그래서 예를 들어 구조는 다음과 같을 것이다. 데이터 저장소 관련 필드는 [DV]로 표시되어 있습니다.
Hub Employee
------------
Employee Hash Key [DV]
Load Date [DV]
Record Source [DV]
Personnel Number
Sat Employee
------------
Employee Hash Key [DV]
Load Date [DV]
Load End Date [DV]
Record Source [DV]
Hash Diff [DV]
Name
Surname
Street
City
Link Employee Department
------------------------
Employee Department Hash Key [DV]
Employee Hash Key [DV]
Department Hash Key [DV]
Hub Department
--------------
Department Hash Key [DV]
Load Date [DV]
Record Source [DV]
Shortcode
Sat Department
--------------
Department Hash Key [DV]
Load Date [DV]
Load End Date [DV]
Record Source [DV]
Hash Diff [DV]
ID
Name
자세한 답변을 주셔서 감사합니다. 그러나 나는 아직 그 점을 이해하지 못한다는 것을 인정해야한다. 부서만을 포함하는 허브 테이블의 용도는 무엇입니까? 짧은 코드? 짧은 코드는 위성에 있어야하기 때문에 허브 테이블을 읽을 이유가 없습니다. – jms
사실이 아닙니다 : 단문은 위성에 존재하지 않습니다. 위성에 비즈니스 키 또는 링크 키가 없습니다. Satellite는 비즈니스 키의 해시 키를 사용하여 허브에 연결됩니다. – tobi6
그러면 허브가 부서 코드와 위성의 데이터를 구분합니다. 위성이라는 짧은 코드의 단점은 무엇입니까? – jms
동일한 허브를 소싱하는 서로 다른 시스템을 사용하는 경우 비즈니스 키가 비슷하게 보이는 것이 매우 중요합니다. 그렇지 않은 경우 동일한 링크를 사용해야합니다. 또한 비즈니스 볼트 계층 (비즈니스 규칙)에서 논리를 제거하고 허브에 대해 원하는 단일 항목을 제공합니다. 나는 다음 층에 논리를 적용하지 않을 것이다. – tobi6