1) Fact Table
중심테이블로서 관련성이 측정값들을 담고 있음
측정값으로는 비즈니스 사업을 수치적으로 관찰할 수 있는 금액, 건수, 시간 등이 포함됨
테이블에 대한 외래 키를 포함
2) Dimension Table
팩트에 대한 설명 정보를 포함
모든 디멘젼 테이블은 하나의 기본키를 가지고 있음
예시
Dimention Table | Fact Table |
---|---|
1=한국 | City = 1, 3, … |
2=일본 | |
3=영국 | |
4=프랑스 |
Orders 테이블은→ Fact Table
나머지 네개의 테이블은 → Dimension Table
Fact Table 설계에 네개의 Dimension Table 이 사용되었습니다.
테이블 종류 | 적재 주기 |
---|---|
Fact Table | 대부분 시간, 일, 주,월별로 기록 / 기업에 따라 상이 |
Dimension Table | 필요에 의해 업데이트 (이벤트 및 업데이트가 있는 경우) |
적재 방식 | 특징 |
---|---|
Truncate | • 이전 데이터가 삭제됩니다. |
• 다만, 테이블 구조(열, 형식)은 그대로 보존됩니다. | |
• 고객의 멤버쉽 등급 등 갱신정보가 필요한 테이블에 주로 사용됩니다. | |
Insert | • 이전 데이터가 유지된 상태로, 데이터가 추가됩니다. |
• 시간에 따른 데이터의 흐름을 파악해야 하는 테이블에 주로 사용됩니다. | |
• 대부분의 데이터는 Insert의 형식을 취하지만 이는 용량 이슈를 야기합니다. |
Q. 서브쿼리 대신 HAVING을 쓰면 안 되는 경우가 있어 문의드립니다. HAVING이랑 서브쿼리랑 정확히 어떤 차이가 있나요?
A. 서브쿼리는 추가 조건 설정 가능, HAVING은 GROUP BY 이후 조건 설정이라 사용하고 나서 추가로 조건 설정하기가 힘듦
서브쿼리가 너무 많아지면 연산량이 많아서 효율이 떨어짐 → 공부하는 입장에서 구조를 정확하게 파악하기 위해 서브쿼리로 적은 겁니다~
어떠한 SQL 구문을 작성하더라도 우리는 테이블이 어떻게 구성되어있는지 확인하기 위해 전체 컬럼을 명시해주는 것이 좋습니다. (다만, 테이블이 너무 큰 경우 LIMIT을 걸어주면 더 좋음)
SELECT 되는 컬럼이 많을수록 쿼리의 실행속도가 느려지게 됩니다. 분석하고자 하는 방향이 명확한 경우, 전체컬럼 보다는 필요한 컬럼만 불러오는 것이 좋겠습니다.
정확하게 결과가 나오는 것이 가장 중요하므로, 쿼리문이 길어져도 괜찮아요. 효율은 나중 문제입니다~