데이터웨어 하우스 인적 자원 - 직원 운동

Question

을이 문제의 또 다른 측면은 여기에서 찾을 수 있습니다 : 내가 HR 데이터웨어 하우스 스키마를 설계하는 데 생각에 검증을 조금 후 https://stackoverflow.com/questions/37962025/data-warehouse-human-resources-employee-hierarchy

, 희망 너희 중 몇 사람이 할 수있는 도움!

주어진 시간에
1. (또는 시간 범위), 고용 전송, 해고 직원의 카운트,
이

내가 여기에보고하고 주요 문제는, 등등의 역할을 전환하는 것이 직원 것이다 (대개) v를 천천히 변화시키고, 결국 몇 달 동안 거의 일어나지 않습니다 ... 그래서 "Mar-16의 총 인원은?"과 같은 질문에 답하기 위해서는이 곡물에서 스냅 샷을 찍어야합니다.이 경우 매일 존재합니다 ... 예를 들어 누군가가 6 개월 동안 고용되어 있고 그 중 4 개월이 전혀 변하지 않으면 기본적으로 스냅 샷 사실에 상당한 양의 중복 된 데이터를 저장할 것입니다. 변경 사항을 시간 스탬프 된 차원으로 기록해야하는지 궁금하다. 필요할 때 테이블의 결과 입자가 생성된다. 예를 들어 일별, 주별, 월별 등.

나는이 작업을 수행하는 다른 방법을 생각하는 것은

Answer 1

한 가지 가능한 디자인이 스키마를 사용 "출산 휴가에"재고 항목으로 직원을 치료하고 "역할 X에 할당"등의 변경 사항을 추적하거나하는 것입니다 :

PK primary key of the object 
VALID_FROM_DATE 
VALID_TO_DATE validity interval 
ATTRIBUTE_1 
.. 
ATTRIBUTE_N 

대책 상태 또는 계층 (고정 깊이 계층 옵션 (킴볼 자원에 가까운 4)

이 차원에 대한 일반적인 피드를 사용하여 나타낼 수

속성은 이벤트

01,235 이루어진되고

PK 
ENTRY_DATE - timestamp of receiving the event in DWH 
TRANSACTION_DATE - validity timestamp, the change was done at this timestamp 
ATTRIBUTE_X_NEW_VALUE - attributes was changed, e.g. the new ID of the manager 
ATTRIBUTE_X_OLD_VALUE - optional field used for validation, not defined for new PKs 

입력 날짜와 거래 날짜가 항상 거의 같은 경우 필드 중 하나를 무시하고 다른 필드 만 사용할 수 있습니다. 하지만 그들은 크게 다를 수 있으면 일이 재미가 될 : 트랜잭션 날짜 입력 날짜보다 (훨씬) 오래된

경우 - 이것은 후반 ariving 변화 입니다 거래 날짜 전에 다음 항목 일 경우 - 이것은이다 미래의 변화

이 다른 사업보기를 기반으로 O 형받은로 데이터를 보고 항목 날짜를 기준으로 기술 한 차원의 두 가지보기를 제공 n 거래 날짜.

두 뷰를 한 테이블에 혼합하지 말 것을 권장합니다. 즉, 두 뷰 모두 두 개의 별도 차원 테이블을 유지해야하는 경우입니다.

기술의 유지 관리는 간단합니다.새 엔티티 (새 PK) 변경된 기관에 대한

VALID_FROM_DATE = ENTRY_DATE 
VALID_TO_DATE = dummy high date meaning open end 

는 PK에 대한 마지막 기록을 찾을 수

로 새 레코드를 생성 들어

설정으로 (이것은 개방 단이 있어야합니다)

VALID_TO_DATE = ENTRY_DATE 

을 (를) 새 레코드 만들기

VALID_FROM_DATE = ENTRY_DATE 
VALID_TO_DATE = dummy high date meaning open end 

결과 차원의 간단한 예제

EMP_ID VALID_FROM_DATE VALID_TO_DATE STATUS 
1001  1.1.2016   31.1.2016  ACTIVE 
1001  31.1.2016   31.12.2099  FIRED 

술어를 사용하여 타임 스탬프 X 현재의 상태를 얻을 수있는 테이블에 액세스하는 시간에

WHERE X >= VALID_FROM_DATE AND X < VALID_TO_DATE 

이 각 PK 유효 적절한 레코드를 필터링 할 X

이 설정에서 VALID_FROM_DATE는 포괄적이며 VALID_TO_DATE는 배타적입니다. 일부 각별한주의하면 포함 두 필드를 정의하고 비즈니스 뷰 차원이 훨씬 더 복잡 유지하기 위해

WHERE X BETWEEN VALID_FROM_DATE AND VALID_TO_DATE 

사용할 수 있습니다. 왜? evens가 순차 순서로 도착하지 않을 수 있으므로 마지막 버전뿐만 아니라 처리해야 할 수도 있습니다.

한 가지 가능한 방법은 종류의 모든 새로운 이벤트가 트랜잭션 날짜를 기준으로하고 재생을보다 롤백 후반 도착 거래 날짜의 타임 스탬프 최대 치수이다.

일반적인 조언 - 이론을 과대 평가하지 말고, 데이터를 얻고, 몇 가지 옵션을 시도하고 어떤 것이 효과가 있는지보십시오.

Answer 2

Marmite가 옹호하는 데이터 원거리 구조가 꼭 있어야합니다. 상세한 보고서를 위해 필요할 것입니다. 그러나 최종 사용자와 가난한 보고서 개발자를 생각해보십시오. 복잡한 솔루션은 함께 작업하고 이해하는 데 어려움이 있습니다.

일일 주기적 사실 테이블에 어떤 문제가 있습니까? - 창고는 정규화가 아닌 데이터 표시와 관련이 있으므로 하루 종일 인력 감원을위한 비즈니스 필요성이있는 경우 수행하십시오. 연간 365 건의 기록은 아무것도 없습니다. (사무실/부서/paygrade 등)

보고서 날짜 범위를 정렬에 대한 일 처리보다이에서 구축하는 것이 훨씬 쉬울 것을 필요한만큼 치수를 추가

 
FACT_STAFF_SUMMARY_DAILY { 
    DATE_SK 
    EMPLOYED_COUNT, 
    MAT_LEAVE_COUNT, 
    SICK_LEAVE_COUNT, 
    OTHER_LEAVE_COUNT, 
    RESIGNED_LASTDAY_COUNT,  
    ..other daily totals.. 
} 

.