내 작업 표에는 created_time, created_date, completed_time, completed_date을 저장할 4 개의 열이 있습니다.데이터웨어 하우스 - created_time, complete_time, complete_date를 저장하는 방법
해당 테이블을 OLAP으로 변환 할 때 해당 테이블을 날짜 시간 차원에 저장하고 싶습니까? 아니면 팩트 테이블에 그대로 둘 수 있습니까?
누군가 설명해 주실 수 있습니까? 고맙습니다.
스타 스키마를 사용한다고 가정 할 때 날짜 측정 기준은 일반적으로 조회 테이블 이상의 역할을합니다. 일반적으로 사실 테이블의 특정 날짜를 설명하는 좋은 수의 열을 포함합니다 (예 : 공휴일, 분기가 올 것인가, 회계 분기가 올 것인가 등).
이렇게하면 비즈니스가 수행 할 수 있습니다 1 분기에 완료된 작업 수 (1 분기의 정확한 시작일과 종료일을 입력하지 않아도 됨)와 같은 질문을하십시오.
귀하의 질문에 대한 대답은 사용자가 귀하에게 묻기를 기대하는 질문 유형에 따라 다릅니다. 위와 같은 쿼리가 예일 경우 날짜 정보를 저장하기위한 포괄적 인 날짜 차원을 만듭니다.
물론 이것은 쿼리에서 FK (또는 날짜 열에 대한 포인터 열)를 사용하고 조인을 사용하게합니다. 매우 큰 테이블의 조인은 성능을 약간 저하시킬 수 있습니다. 그러나 스타 스키마는이 개념을 기반으로합니다.
날짜 차원은 현재 연도 (또는 그 이상) 이외에 일반적으로 1 년 또는 2 년을 다루는 일부 데이터 행으로 초기화해야합니다.
이제 시간 열에 대해 이야기합니다. 날짜 차원에서 시간을 구성하는 것은 좋지 않습니다 (링크 참조). 날짜 차원에서 시간을 작성하면 날짜 차원이 불필요하게 커집니다.
시간 차원을 사용하는지 여부에 관계없이 사실 테이블에만 시간 열을 배치하는 것이 좋습니다. 사실 테이블의 총 기간 (일, 월, 년 및 시간)과 같은 사실에 계산 열을 포함하는 것이 좋습니다 (이 정보는 완료까지 5 시간이 소요 된 작업 수와 같은 쿼리를 처리한다고 가정 할 경우). ETL 동안 계산을해야합니다. 날짜가 없어도 시작 시간에서 종료 시간을 뺄 수는 없습니다. 또한 쿼리 시간 동안 계산에 참여하기를 원하지 않습니다. 그렇지 않으면 쿼리가 복잡해집니다.
이러한 비정규 화 유형은 스타 스키마 모델 내에서 많은 사람들이 수용 할 수 있으며 사실을 더 길게 만드는 사소한 단점이 있습니다. 계산 된 열을 가상으로 만드는 방법이 있지만 계산 된 열을 유지할 수도 있습니다. 그러한 경우, 사실이 길고 많은 수의 팩트 테이블을 가지고 있다면, 처리를 더 빠르게하기 위해 주요 사실과 1-1 관계에 연관된 특수 팩트 테이블을 작성하기로 결정할 수 있습니다. 새로운 사실은 더 작고 빠르게로드 할 수 있습니다. 그러나 이것은 많은 응용 프로그램의 경우가 아닐 가능성이 크며, 사실 1 개의 사실만으로도 잘 작동합니다.
이것은 도움이 될 수도 있습니다 : Kimball-Latest Thinking On Time Dimension Tables.
created_time이란 무엇입니까? 그것은 hh : mm : ss입니까? – NoChance
@NoChance hh : mm – user3099298